Planning a migration around a platform renewal

Most migrations are not born from a strategy deck. They are born from a renewal quote. The platform you have run for a decade sends a number for the next three years, and the number makes the decision for you.

That date is useful. A deadline that cannot move forces answers to questions a committee would debate for another year. The renewal converts a vague intention into a plan with a shape. This is how to build that shape.

How far ahead should you start?

The renewal date is fixed, so the variable is scope. The most common failure is not starting late. It is fixing scope early, discovering the estate is bigger than anyone counted, and then compressing the parallel run to save the date. The parallel run is the last thing you should ever compress, because it is the thing that proves the migration.

Why does the inventory come first?

You cannot plan what you have not counted. The inventory lists every procedure, package, script and schedule, classifies each by complexity, and marks the ones only one person understands.

It changes the conversation. Before the inventory, the plan is a guess with a Gantt chart. After it, the plan is arithmetic: this many objects, at this measured rate, fit or do not fit the runway. The ten-minute Logic Debt Scorecard gives a first count; the estate assessment turns it into a counted list.

The inventory also finds the estate's silent mass: dead code, duplicate procedures, jobs that write to nothing. Every dead object you find is an object you do not have to convert. In most estates that is a meaningful discount on the whole project.

Why prove one domain before committing to the whole estate?

Because a first domain turns opinions into measurements. Pick one domain with real logic in it, the kind people argue about. Convert it. Reconcile it. Run it in parallel. Time every step.

The first domain tells you your real conversion rate, your real reconciliation effort, and where the surprises live. A plan extrapolated from a measured first domain survives contact with reality. A plan extrapolated from optimism does not.

How do you cut scope when the runway is too short?

The license is paid per platform, not per domain. A partial migration that has proven each moved domain is a success you finish on a bridge. A total migration nobody proved is a risk you carry for years.

1. Convert the domains with the highest business visibility first, so the parallel-run evidence covers the numbers people actually watch.
2. Move reporting and read-heavy workloads early. They are usually the safest tranche and they free capacity for the harder ones.
3. Push low-risk domains past the renewal date if needed, on a short bridge extension. A small bridge license for two domains is cheap. A rushed cutover of everything is not.
4. Never cut the parallel run. If there is no time to prove a domain, there is no time to move it.

What about the deadline that is already too close?

Then the right plan may be a short bridge extension with a fixed, honest scope, not a heroic one. A two-quarter bridge that converts and reconciles the estate properly costs less than a rushed cutover followed by a quarter of unexplained discrepancies.

The renewal date is a deadline for the platform decision. It does not have to be the deadline for the last procedure, as long as each tranche that lands is proven before it lands.

The plan, in one page

Count the estate. Score it. Prove one domain and measure. Scale in tranches, highest-visibility domains first, with a parallel run before every cut over. If the runway runs short, cut tranches, not proof.

A renewal date is an uncomfortable gift. It is the one thing in a migration that will not move, which makes it the one thing you can plan against.