Why 'lift and shift' migrations fail (and what to do instead)

Moving the mess to a new platform is not modernization. It is paying twice: once to move it, once to clean it up afterward.

There is a seductive simplicity to lift-and-shift migration: take everything from the old platform, put it on the new one, declare victory. No hard decisions, no arguments about what to keep, no one whose content gets archived.

It is also the most expensive way to migrate — because you pay to move everything, including the content nobody needs, and then you pay again to clean it up in the new environment, where the same problems resume within months.

Why smart teams choose lift-and-shift anyway

Lift-and-shift is rarely chosen because anyone believes it is the best approach. It is chosen under pressure. The platform is end-of-support and the deadline is fixed. Leadership wants the migration done this fiscal year. The vendor's proposal promises speed and simplicity. The business wants no disruption. In that environment, the proposal that avoids hard decisions wins — because hard decisions take time, and time is what the deadline does not allow.

There is also a quiet incentive problem. A migration scoped by volume rewards moving more, not less. A migration scoped by outcome rewards moving only what earns its move. When the contract pays per gigabyte or per site, nobody in the delivery chain benefits from triage — and the organization pays for the absence of triage twice, once in the migration and once in the cleanup that follows.

Understanding these pressures matters, because the argument against lift-and-shift has to beat them. It has to show that triage is not a delay — it is the thing that makes the migration cheaper, faster, and less disruptive.

What lift-and-shift actually moves

When you lift and shift without triage, you migrate:

  • Dead content nobody has opened in three years.
  • Broken permissions, granted years ago and never reviewed.
  • Duplicate files and conflicting versions.
  • Workflows built on unsupported tooling, which will break quietly after the move.
  • Sites with no owner, which will become nobody's problem on the new platform too.

You also migrate the opportunity cost: the migration consumed the budget and the team's attention, so the cleanup that should have happened never does. The new platform inherits the old platform's problems — and the organization concludes that migration 'did not help', which makes the next modernization harder to fund.

The permission problem deserves emphasis, because it is the one with the longest tail. Migrating broken permissions does not just carry forward a mess. It carries forward an access model nobody can explain, onto a platform where Copilot and enterprise search will surface whatever those permissions allow. The migration that ignored permissions becomes the AI exposure of next year.

What to do instead: migrate as modernization

1. Inventory and triage

Map the estate. What is current and used? What is dead? What is sensitive? Archive the dead, remediate the sensitive, and migrate only what earns its move.

Triage is not deletion. It is a decision, made with the content owner, about each body of content: migrate, archive, or delete. Archiving is the option that makes triage politically survivable — nothing is destroyed, everything is retrievable, and the new platform starts clean. Most estates find that a large share of content archives without a single complaint, because nobody was using it.

2. Redesign the architecture

The new platform should not inherit the old information architecture. Hub structure, metadata, navigation, and permissions get designed for how people work now — not copied from a structure designed a decade ago.

Architecture redesign is also where you fix the findability problem that drove people to shadow storage in the first place. If users could not find things in the old structure, copying the structure guarantees they will not find things in the new one either. Design for how people search, browse, and work — not for how the old folders were organized.

3. Rebuild permissions

Permissions are rebuilt on current needs, not copied from history. This is the single highest-value step in the migration — and the one lift-and-shift skips.

Rebuilding permissions forces the conversation that the old platform avoided: who actually needs access to this content, and why? The answer is usually a much smaller group than the inherited permissions suggest. Smaller, explainable access is the foundation of audit readiness, AI readiness, and every governance initiative that follows.

4. Modernize workflows

Legacy workflows get rebuilt in Power Automate. They do not get carried forward to break later.

Workflow modernization is also an opportunity to simplify. Many legacy workflows encode workarounds for constraints that no longer exist. Rebuilding them in Power Automate — with the process owners in the room — often produces a simpler workflow that people actually follow, instead of a faithful copy of a process everyone had learned to work around.

5. Migrate in waves, validate every wave

Pilot first, then business-priority waves with validation after each. Nothing is declared done until users verify it.

Wave validation is what separates a migration from a move. After each wave, the content owners verify their content: it is there, it is the right version, the permissions are correct, the workflows run. Problems surface when they are small and fixable, not at the end when the whole estate has moved and the legacy platform is already decommissioned.

The migration that worked

Picture the alternative: an organization that inventories first and finds that a meaningful share of its content is dead. It archives that content, redesigns the architecture around how teams actually work, rebuilds permissions with named owners, modernizes workflows with the people who use them, and migrates in waves with validation after each. The legacy platform is decommissioned on schedule. Users arrive on the new platform to find content they can find, permissions that make sense, and workflows that work. The migration is remembered as the project that cleaned things up — not the project that moved the mess.

That outcome is not luck. It is the predictable result of treating migration as modernization.

The questions to ask before you sign

If you are evaluating a migration proposal, four questions separate the modernizers from the movers. Does the proposal include triage, or does it move everything? Are permissions rebuilt or copied? Are workflows modernized or carried forward? Is validation part of every wave, or a single check at the end? A proposal that answers all four correctly is a modernization proposal. A proposal that answers none of them is a lift-and-shift with better formatting.

The business case

Migration-as-modernization costs more upfront in planning — and far less overall, because you migrate less, you validate more, and you do not pay for a cleanup afterward. The estate that results is cleaner, governed, and cheaper to run than the one you left.

The cheapest migration is not the fastest one. It is the one you only have to do once.

Book a scoping call to plan a migration that modernizes — inventory, architecture, and waves, before anything moves.
Weekly newsletter
No spam. Just the latest releases and tips, interesting articles, and exclusive interviews in your inbox every week.
Read about our privacy policy.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.