SharePoint Migration: Planned in Waves, Validated Before Cutover
A SharePoint migration is never really about moving files. Files move easily. What breaks — what always breaks, in migrations run as file-copy projects — is everything attached to the files: permissions that don't map, workflows that silently stop firing, InfoPath forms that have no destination, Power Apps that lose their data source mid-quarter, and links in ten years of email that now go nowhere.
We plan migrations around the things that break, not the things that copy. That's the difference between a migration and a move, and it's the operating rule across our whole SharePoint practice.
Why organizations migrate now
Migrations rarely happen because someone woke up wanting one. They happen because a trigger fires:
- SharePoint Server support windows are closing. Staying on-premises means paying more each year for less — more infrastructure, more patching, fewer features, and no path to Copilot. Microsoft has set this direction; the only open question is whether you move on your schedule or theirs.
- A merger or divestiture forces tenant consolidation. Two tenants, two permission models, two intranets, one deadline.
- File shares, Google Workspace, Dropbox, or Box content needs to come into Microsoft 365 — usually because the organization is consolidating licensing, tightening security, or preparing for Copilot, which can only reason over content it can reach.
- Legacy workloads are failing. InfoPath is retired with no successor. SharePoint Designer 2010 workflows are retired; 2013 workflows are on borrowed time. When those break, the migration conversation stops being strategic and starts being urgent. If that's where you are, start with our workflow modernization and InfoPath migration pages — those workloads need their own exit plans inside the larger move.
- Copilot is coming, and the estate isn't ready. A migration is the natural moment to fix permissions and retire stale content, because you're touching everything anyway.
Why migrations fail
Migration is the one moment when restructuring is nearly free, because users expect change.
The failure patterns are consistent enough that we can list them. If your migration plan doesn't address each of these by name, it isn't a plan yet.
Permissions don't survive the trip.
Item-level permissions, broken inheritance, and user accounts that no longer exist don't map cleanly to a new environment. Migrating them as-is preserves chaos; dropping them creates exposure. The right answer is a permissions redesign — group-based, auditable, least-privilege — executed as part of the move, not deferred to "phase two," which never comes.
Workflows and forms are discovered too late.
Designer workflows and InfoPath forms don't appear in a file inventory. Teams discover them when a business process stops working after cutover. The census has to include every workflow, form, and customization before the first byte moves.
Information architecture gets copied instead of designed.
Lifting a decade of accumulated folder sprawl into a new tenant produces a new tenant with a decade of folder sprawl. Migration is the one moment when restructuring is nearly free, because users expect change. Skipping it wastes the moment — SharePoint modernization and migration are cheapest done together.
Connected applications are treated as someone else's problem.
Power Apps reading SharePoint lists, flows moving documents, Power BI reports querying libraries — these break when their sources move. Because we work on both the content layer and the app layer, we inventory these dependencies up front and re-point them as part of the wave, not as a surprise afterward.
Everything moves at once.
Big-bang cutovers concentrate all risk into one weekend. When something goes wrong — and in a large estate, something goes wrong — there's no way to isolate it.
How we run migrations
Our migrations follow the IMP0WER GRID, the same published methodology behind every engagement — you can read it in full on our methodology page.
Gauge.
A complete census of the source estate: sites, libraries, lists, permissions, workflows, forms, customizations, connected apps and flows, and usage signals that separate the living content from the dead. Most organizations are surprised by what this turns up; that's the point of doing it first.
Route.
The target design and the wave plan. Which content moves, which gets archived, which gets deliberately retired. The new information architecture and permission model. Wave sequencing by business area, with dependencies mapped so no team loses a working tool mid-wave. Effort ranges per wave, so the schedule is grounded in evidence instead of optimism.
Install.
Execution, wave by wave, using ShareGate and AvePoint tooling — platforms our founder has used to lead Microsoft 365 migrations at enterprise scale. Every wave gets pre-migration validation, the move itself, post-migration verification against the source, and a hypercare window where the team that moved the content is on hand while users settle in.
Migrated estates are held to the same Ø Standard as everything else we ship: named owners, auditable access, documented handoffs, and a support path after go-live.
The risks, and how the plan absorbs them
| Risk | What it looks like | How the plan absorbs it |
|---|---|---|
| Permission drift | Users can suddenly see too much — or nothing | Permission redesign in Route; verification per wave |
| Silent workflow loss | A business process just stops | Full workflow and form census in Gauge; rebuild plan per item |
| Broken app dependencies | Power Apps and flows fail after their lists move | Dependency inventory; re-pointing inside each wave |
| Content overrun | The estate is bigger and messier than believed | Census before commitment; archive-and-retire decisions up front |
| User revolt | People can't find their files | IA designed with department input; communication per wave; hypercare |
Where to start
Every migration we run starts with the SharePoint Modernization Blueprint — a fixed-price assessment: $7,500 focused, $15,000–$25,000 deep for large or regulated estates. You get the census, the exit maps for InfoPath, Designer, and Nintex, and a wave plan with effort ranges. The Blueprint stands on its own: if you take it to another firm, or run the migration internally, it still works. If you engage us, 100% of the focused-tier fee is credited toward any implementation engagement of $25,000 or more signed within 90 days of your readout.
Frequently asked questions
How long does a SharePoint migration take?
It depends on the size of the estate, the number of workflows and forms that need rebuilding rather than copying, and how much restructuring you take on during the move. Anyone who quotes a duration before running a census is guessing. The Blueprint exists to replace that guess with a wave plan and effort ranges you can hold us to.
What actually drives the cost?
Not volume of files — tooling handles volume well. Cost concentrates in the exceptions: item-level permissions to redesign, Designer workflows and InfoPath forms to rebuild in Power Automate and Power Apps, customizations with no modern equivalent, and connected applications to re-point. The census quantifies each category, which is why we price implementation after the Blueprint rather than before it.
Will our teams lose access during the migration?
Waves are sequenced and communicated so each team has one defined cutover window, not months of uncertainty. Source content stays readable until its wave is verified. Hypercare after each wave means problems get fixed by the people who just moved the content.
Can you migrate our Nintex workflows too?
Yes — usually by rebuilding them in Power Automate rather than carrying the licensing forward. Whether that's the right call depends on how many workflows still earn their keep; the census answers that. See workflow modernization for how we handle the decision.
We already started a migration and it's stuck. Can you take over?
Yes. Rescue engagements start the same way: Gauge what's moved, what's broken, and what's left, then re-plan the remaining waves. Partial migrations are recoverable; the census tells us how much of the earlier work is salvageable.
Do we clean up before we migrate, or migrate and then clean up?
Cleanup decisions happen before; cleanup execution happens during. Deciding what to archive and retire belongs in Route, so you don't pay to move content nobody will ever open. Deferring all cleanup until after the move is how new tenants inherit old problems, and how Copilot rollouts surface files nobody meant to share.