How to Estimate a Migration or Replatform

Database swaps, framework upgrades, moving off a vendor, splitting a monolith. Migrations share a signature failure: the team estimates six weeks, the first 80% takes five, and the remainder takes four months.

That pattern is so consistent it's worth planning for directly.

Why the tail is so long

Migrations are not one piece of work, they're one piece of work times every caller. The core change (the new client, the new schema, the new service) is genuinely well understood and genuinely estimable. What isn't estimable at the start is the set of things depending on the old behavior, including behavior nobody documented and some nobody intended.

The effort isn't in the migration. It's in the discovery of what was coupled to what.

Count the call sites before you vote

The single highest-leverage thing you can do before estimating a migration is to spend a day producing an inventory: every module, job, dashboard, script, and external consumer touching the thing you're replacing. Not an estimate of how many, but an actual list.

Then estimate a representative sample of them properly and multiply. A team that has counted 140 call sites and estimated twelve of them has a real forecast. A team that hasn't counted has a wish.

Estimate the three phases separately

Migrations behave differently enough across phases that a single number hides everything:

• Build the new thing: well-defined, estimate it like any feature.
• Move the callers: repetitive and countable, best estimated as unit-cost × count, with a few known-hard ones sized individually.
• Remove the old thing: the decommission. Routinely dropped from the plan and routinely the reason migrations linger for a year with both systems running.

If the third phase isn't in the estimate, it won't be in the schedule, and you'll pay the cost of running both systems indefinitely.

Budget for the dual-running period

While both systems exist, every new feature costs more, because it has to work in both. That tax is invisible in the migration's own estimate but very real in the sprints alongside it. Name it: "while the migration runs, expect roughly a fifth less throughput on everything else."

Slice so you can stop

The best protection against a migration estimate being wrong is a migration that delivers value in pieces. If moving 30% of traffic is useful on its own, an overrun is a delay. If nothing is useful until 100% is done, an overrun is a crisis, and you've built something too big to estimate at the whole-project level anyway.

Re-estimate after the first cohort

Once you've migrated the first ten call sites, you know your real unit cost. Use it. It'll usually be higher than your estimate, and finding that out in week two beats finding it out in month four. This is one of the clearest cases for re-estimating mid-flight.

Migrations aren't hard to estimate because the work is mysterious. They're hard because the work is large, repetitive, and easy to miscount, so count it.