8. How to Limit Scope & Start Small
2024-09-01
The most common failure mode in migration? Trying to do too much.
We’ve seen migrations stall for months not because the work was too hard, but because the scope kept growing. Every team wanted their tooling in the new stack. Every service needed to be optimized. Every edge case needed to be solved. Nothing shipped.
Smart migrations don’t boil the ocean. They create controlled, meaningful wins — fast. But those wins must be designed as complete vertical slices, not just disconnected microservices.
It has multiple services that work together
It delivers user or internal value on its own
It can be migrated and operated independently
Why? Because migrating just one piece of a larger system creates new integration points, new latency, and more complexity. We want to reduce risk, not shift it around.
Observable behavior and known traffic patterns
Low user impact if something breaks
No shared database with other services
Clear ownership (if possible)
Easy to roll back if needed
These stacks become your proof of concept: they validate your infra patterns, pipelines, access model, monitoring, and team collaboration.
Monoliths with shared DBs and no clear boundaries
Billing or subscription flows
Core customer-facing experiences
Services that touch everything else
Compliance-sensitive workflows
Workloads without logging or alerting
Start with systems that can fail safely. Don’t bet the org on your first step.
Monoliths with shared DBs and no clear boundaries
Billing or subscription flows
Core customer-facing experiences
Services that touch everything else
Compliance-sensitive workflows
Workloads without logging or alerting
Start with systems that can fail safely. Don’t bet the org on your first step.
"We'll build momentum through visible progress."
"This is a test run for our tools, workflows, and teams."
"We’re learning the system while migrating it."
"We need to de-risk this before scaling."
Leadership understands experimentation. This is your MVP mindset — applied to infrastructure.
Say no to wishlist features: "not now"
Assign someone to guard the scope and call it out when it drifts
Pause rollout if the foundation isn’t solid yet
Avoid "just add this too" changes mid-sprint
Most importantly: cut things off. Make the switch. Shut down the old. If you don’t, you’re not migrating — you’re duplicating.
One reason migrations drag on forever? Teams don’t get to rest. When you keep multiple environments up indefinitely, fatigue sets in. Every sprint is half migration, half maintenance. Nobody sees the finish line.
Migrate a real chunk
Cut over fully
Celebrate
Pause
Then move to the next chunk. That’s how you build rhythm without burning people out.
A successful migration isn’t the one with the perfect scope. It’s the one that finishes. And finishing starts with choosing the right first slice.