A commerce platform begins a strangler migration. Which slice should be first, and what must exist before any slice moves?

What must exist first

A façade in front of the existing system, through which all traffic routes and which can direct each request to either the old or the new implementation. Nothing changes functionally; this step exists purely to create the switch, and doing it first is what makes everything afterwards incremental.

Traffic shadowing capability, so real traffic can be sent to both and the responses compared. This finds behavioural differences no test suite will — particularly the undocumented edge cases that turn out to be load-bearing business rules.

An anti-corruption layer at the boundary, so new services do not inherit legacy data models and naming. Without it, the "new" system becomes a distributed copy of the old one with extra network calls, which is the most common way strangler migrations fail.

Instant rollback, as a configuration change rather than a deployment.

Which slice should be first

Not the most valuable one. The one that proves the machinery. Criteria:

• Few dependencies, so the slice can be replaced without coordinating with everything else.
• Clear boundaries, ideally a capability rather than a process step, since capability boundaries survive product changes.
• Read-only or read-mostly, which avoids the hardest problem — data ownership — in the first slice.
• Modest traffic, so a mistake is survivable, but real traffic rather than none.
• An owner with capacity, because a first slice that stalls sets the programme's reputation.

For a commerce platform this is frequently something like catalogue or content retrieval: read-heavy, clearly bounded, and low blast radius.

Why the first slice matters disproportionately

It establishes whether the routing, shadowing, comparison, cutover and rollback machinery works, and it produces the organisation's first evidence that the programme delivers. A first slice that takes nine months because it was too ambitious frequently ends the programme, regardless of the technical merit of the plan.

The rule that keeps it honest

A slice is not complete until the legacy path is removed. Otherwise the organisation operates both permanently — which is the characteristic failure of these programmes and the outcome that destroys the business case.