On every migration I’ve run, there’s a moment where someone suggests starting the first production cutover with something substantial. A major service. A meaningful percentage of traffic. Something that would demonstrate real progress.
The instinct is understandable. There’s been months of preparation, the new platform is ready, and a small cutover feels like it doesn’t justify all the effort. Why prove you can shift 1% when you’re ready to shift 25%?
The answer: because you don’t yet know whether the machinery works.
What the first cutover is actually proving
The first production cutover isn’t primarily about traffic. It’s about process.
Can you run the runbook under real conditions? Does the monitoring show what you expect it to show? Is the communication chain working — does the right person get the right notification when something looks wrong? Is the rollback procedure actually executable, or does it have a dependency that didn’t show up in rehearsal?
All of those questions have one cheap answer and one expensive answer. The cheap answer is a small, controlled, reversible cutover where the blast radius is a single non-critical service. The expensive answer is discovering the gap mid-cutover on something business-critical.
The first cutover’s job is to make the process real. Everything else can scale once the process is validated.
The machinery that needs to be proven
I think about three pieces: the runbook, the observability, and the rollback.
The runbook is a document until it’s been followed under production conditions. Steps that seemed clear in a dry run have a way of becoming ambiguous when the clock is running and real traffic is involved. The first cutover is where ambiguity surfaces at low cost. The questions that come up — “what do we check here?”, “who makes the call to proceed?” — are the questions you want answered before you’re in a cutover that can’t wait.
The observability is a dashboard until you’ve trusted it on real traffic. Does the new platform’s monitoring correctly reflect what’s happening? Are the thresholds calibrated for the new environment, or are they carryovers from the old one that don’t map correctly? Latency graphs and error rates look very different on a single quiet service versus a high-traffic one, and the first cutover is how you learn what “normal” looks like before you need to recognise “abnormal.”
The rollback is a theoretical procedure until it’s been tested. The most important question in a cutover is not “did it go well?” but “how quickly could we reverse it if it hadn’t?” On the first cutover, you have the option to roll back for almost any reason — because the latency looks slightly off, because one metric wasn’t where you expected, because a team is uncomfortable. Use that flexibility to prove the rollback works while the stakes are low.
How small is embarrassingly small
Embarrassingly small means: if someone asked “why did you bother” and your answer was “to prove the process works,” that answer should make sense.
In practice: one service, ideally a non-critical path, with a defined window and a defined acceptance criterion. The acceptance criterion is specific — not “it worked” but “latency stayed below X for Y minutes, error rate stayed below Z, and all dependent services remained stable.” If it meets that criterion, the cutover stands. If it doesn’t, rollback and investigate.
On a migration for a mobile advertising platform in India, the first production cutover was a single internal tool — something used by the team rather than serving external requests. Not because we weren’t confident in the platform, but because confirming that confidence with something reversible was worth the extra time. The platform had been validated extensively in staging. The first production cutover validated the process on something where a problem would be a delay, not an incident.
The pressure to go bigger
There’s often external pressure to make the first cutover more substantial. The client wants visible progress. The timeline has milestones. A single internal tool doesn’t feel like it justifies the platform work that preceded it.
The counter to that pressure: the first cutover is the foundation for all subsequent cutovers. If it goes wrong in a visible way — service degraded, rollback executed, an incident generated — the next cutover will be harder to schedule and harder to get approval for. The political cost of a failed big cutover is far higher than the political cost of a successful small one.
The first cutover being small is a feature of a well-run migration, not an apology for being cautious.
After the first cutover
Once the first cutover has validated the process, the scope can grow with confidence. The second cutover is bigger because the first one proved the machinery works. By the time you’re at 75% or 100%, the runbook has been followed, the observability has been calibrated, and the rollback has been tested.
You don’t learn those things on the big cutovers. You carry them into the big cutovers from the small ones that came before.
The first cutover should be embarrassingly small. That’s not a limitation — it’s the whole point.