TL;DR:
A SharePoint migration without a clear plan is how projects go over budget, miss deadlines, and arrive broken. This blog walks through the essential steps every company needs in their SharePoint migration plan
The moment a SharePoint migration starts without a clear plan, fixing problems becomes significantly more expensive.
According to Gartner, 83% of data migration projects either fail or overrun their budgets and schedules. That’s the default outcome when planning gets treated as a formality instead of a foundation.
The companies that land in the other 17% are not the ones with the simplest environments. They’re the ones that knew exactly what they were migrating, where it was going, and what could go wrong, before a single file moved.
This blog walks through the essential steps every company needs in their SharePoint migration plan, what each step involves, and where teams most commonly get it wrong.
Step 1: Run a Content Audit Before Anything Else
Even though you might assume you know every file and folder you have stored in your SharePoint, it’s still good practice to audit it.
Content may have accumulated over the years, files with names that violate SharePoint’s character limits, and path lengths that will fail during deployment. Migrations that skip this step don’t just carry useful content to the new environment. They carry everything, including the mess.
A proper content audit identifies:
- Total data volume and file count
- Duplicate and redundant files that should be cleaned before migration
- File names with invalid characters or path lengths that exceed SharePoint’s limits
- Oversized files that breach SharePoint’s size thresholds
- Content that should be archived rather than migrated
Tzunami’s Pre-Migration Analyzer automates this entirely. It scans the source environment and generates five types of pre-migration reports covering data volume, file distribution, path length violations, invalid characters, and file extensions. Results are exported to CSV for deeper analysis.
Step 2: Define the Target Environment Before Migration Begins
Moving content into SharePoint without defining where it’s going is like packing boxes without knowing which room they’re for.
Before migration starts, define:
- Site and library structure — how content will be organized in SharePoint Online
- Content types and managed metadata — taxonomy needs to exist in the term store before content arrives,
- Naming conventions — consistent across the new environment from day one
- Permission model — how users and groups will be structured in the target
If the term store isn’t built before content migrates, managed metadata columns arrive blank.
Step 3: Map Your Permissions
Permissions are the most technically complex part of any SharePoint migration plan. They are also the most consequential.
Get permissions wrong, and two things happen simultaneously: some users can’t access content they need, and others can access content they shouldn’t.
A permission plan needs to address:
- How source system permissions map to SharePoint’s security model
- What happens to broken inheritance — carry it forward, clean it up, or restructure it
- How external users and guest accounts are handled at cutover
- What happens to permissions for users who have left the company
Tzunami Deployer transfers security settings, users, groups, and permissions alongside content. For companies migrating from Documentum, OpenText, Confluence, LiveLink, and other ECM systems, it maps permissions from the source model to SharePoint’s, including cross-domain scenarios where the source and target sit on different LDAP directories.
Step 4: Plan Your Metadata Migration
Metadata is what makes content useful inside SharePoint. It powers search and drives workflows. It is also what most migration tools treat as secondary to the files themselves.
Before migration, the metadata plan needs to cover:
- How source system fields map to SharePoint columns and content types
- Which managed metadata values need to exist in the term store before content arrives
- How invalid values — incorrect date formats, numeric fields stored as text — will be corrected
- What happens to source fields that have no SharePoint equivalent
Tzunami Deployer maps metadata from the source ECM system to SharePoint’s model automatically, correcting invalid values before deployment.
Step 5: Choose Your Migration Approach
There’s no single migration approach that works for every company. The right strategy depends on your environment, business requirements, and tolerance for downtime.
| Approach | Best For | Trade-Off |
| Big/All at once | Small environments, tight timelines | Higher risk, requires a downtime window |
| Phased | Large environments, multiple departments | Lower risk, longer overall timeline |
| Pilot first | Any enterprise migration | Adds time upfront, surfaces problems early |
| Hybrid | Complex multi-source environments | Most control, most coordination |
For most enterprise migrations, a phased approach with a pilot is the right call. Migrate 5 to 10% of content first — one department, one site collection — validate it completely, fix what breaks, and then scale.
Here’s what that looks like in Practice
For instance, a pharmaceutical company migrating from Documentum to SharePoint Online runs a pilot with its legal department before touching anything else. The pilot revealed over 300 invalid metadata values in their term store — values that would have caused managed metadata columns to arrive blank across 80,000 documents. Catching it in the pilot took two days to fix. Catching it post-migration across the full environment would have taken weeks and required a partial remigration.
The pilot phase is the work that protects everything that comes after it.
Step 6: Build Delta Migration Into the Schedule
Content doesn’t stop being created because a migration is in progress. Documents get added. Existing ones get modified. If the plan doesn’t account for this, content created during the migration window simply won’t exist in the new environment at cutover.
Delta migration closes that gap. It captures content that changed or was added after the initial migration run and picks it up in subsequent passes — so the final state of the source environment is fully reflected in SharePoint before cutover.
A delta plan needs to define:
- When the initial migration run takes place
- How many delta passes are planned before cutover
- When the source goes read-only for the final delta run
- Who confirms outstanding delta items are at zero before the source is decommissioned
Tzunami Deployer supports delta migration natively. Subsequent passes pick up only what changed, with no full re-run required.
What Is the Most Common Mistake Companies Make With Their SharePoint Migration Plan?
Treating planning as the thing they do before the real work starts and rushing through it to get to migration faster.
Planning is the real work. Every hour spent in discovery, content audit, permission mapping, and metadata design saves multiples of that time during migration and more again in post-migration cleanup.
Companies that skip proper planning don’t just underestimate scope. They discover the actual scope mid-migration, when fixing it costs three times as much and impacts everyone already working in the new environment.
Conclusion
A SharePoint migration plan is not a document that satisfies a project management requirement. It is what tells you what you have, where it’s going, how permissions and metadata will travel with it, what happens to content that changes during the migration, and how you’ll know the migration actually worked when it’s done.
None of those questions answer themselves after go-live. They need to be answered before a single file moves, and the SharePoint migration plan is where that happens.
Frequently Asked Questions
1. What should a SharePoint migration plan include
A content audit, target environment design, permission mapping, metadata plan, migration approach, delta migration strategy, and post-migration validation criteria.
2. How long should the planning phase take
For small migrations, one to two weeks. For enterprise migrations, four to eight weeks is realistic and worth every day.
3. What happens if you skip the content audit?
You migrate everything, including duplicates, invalid file names, path violations, and metadata problems. These surface mid-migration when they’re far more expensive to fix.
4. Should permissions be migrated before or alongside content?
Alongside. Separating them creates a window where content exists in the target without access controls. Tzunami Deployer handles both simultaneously.
5. What is delta migration?
It captures content that changed or was created after the initial migration run. Without it, content modified during the migration window is missing at cutover.
