Every replatforming conversation starts the same way. The current storefront is eight years old, nobody wants to touch the checkout, and the CTO has been told the migration will take nine months. The unspoken assumption in that estimate is that the roadmap stops for nine months.

It doesn't have to. The business case for replatforming usually evaporates if you have to buy it with three quarters of frozen feature work, so the interesting question is never "how do we rebuild this?" — it's "how do we rebuild this while the old system keeps taking orders?"

Route traffic before you move code

The single decision that makes or breaks an incremental migration is where the routing boundary lives. Put a reverse proxy in front of both systems on day one, before a single line of the new platform exists. Every path resolves to the legacy application by default; you move paths across one at a time.

location /checkout { proxy_pass http://legacy; }
location /catalog  { proxy_pass http://spryker; }
location /         { proxy_pass http://legacy; }

That is the entire strangler pattern. It is unglamorous, and it is what turns a big-bang cutover into a sequence of reversible decisions. When the new catalog misbehaves under real traffic, the rollback is one line of config, not a weekend.

The corollary matters just as much: pick the boundary along a seam the business already understands. Catalog, search, checkout, account. If your first slice cuts across three of those, you have not found a seam — you have found a rewrite.

Sequence by risk, not by ease

The instinct is to migrate the easy things first for an early win. That gets the sequence backwards. The parts of a commerce platform that carry migration risk are the ones with the most integration surface — pricing rules, tax, availability, the ERP handshake — and they are exactly the parts you want to discover problems in while you still have budget and political capital.

A sequence that has held up across several builds:

  1. Catalog and search first. Read-heavy, low blast radius, and it forces you to solve product data import and the PIM relationship immediately.
  2. Content and landing pages next. Marketing gets visible value early, which buys patience for the quieter phases.
  3. Cart and pricing after that. This is where the real business rules live, and where the legacy system's undocumented behaviour surfaces.
  4. Checkout and payment last. Highest risk, most regulated, and by this point you understand the domain well enough to do it once.

Accounts and order history sit awkwardly across the whole sequence, because customers expect continuity. Plan for a period where both systems read from one identity source — usually the legacy one — rather than trying to migrate identity in the same slice as anything else.

The dual-write period is the hard part

For any slice touching writes, there is a window where both systems need a consistent view of the same data. Teams reach for dual-write and then discover that dual-write without an ordering guarantee is just two systems disagreeing at speed.

Publish domain events to a log — Kafka is the usual answer, and it is the right one — and let both systems consume from it. The legacy application gets a small outbound adapter, the new platform gets a consumer, and the log becomes the arbiter of what happened and in what order. This is more work upfront than a synchronous double-write, and it is the difference between a migration you can reason about and one you can only apologise for.

The question to ask about any dual-write design: when the two systems disagree, which one is wrong, and how do you find out before a customer does?

What actually goes wrong

Not the things in the risk register. In practice:

  • Redirects. Nobody budgets for them, and a botched URL map costs more organic traffic than the replatform gains in conversion. Build the redirect map from the server logs, not from the sitemap — the sitemap does not know about the ten-year-old campaign URLs still earning links.
  • Search relevance. The new search is objectively better and converts worse for six weeks, because merchandisers had years of tuning baked into the old one. Budget for re-tuning as a project, not as a task.
  • Reporting. Finance has a spreadsheet that reads from a database view somebody built in 2017. It will be discovered two days before cutover.

None of these are engineering problems, which is exactly why they get missed by engineering-led migration plans.

When a big-bang cutover is right

Incremental is not always correct. If the storefront is small, the integration surface is thin, and the legacy system genuinely cannot be fronted by a proxy — some hosted platforms make this impossible — then the proxy layer is real work that buys you nothing you can't get from a well-rehearsed weekend cutover.

The honest test: if the incremental path costs more than about a fifth of the total migration budget in pure plumbing, and the rollback story for a big-bang is credible, take the big-bang. Rehearse it three times against production data first.