Migration is the most misunderstood work in this report, because almost everyone still describes it as a project. Projects end. This doesn't.

Once compliance clears the path, the work becomes movement CH 5Compliance→. And the movement does not stop. Organizations acquire, divest, restructure, consolidate, and modernize on a rolling basis, and each of those events produces a migration. The data shows teams working through several, finishing one and starting another, and consistently wishing they'd treated it as a capability the first time round.

94% of organizations migrated something in the past two years, and those that did averaged 2.5 migration types completed, underway, or planned across the 24-month period. 6% stood still. Of the teams that moved anything, 81% ran two or more kinds of migration inside the same 24 months and half ran three or more. That's the case for treating migration as an operating capability rather than an event: the average team isn't between migrations, it's working through two or three of them.

Laura Rogers sees the same pattern from inside the projects.

Nearly a quarter of organizations say their biggest migration was driven by a merger, acquisition, or divestiture. The cost chapter found that cost pressure is a moderate or major driver of migration and consolidation for 88% of organizations, and duplicate M&A tenants are among the largest cost lines in the estate CH 2The AI reckoning→. The two findings describe the same cycle from different ends. Add consolidation and restructure work and 35% of the most significant projects were driven by organizational change rather than technology strategy.

This is the structural reason migration never ends. Cloud migration has a finish line, at least in principle. Corporate change does not. As long as organizations keep buying, selling, and reorganizing, tenant-to-tenant work keeps arriving. It arrives on someone else's timetable, with a deal deadline attached.

Constant motion leaves a trace. Teams that ran three or more kinds of migration in the past two years are more likely to report a governance incident than teams that ran one: 83% against 68%. The sharpest split is shadow IT and shadow AI, where people pick up tools, apps or automations outside IT's line of sight. That one doubles.

The survey can't tell you which way that runs. Repeated migration may leave sprawl behind, or the teams generating the most sprawl may be the ones restructuring most often. Both are plausible, and the pattern shows up in all five company size bands. What it does establish is that heavy migration activity and governance debt turn up in the same places.

We asked the MVPs why that debt accumulates rather than clears. David Drever put it down to change management rather than tooling.

Decay is the right word for it. 77% of organizations reported a governance incident in the past year, and the teams moving most often are the ones furthest into that number CH 3Governance→.

How long it takes

Planning benchmarks matter when the timeline is set by a deal rather than by IT.

Most projects land in the 3 to 6 month band, but more than a third take seven months or more, including 10% that exceed a year. Read that against the M&A finding and the tension is obvious: a significant share of migrations are triggered by transactions whose integration deadlines are set in a boardroom, and the typical project takes half a year. Teams who haven't pre-built the capability are being asked to compress a six-month process into whatever the deal timeline allows.

Last year's report asked the same question of M&A migrations, so that's the one group where the two years compare. One band moved enough to mention.

Treat that as a direction rather than eleven exact points: last year's figure comes from a dedicated M&A module of 520 people, this year's from the 214 whose biggest project was a deal. The other bands drifted a few points each and none of them says much on its own. What thinned out is the quick one.

Why teams move

Teams could name up to three reasons. One of them is new this year.

Security and scalability remain the top two, as they were last year, though they've swapped places: in 2025 scalability led at 65% with security a point behind at 64%. Every driver scores lower in absolute terms this year, which likely reflects a change in how the question was asked rather than a collapse in motivation, so read the ranking rather than the levels. The newcomer worth watching is AI readiness, now a named driver for more than a quarter of organizations.

Two years ago AI readiness wouldn't have appeared on this list. It's now cited more often than end-of-support deadlines, and it connects this chapter directly to the first: content has to be somewhere Copilot can reach it, governed well enough that reaching it is safe CH 1Confidence ≠ control→.

Mike Maadarani described what that looks like at the moment of the move.

What actually moves when a tenant moves

Scoping a tenant move starts with this list, and it runs longer than most teams expect.

Power Platform tops the list. That should reset the scoping conversation. The assumption that tenant-to-tenant work is mostly mail and files is out of date, and it's the assumption most likely to produce a mid-project surprise. Apps, flows, and connectors are the most commonly in-scope workload, they hold their own permissions and connections, and they're frequently owned by someone outside IT who built them for a purpose nobody documented. The estate chapter covers what this says more broadly CH 4The estate→.

A third of these projects also involve Google Workspace, which is worth noting for anyone assuming cross-platform work is a niche case.

Power Automate flows are also the example named in the shadow IT question earlier in this chapter, the incident type that nearly doubles as migration volume rises. The workload teams most often have to move is the one they're least likely to have documented.

What teams use to move

Most teams don't pick a tool. They pick several.

That's the shape of a field where teams are stacking approaches rather than swapping them, which is what you'd expect from teams running two or three kinds of migration every two years. Native tools are the floor almost everyone builds on. What changes is what gets added on top, and how soon.

What teams would do differently

We asked the teams who'd already finished one what they'd change.

Only 7% would change nothing. The top three regrets are all the same shape: plan earlier, tool earlier, clean up earlier. Hindsight is the most honest advice in any survey, because the person giving it has already paid for the lesson. Three of the top four answers describe work that should have happened before the project started.

What actually predicts buying a tool

Not the size of the company. How much migration it runs.

The obvious objection is that this is really a story about company size. Bigger companies run more migrations and buy more software. It isn't. The same pattern shows up inside every size band in the study, and it's widest in the largest one.

The regret climbs the same way. Among teams that ran one kind of migration, 27% wish they'd bought tooling sooner. At three or more, 43%. Over the same range, the share saying nothing went wrong halves.

Split the same question by what teams actually bought and the answer lands in a place worth sitting with.

36% find identity preparation difficult or the single hardest part. Another 40% call it manageable while noting it could be easier, which is a polite way of saying it works but costs more than it should. More than four in five want identity preparation handled inside the migration tool rather than bolted on. Now the number that turns that preference into a gap.

That gap explains the difficulty scores above. More than four in ten teams are doing identity prep in a separate Microsoft tool, and another 41% are doing it by hand in the admin center or with scripts. The step teams find hardest is the step most often handled outside the workflow that everything else runs in.

The difficulty does track with the method, though the bases get small quickly. Teams using PowerShell scripts report the most difficulty, while the small group with identity built into their migration tool reports the highest ease. That last group is only 34 people, so read it as a direction, not a decimal.

Identity and permissions occupy two of the top three. M&A projects also run longer. 39% pass the six-month mark against 34% of on-premises-to-cloud moves, on timelines usually set by a transaction rather than by IT.

The planned, happy-path portion of a migration, the part every tool demos well, rarely breaks a project. What breaks projects is everything that wasn't fully scoped: the customization nobody documented, the permission that doesn't map, the Power Platform flow that surfaces halfway through, the coexistence window that runs longer than planned.

The mailbox picture reinforces it: identity prep is the second-largest challenge, and coexistence, which is largely an identity and routing problem, is third. Which reframes what tooling is actually for. Automating the predictable steps has value, but the predictable steps were never the risk. The tooling that earns its cost is the tooling that absorbs the exceptions, and it earns it repeatedly, because a team running 2.5 migration types every two years will meet those exceptions again.