SharePoint Migration: Why It Fails and How to Get It Right
SharePoint migration is the process of moving content, permissions and structure from one SharePoint environment, or another platform entirely, into SharePoint Online.
It sounds simple. In practice, it is the stage where most SharePoint projects run into trouble, not because the tools are unreliable, but because the planning behind them usually is.
Most organisations only think about migration once they have already decided to move. By then, the technical question, which tool to use, has usually taken over the conversation, while the harder question of what should actually be moved, and in what order, gets far less attention than it deserves.
That imbalance is where most of the problems in this article start.
Get it wrong, and the consequences rarely show up straight away. A migration can look complete on the surface while permissions are too open, metadata is missing, and version history has quietly gone missing.
None of that tends to surface until an audit, a data request, or a frustrated user forces the issue months later, by which point it costs far more to fix than it would have to get right first time.
If you strip away the technical detail, most SharePoint migrations succeed or fail for the same handful of reasons:
- Migration tools like Microsoft’s SharePoint Migration Tool (SPMT) and third-party options such as ShareGate rarely cause the problems people blame them for
- Most failed migrations trace back to poor assessment of source content before the move ever starts
- Permissions, metadata and version history are the three things most commonly lost or broken
- A phased approach beats a single “big bang” migration for anything beyond a small, simple site
- The right tool depends on complexity, not preference: SPMT suits straightforward lift-and-shift jobs, while ShareGate and similar tools earn their cost on anything requiring transformation or heavy reporting
None of this is really about the technology. It is about how much thought goes in before anyone opens a migration tool at all, which is exactly what the rest of this article covers.
Why migrations go wrong more often than they should
Ask most IT teams what worries them about a SharePoint migration and they will usually mention the tool. Will it cope with the volume? Will it break something? Will it take forever?
In our experience, the tool is rarely the problem. What causes migrations to overrun, or to land in a worse state than before, is almost always what happens, or does not happen, before a single file gets moved.
Organisations often start migrating content they have never properly audited. Old file shares, legacy intranets, and years of undocumented folder structures get pointed at a migration tool with the assumption that everything will sort itself out on the other side. It does not. The tool will move exactly what you tell it to move, including duplicate files, outdated permissions, and structures that made sense in 2015 but nowhere else since.
What actually gets broken in a migration
Three things account for the vast majority of post-migration headaches.
Permissions. SharePoint permissions are inherited, layered and often edited manually over years by well-meaning administrators. A migration that does not map permissions deliberately will either carry over a mess, or default to broader access than intended, which creates a security problem rather than solving an organisational one.
Metadata. Content that relied on folder structure for organisation does not automatically gain metadata just because it has moved to SharePoint. If metadata was not planned before migration, it is rarely added afterwards, because nobody has the time once the project is technically “done”.
Version history. Some migration paths, particularly quick file-share transfers, do not preserve version history by default. For organisations with any compliance or audit requirement, this can be a serious gap that only surfaces months later, when someone asks for a document as it existed six versions ago.
Choosing the right migration tool
Microsoft’s own SharePoint Migration Tool (SPMT) is a solid, free option for straightforward lift-and-shift migrations: moving on-premises SharePoint content or simple file shares into SharePoint Online without significant restructuring. It handles documents, lists, libraries and sites, and manages the underlying transfer through Microsoft’s own migration API.
Where SPMT tends to fall short is on anything more complex. If you need to reorganise content as part of the move, add or correct metadata during migration, or get detailed pre-migration reporting to catch problems before they happen, a tool such as ShareGate is usually the better investment. It costs more, but the time saved in planning, auditing and post-migration clean-up generally justifies it for anything beyond a small, simple site.
Neither tool solves the planning problem on its own. That still has to come from the organisation, or from whoever is running the project.
What a properly planned migration actually looks like
Assess before you move anything. Understand what content exists, who actually uses it, and what can be archived or deleted rather than migrated. Migrating everything is rarely the right call; it is simply the path of least resistance.
Decide your priorities and sequencing. Not every team needs to move on day one. A phased migration, moving lower-risk content first, gives you room to catch and fix problems before they affect the whole organisation.
Map permissions deliberately. Do not assume existing permissions are correct just because nobody has complained about them. Migration is the natural point to clean this up, not just replicate it.
Package content sensibly. For tools like SPMT, transferring in reasonably sized batches, generally in the region of 100 to 250 megabytes per package, tends to keep uploads faster and more reliable than attempting everything in one pass.
Plan for what happens after migration, not just during it. Metadata tagging, permission reviews and user training all need to happen close to go-live, not as an afterthought once attention has moved to the next project.
A recent example
On a recent migration for a mid-sized professional services client, the biggest risk was not the technology, it was history. Fifteen years of file shares had never been properly categorised, and permissions had been added and adjusted by several different administrators over that time with no consistent logic. Rather than migrating everything as-is, the first four weeks of the project were spent purely on assessment and permission mapping before a single file was moved. The migration itself, once it started, took a fraction of that time and produced none of the access or duplication problems that a straight lift-and-shift would almost certainly have created.
That pattern holds in most of the migrations we see. The move itself is rarely the hard part.
If you are weighing up a SharePoint migration and want a second opinion on the approach before committing to a tool or a timeline, our SharePoint Migration Services team can talk you through what a properly planned migration looks like for your specific environment.
The bottom line on SharePoint migration
SharePoint migration tools have become genuinely good at the mechanical part of the job: moving files, preserving structure, and doing so securely. What they cannot do is decide what should be moved, how it should be organised, or who should have access to it once it lands. That is still a planning exercise, not a technical one, and it is where the vast majority of migration problems actually originate.
Get the planning right, and the migration itself tends to be the easiest part of the whole project.
Frequently Asked Questions
Is the SharePoint Migration Tool (SPMT) good enough on its own?
For simple, low-complexity migrations, yes. SPMT handles straightforward transfers from on-premises SharePoint or file shares into SharePoint Online reliably and at no cost. It becomes less suitable once you need restructuring, metadata changes, or detailed reporting as part of the move.
How long does a typical SharePoint migration take?
This depends far more on the assessment and planning stage than on the technical transfer. A well-planned migration for a mid-sized organisation often spends more time on audit and permission mapping than on the actual data transfer, which is usually the fastest part of the project.
Will we lose version history when we migrate to SharePoint?
Not necessarily, but it depends on the migration path and tool used. Some quick file-share transfers do not preserve version history by default, so this needs to be confirmed and planned for before migration, particularly if you have compliance or audit obligations.
Should we migrate everything, or leave some content behind?
In most cases, some content should be left behind. Migrating everything by default usually just moves an existing mess into a new environment. An assessment stage before migration should identify what is actually still in use.
What is the difference between SPMT and ShareGate?
SPMT is Microsoft’s free tool, best suited to simple lift-and-shift migrations. ShareGate is a paid third-party tool that offers more detailed pre-migration reporting, easier handling of metadata and permissions during the move, and more flexibility for complex migrations. For further detail on the official tool, see Microsoft’s SharePoint Migration Tool documentation.
Can we train our own team to manage SharePoint once the migration is complete?
Yes, and it is worth planning for. Our SharePoint training courses cover day-to-day administration and best practice for teams taking on SharePoint management after a migration project.