A few weeks ago I co-hosted a roundtable with Atlassian. It wasn’t a pitch, just a small group of senior IT leaders talking about what breaks in their environments.

At one point a CIO walked us through why incidents in his organization take so long to resolve. The knowledge to fix most of them exists, he said. It’s just scattered across five different systems, and it got that way over a decade of tool changes and a couple of acquisitions that nobody ever went back to consolidate.

And he explained how it got that way. The tool changes had all been migrations, and each had moved the data across without touching the fragmentation underneath.

A migration gets scoped as a data job

The framing is almost always technical. Get the data out of the old system and into the new one without losing anything or breaking anything, and that’s the brief.

That framing holds up as far as it goes. The problem is that it treats the organization as the fixed thing and the platform as the only thing that changes.

And the organization is not fixed.

By the time you’re scoping a migration, the source system has usually been running for years. It has absorbed reorganizations, new compliance requirements, a few process changes nobody wrote down, and a whole layer of workarounds people invented when the old tool wouldn’t do what they needed. All of that lives in the data, so if you reproduce it faithfully, what you get is a shiny new system that quietly inherits every compromise of the one it replaced.

Lift and shift is a reasonable position

It would be easy to call that a failure of ambition, but I don’t think that’s fair.

Migrations are risky. People are already on edge about the change, and if you swap the platform and redesign the process at the same time, then the moment something breaks you can’t tell which decision caused it. Keeping the number of moving parts down is sound judgment. So teams move it as-is, get it stable, and figure they’ll improve it later.

The trouble is that moving it as-is is rarely something anyone decides on purpose. It just ends up that way because nobody stops to make the call, and by the time anyone might, the project has closed and the team has moved on, so whatever got deferred becomes the permanent shape of the new system.

The one window where an organization will tolerate a change in how the work gets done is the migration itself, and that window shuts the day the project does.

Contextual Delivery treats the migration as a chance to change

At Trundl, the alternative we’ve landed on is what we call Contextual Delivery. The idea is simple. What an organization knows about itself should keep shaping the build the whole way through, instead of getting captured once at kickoff and carried unchanged to go-live.

For a migration, that means going into the source environment and seeing how it runs now, because the documentation is usually a few years stale. What you find on the ground is the stuff nobody would raise in a workshop, like a field they stopped using two years ago.

Those findings force two calls that a standard migration plan doesn’t really leave room for. The first is deciding what shouldn’t move at all, because some of it was only ever a workaround for the tool you’re replacing, and some of it is left over from a process that ended a long time ago. The second is spotting where the new platform can do something the old one couldn’t, so the process improves instead of relocating. Neither of those is a technical question, and both get skipped when a migration is scoped as a data exercise.

Some of this still takes time

None of this makes the hard part faster. A department head still has to agree that a process they’ve run for years is going to change, and people still have to learn something new and decide whether they trust it.

Better tooling doesn’t compress that at all. If anything it makes the human side more visible, because the technical work stops being the thing everyone is waiting on. And there are still good reasons to defer some things. A regulated control is a bad thing to be experimenting with in the middle of a migration, and some parts should move across untouched.

The honest version

Most migration plans measure success by fidelity. Did everything come across, did anything break, did we hit the cutover date. Those are the right questions for the move itself.

They’re the wrong questions for the money, though, because a migration is one of the few moments when an organization has already agreed that things are going to change. That agreement is worth something, and lift-and-shift spends it on nothing.

So before the next migration starts, I’d want to know whether anyone decided what to leave behind. If nobody did, the new system just quietly takes on everything that was wrong with the old one.