The tool licence is rarely the expensive part of a SharePoint migration.
That statement surprises clients who have spent time comparing migration tools on price. The tool matters, but in almost every migration project that goes over budget or over time, the licence cost is a small fraction of the final bill. The expensive parts are the hours spent preparing data before the first file moves, the consultant time lost to throttled or failed migration runs, and the remediation work that lands in the first weeks after cutover when users discover that something did not transfer the way they expected.
This post names those costs directly. If you are scoping a SharePoint migration, whether cross-tenant after an acquisition, same-tenant restructure, or a full Microsoft 365 consolidation, these are the line items you need to account for before you commit to a timeline.
The pre-migration labour no one quotes for
Migration tools move data. They do not make decisions about what data is worth moving, what permissions should survive the transfer, what version history can be discarded, or what folder structure makes sense at the destination. All of those decisions require human judgement, and they have to be made before the migration job runs.
In a tenant that has been running for four or more years, the pre-migration audit alone is a multi-day project. A mid-size organisation with 200 SharePoint sites, each holding an average of 12 document libraries, has 2,400 libraries to assess. Some will be straightforward to migrate as-is. Others will have version histories that multiply the data volume by a factor of 10. Some will have broken permission inheritance with hundreds of unique permissions that will create chaos at the destination if not resolved first. A few will contain content that no one should migrate because the project they supported ended two years ago and no one ever cleaned up.
None of that assessment happens inside the migration tool. A SharePoint administrator or consultant handles it - reading reports, making calls, and documenting decisions. That labour is typically measured in days or weeks, not hours, and it rarely appears as a named line item in the initial project quote.
Version history is the most common source of pre-migration labour surprises. A 50 GB site that turns out to carry 480 GB of version history requires a decision: migrate with full history (multiplying transfer time tenfold), migrate with partial history (requiring a trim policy and a trim run before the job), or migrate current versions only (fast but losing the historical record). That decision and the work it triggers belongs in the project scope, not in the contingency.
How does version history multiply migration scope?
This is the single most underestimated dimension of SharePoint migration data volume, and it follows a consistent pattern.
- Current files are the visible number; version history is the hidden multiplier. The SharePoint admin center shows total storage per site, which includes current files and all historical versions. A site with 80 GB showing in the admin center might have 12 GB of current working files and 68 GB of version history. The migration tool, by default, will attempt to transfer all of it.
- Binary files have no compression between versions. Office documents (Word, Excel, PowerPoint) store binary diffs between versions, so each incremental save does not require a full copy. PDFs, images, ZIP files, and video files store a complete copy per version. A 5 MB PDF with 100 versions occupies 500 MB of version history. A library full of design exports, scanned documents, or CAD files can have a version-to-current ratio of 20:1 or higher.
- API throttling scales with data volume. SharePoint Online has throttling limits on how many API calls a migration tool can make per second and per day. A job migrating 2 TB of data including version history will encounter throttling events that a 200 GB job would not, and recovering from a throttle-induced pause can add hours or days to the migration window.
- Destination quota gets consumed on day one. Whatever version history you migrate arrives at the destination immediately. If you migrate a tenant's worth of six-year-old version history, the destination tenant starts its life partially full before any new work has been created there. Planning for quota at the destination without accounting for version history is a common cause of mid-migration quota errors.
The solution is to trim version history before the migration runs, not during or after. See the related post on trimming SharePoint version history before a migration for the specific approach and the decisions required.
The practical tool for this is Space Master's Version Trimmer, which runs a configurable keep policy across all libraries in the source tenant before any migration job is scheduled. Trimming to the last 20 versions per file ahead of a migration typically reduces the effective data volume to transfer by 60 to 80%, which directly reduces transfer time, throttling risk, and destination storage consumption.
Post-migration remediation: the cost that always surprises
Even well-prepared migrations produce a punch list of issues in the first two weeks after cutover. Some of these are expected and manageable. Others emerge because something about the source environment was undocumented, and the assumption built into the migration job turned out to be wrong in specific cases.
The most common post-migration remediation tasks:
| Post-migration issue | Why it happens | Effort to fix |
|---|---|---|
| Broken internal links in SharePoint pages and documents | Absolute URLs embedded in page content or Office documents still point to the source tenant. They break immediately at cutover. | Medium to high: requires a find-and-replace across all site pages and documents to update URLs |
| Permissions not as expected at the destination | Broken inheritance in the source is carried to the destination. Unique permissions on specific items that were intended to be temporary arrive as permanent structures. | Medium: permissions audit and cleanup at the destination, similar to what should have been done at the source pre-migration |
| Metadata columns missing or defaulted | Custom column types (managed metadata, lookup columns) do not always transfer correctly when the target term store or lookup list is not configured identically. | Low to high depending on how critical the metadata is to workflows |
| Large items in recycle bin consuming destination quota | The migration moved deleted items still in the source recycle bin along with current content, filling destination quota faster than expected. | Low: clear the destination recycle bins immediately post-migration |
| Empty folders arriving at destination | Folders without files in the source still get created at the destination, cluttering the library structure without contributing anything useful. | Low: bulk empty folder removal post-migration |
Broken internal links deserve specific attention because they affect every user immediately at cutover and are the most visible source of post-migration complaints. When a site has been in use for years, its pages, news articles, and embedded documents accumulate hundreds or thousands of absolute URLs that point to the old tenant. Replacing those URLs manually is not realistic. A find-and-replace tool that operates across all page content and list items simultaneously is the practical path; ShareMaster's Replace Master handles this at scale, searching for the old domain or URL pattern and replacing it with the destination pattern across all libraries and site pages in scope.
Building post-migration remediation into the project scope from the start is not pessimism; it is accuracy. Two to four weeks of follow-up effort is realistic for any migration of meaningful size. Scope it in from day one, or absorb it as overrun later.
Frequently Asked Questions
What takes the most time in a SharePoint migration?
Pre-migration data preparation consistently accounts for the largest share of elapsed time: cleaning up version history, mapping permissions, removing stale accounts, and identifying content that should not be migrated at all. The data transfer itself is rarely the bottleneck. It is the assessment and cleanup work required before the first file moves that most project timelines underestimate.
How does version history affect SharePoint migration cost?
Version history multiplies the effective data volume being migrated. A site whose current files total 50 GB can carry 400 to 600 GB of version history. If version preservation is enabled, the migration tool must read, transfer, and write all of it. That multiplier increases transfer time, API throttling risk, and destination storage consumption from day one. Trimming version history before migration reduces all three directly.
What should be fixed in SharePoint before starting a migration?
Before scheduling a migration job, address: version history (trim to a keep policy of 20 to 30 versions per file to reduce data volume); permissions (remove stale accounts and resolve broken inheritance so problems do not arrive at the destination); empty folders (remove them to avoid cluttering the destination library structure); and content scope (identify what does not need to migrate at all and exclude it from the job rather than cleaning it up at the destination later).