A catalog rebrand or platform migration is often sold as a project plan with a go-live date. Underneath it is a distributed data problem with customers still buying things. I have worked through import microservices, submit/fulfillment pipelines, Terraform-provisioned ECR/container footing, companion Lambdas for webhooks and bulk processing, and reusable Dockerized migration templates with CodeBuild promotion paths. The complexity is not copying rows.
Identity is the first war
Every SKU, barcode, customer, location, and historical order id must map between worlds. If two systems disagree about identity, you get duplicates, orphans, and support nightmares.
Good migrations invest early in:
- canonical external ids
- mapping tables you can audit
- dry-run reports of unmapped entities
- explicit rules for collisions
Bad migrations discover identity issues on launch morning.
Pipelines beat megajobs
Import, submit, and fulfillment as separate services (or at least separate stages) exist because the failure modes differ. Import can be re-run. Fulfillment may have side effects you cannot casually rewind. Bulk order processing Lambdas may need different concurrency than catalog importers.
Terraform that creates ECR repos without images will hang or fail forever if your apply assumes tasks can start immediately. That tiny operational detail has burned many “infra is done” claims. Images are part of the release, not an afterthought.
Cutover is a product experience
Will the storefront freeze? Will Admin be read-only? Will POS still sell? Will webhooks point at old handlers for an hour?
Partial cutovers are often necessary and always dangerous. You need a state machine for the migration itself: what is live where, and you need humans who understand it at 2 a.m.
Media and merchandising are underestimated
Engineers focus on product JSON. Merchants experience missing images, broken collections, wrong metafields, and theme assumptions. Apostrophe-style CMS launches have the same class of problem: favicons and social images not in git still block a “done” deploy.
Budget time for visual QA as a first-class workstream.
Templates are how you stop paying tuition twice
Reusable migration templates with Docker + CodeBuild (dev/prod) exist because the second migration should not start from folklore. Parameterize what varies. Hard-code what must stay safe. Log like you will need receipts.
What I insist on before go-live
- Mapping completeness report with owners for leftovers
- Replay/re-run strategy per stage
- Rollback narrative (even if rollback is “forward fix only”, say it out loud)
- Webhook/cron silence or dual-write plan
- Support playbook for the first 72 hours
Migrations are not ETL hobbies. They are temporary distributed systems that must not drop the business while the business moves.