Beyond Big Bang: Iterative Migration

The big-bang integration migration looks clean on the Gantt chart. That clean line is exactly where the risk hides. There is a slower-looking path that is actually safer, cheaper, and far easier to fund.

Imagine the initial kickoff meeting.

An IT director stands in front of a Gantt chart. Eighteen months. One platform. One go-live date. Management signed the budget off last quarter. The room is quiet with relief.

Finally the legacy question has an answer. Finally somebody decided.

Now go back to the same room fourteen months later.

Same team, minus the two senior people who left in the autumn. The Gantt on the wall has a lot of red on it.

The new platform is half in and half out. Management is asking why. The director is preparing the answer.

We have been collecting versions of these two rooms for years, across industries, company sizes, starting platforms, and destinations.

The pattern is steady enough to write down. This is about how to never end up in it.

The clean plan is the risky plan

The big-bang instinct makes sense. You run one project instead of two systems in parallel.

You force the organisation to decide. The technical debt gets a cutoff date. You can tell management, in a clear voice, that you are on the new platform now.

We hear the pressure behind it all the time.

One IT director at a Nordic energy company put it plainly: “We can’t keep the old platform alive much longer.”

When the pressure feels structural, the plan feels like it has to be structural too. Big. Final. One line on the deck.

Here is the hard part. The big and final plan is not the safe plan. It is the risky one.

The clean Gantt line hides the fact that you have bet the whole platform on the data you had on day one. And day one is when you know the least you will ever know.

What goes wrong between month six and month fourteen

The big-bang plan rarely survives contact with reality. Something usually ships, but it looks almost nothing like the kickoff slide. A few patterns repeat.

Scope quietly grows. You start out migrating messaging. Three months in, you find the messaging is tangled into business logic nobody has documented in a decade.

By month nine you are re-architecting three business domains. Nobody approved that. It happened one reasonable decision at a time.

The project stalls. Leadership changes. A budget freezes. A regulator eats a quarter of the team’s time.

However, the project does not die. It just stops moving, with two systems still running and neither one clearly owned.

The person who knew leaves. The architect who understood how the flows mapped to the business takes an offer in month seven. The documentation in their head walks out with them.

Then comes the audit. Someone asks which transactions an outage touched on the fourteenth.

The team can say when the connector restarted. They cannot say which invoices posted twice when the retry kicked in.

In a big-bang plan, that gap stays open until the new platform closes it. Eighteen months away. The compliance lead does not have eighteen months.

Migration is a portfolio, not a project

Here is the reframe.

A project has one budget, one timeline, one go-live date. If the bet is wrong, you find out late and you find out expensively.

A portfolio is many small bets. Each has its own business case. Each has its own payback. Each has a clean way out if the bet does not work.

So stop treating “the migration” as the unit of work.

The real unit is the reversible module: a piece small enough to finish in weeks, big enough to matter, and self-contained enough to run before you have chosen the platform you are heading toward.

You can test any piece of work against four questions.

The Reversible-Module Test

1. Weeks, not quarters? Can this piece finish in weeks, with a deliverable you can point at?

2. Fundable alone? Does it have its own business case, so management can fund just this?

3. Clean off-ramp? If the bet is wrong, can you stop without losing what you built?

4. Buys data? Does it produce information that changes the next decision?

Four yes answers mean a reversible module. Anything less means you are still betting the platform on day one.

Start with what you cannot see

The first module is almost always the same one, and it is the one teams skip: get a live picture of what is running today.

Not the diagram from 2022. Today. Integrations, dependencies, flows, owners. No platform commitment. Pure learning.

It surprises people every time.

Somewhere between twenty and forty percent of what a team thinks it runs is dead, duplicated, or serving a use case the business retired years ago.

One Nordic energy company was three weeks from signing a large platform deal. They paused and spent six weeks on visibility first. About thirty percent of the integrations they were about to migrate were dead or duplicated.

Another slice was owned by departments about to be reorganised, so those requirements were going to change anyway.

They postponed the platform decision by six months, and by the time they made it, the migration scope was roughly half the original.

The same pattern shows up at construction groups and universities running very different stacks.

The order changes the answer

Notice what actually happened in that energy company. The team did not get smarter between week three and week eight. They got the same decision with the data in a different order, and the order changed the answer.

That is the whole idea.

The big-bang plan asks you to make the biggest call at the moment you know the least.

The reversible module flips it, so each decision is made on data you did not have before.

And it works whatever you run on. Azure, on-premise, hybrid, a partner running it for you, one platform or four stitched together.

The destination is yours to choose. The sequence is what changes the quality of the choice.

So before your next architecture meeting, do one thing.

Take the biggest migration decision on your desk and run it through the four questions above. If it fails even one, you have not found your first reversible module yet.

Start there.

Map what you actually run, before you migrate a single flow.

That one move will tell you more about your real risk than any eighteen-month Gantt chart ever has.