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.

Start with a Whole, Small Product

The ideal starting point for migration is an independent application or stack, not just a background job or single microservice. That means:

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.

How to Know You Picked the Right First Scope

Good candidates tend to have these traits:

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.

What Not to Touch First

Some parts of your system might seem important, but they’re terrible starting points:

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.

Why Starting Small Isn't Playing It Safe

Some parts of your system might seem important, but they’re terrible starting points:

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.

Why Starting Small Isn't Playing It Safe

When we start small, we don't do it to avoid risk. We do it to de-risk the bigger plan. Our messaging to stakeholders is:

"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.

Avoiding Scope Creep

Even small migrations can get bloated. Here’s how we prevent that:

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.

Don’t Forget Migration Burnout

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.

Instead:

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.