Single blog hero image

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.