SharePoint Data Migration: The Complete Guide for UK Businesses

Introduction

SharePoint data migration is one of the most technically and organisationally complex tasks in a SharePoint project — and one of the most consistently underestimated. It is the phase that organisations most often rush, most often under-resource, and most often regret having not taken more seriously. It is also, when done properly, the phase that sets the foundation for a SharePoint environment that employees trust, use with confidence, and find genuinely useful.

The appeal of migration is obvious. You have years of content — documents, policies, spreadsheets, presentations, forms — stored somewhere that is no longer fit for purpose. A file server that is slow, ageing, and impossible to access remotely. A legacy intranet platform whose licence is expiring. A SharePoint on-premises environment that the business wants to move to the cloud. An old collaboration platform — Confluence, Google Drive, a shared Dropbox — that the organisation has outgrown. Moving that content to SharePoint Online is a necessary step in the journey to a better digital workplace.

The challenge is that content migration is not simply a matter of copying files from one place to another. The content that has accumulated in most organisations over years or decades is complex, heterogeneous, and frequently in poor condition. It contains duplicates. It contains outdated versions of superseded documents. It contains content that was never properly organised, never properly named, and never clearly owned. Moving it wholesale into a new environment does not solve the underlying problems — it imports them into a clean space, contaminating it immediately.

This guide provides a comprehensive framework for approaching SharePoint data migration with the rigour that it deserves — from the initial content audit through to governance, tooling, testing, go-live, and post-migration support.

NetMonkeys is a Microsoft 365 specialist consultancy with extensive experience delivering SharePoint data migrations for UK businesses. 

Understanding What You Are Migrating — The Content Audit

The most valuable investment you can make at the beginning of a SharePoint data migration is time spent understanding your existing content estate before migrating a single file. A content audit — a systematic assessment of what content you have, where it lives, who owns it, and whether it should be migrated — is the foundation of every successful migration we have delivered at NetMonkeys.

Most organisations, before conducting a content audit, significantly underestimate the volume of their content estate and overestimate its quality. The reality is typically that a file server or legacy platform hosting fifty thousand files contains:

A large proportion of duplicate files — the same document saved multiple times, often under different names or in different folders, with no clear indication of which is the most current version.

A significant proportion of obsolete content — documents relating to projects completed years ago, policies that have been superseded, templates for processes that no longer exist, and files that nobody has opened in three or more years.

A proportion of trivial or personal content — content that was never appropriate for a shared environment, including personal files, draft documents that were never completed, and files that have no relevance to any current business process.

And a proportion of genuinely valuable, current content that should be migrated — the policies, templates, procedures, and reference documents that employees actually need and use.

A good content audit separates these categories. It gives you a clear picture of what you actually have, allows you to make informed decisions about what to migrate and what to leave behind, and produces a content inventory that serves as the migration manifest — defining exactly what will move, where it will go, and in what form.

How to Conduct a Content Audit

A content audit at scale — covering a file server with tens or hundreds of thousands of files — requires automated tooling alongside human judgement. Tools like SharePoint Migration Assessment Tool (SMAT), provided free by Microsoft, analyse existing file servers and SharePoint on-premises environments and produce reports on content volume, file types, permissions structures, and potential migration issues.

These automated reports provide the quantitative picture. The qualitative picture — which content is valuable and which is not — requires human review. For large content estates, a sampling approach is practical: review a representative sample of content from each major area, assess its quality and relevance, and apply the findings across the broader category.

The output of the content audit is a content inventory and classification — a document that categorises every significant area of content as Migrate, Archive, or Delete. Migrate content is current, relevant, and needed in the new SharePoint environment. Archive content may need to be retained for compliance or reference purposes but does not need to be actively accessible in the primary SharePoint environment. Delete content has no ongoing value and should not be moved.

The willingness to be decisive about the Delete category is one of the most important factors in a successful SharePoint data migration. Organisations that migrate everything — on the grounds that it might be useful, or that it is too difficult to make decisions about individual files — create SharePoint environments that are immediately cluttered with content that should have been discarded. Every file that is not migrated is a file that does not need to be organised, maintained, searched, or explained in the new environment.


Designing the Target Information Architecture

Before any content is moved, the destination needs to be ready. Designing the target SharePoint information architecture — the structure of sites, document libraries, folders, and metadata that content will be migrated into — is as important as the migration itself.

This is where many organisations make their most consequential mistake. They design the destination SharePoint structure to mirror the source structure — replicating the folder hierarchy of the file server or the site structure of the legacy platform in SharePoint. This approach is tempting because it minimises the apparent complexity of the migration — content goes to a place that looks like where it came from. But it perpetuates the structural problems of the source environment rather than solving them.

SharePoint is not a file server. Its document library capabilities — version control, metadata, content types, search integration, co-authoring, and workflow — are most effectively used in a different structural model from the deeply nested folder hierarchies that file servers encourage. A document library with well-applied metadata and a flatter folder structure is significantly more usable and maintainable than a document library that replicates a complex folder tree.

Designing the target information architecture means asking — for each category of content that will be migrated — where does it belong in the new SharePoint environment, what document library should it live in, what metadata should be applied to it, who should have access to it, and how should it be named? These decisions should be made before the migration begins, documented clearly, and validated with key stakeholders before any content is moved.

Site structure decisions. Which content belongs in the corporate intranet, which in departmental sites, which in team collaboration sites? Content that is published and consumed by a broad audience belongs in communication sites. Content that is actively worked on by a defined team belongs in team sites. Content that is archival belongs in a designated archive site or an archiving solution. 

Document library design. Libraries should be named for the content they contain, not generically. Metadata columns — document type, status, owner, review date, department — should be defined and consistently applied across libraries of the same type across all sites. Folder use should be deliberately limited. Where folders are used, they should be used sparingly and with consistent naming conventions.

Naming conventions. File names in a migrated SharePoint environment should follow consistent conventions — clear, descriptive names that identify the content without needing to open the file. Acronyms and internal shorthand that make sense to the original creator but confuse everyone else should be expanded. Date formats in file names should be standardised — YYYYMMDD is sortable and unambiguous.

Permissions mapping. The permissions that govern access to content in the source environment need to be understood and deliberately replicated — or deliberately revised — in the destination. Permission mapping is one of the most labour-intensive aspects of a SharePoint data migration, and one of the most important. Under-permissioning locks users out of content they need. Over-permissioning exposes sensitive content to audiences that should not see it.


Choosing a SharePoint Data Migration Tool

Microsoft provides a free SharePoint Migration Tool (SPMT) that handles migrations from file servers, SharePoint on-premises, and SharePoint 2010-2019 environments to SharePoint Online. For straightforward migrations of moderate scale, SPMT is a capable and cost-effective option.

For larger, more complex migrations — or those involving source environments other than file servers and SharePoint on-premises — enterprise migration tools provide capabilities and performance that go beyond what SPMT offers. The most widely used enterprise SharePoint migration tools in the UK market include:

ShareGate is one of the most popular tools for SharePoint and Microsoft 365 migration. It provides a clean interface, strong metadata handling, granular permission migration, delta migration capabilities (allowing content added after an initial migration run to be captured in a follow-up pass), and detailed migration reports. ShareGate is well-suited to mid-market migration projects.

Metalogix Content Matrix provides enterprise-grade migration capabilities with sophisticated transformation rules — allowing content to be restructured, renamed, and re-permissioned as part of the migration process rather than as a separate step. It is suited to large, complex migrations where significant structural changes are being made.

Avepoint Fly offers a cloud-native migration platform that supports a wide range of source environments including Google Drive, Dropbox, Box, and legacy on-premises systems, as well as SharePoint on-premises. Its cloud architecture makes it well-suited to migrations that run continuously over extended periods.

AvePoint Cloud Backup provides the ability to run SharePoint migrations alongside backup and recovery capabilities — useful for organisations that want ongoing backup of their SharePoint Online environment beyond what Microsoft’s native retention provides.

The right tool depends on the scale and complexity of the migration, the source environment, the degree of structural transformation required, and the budget available. NetMonkeys selects migration tooling based on the specific requirements of each engagement rather than defaulting to a single tool regardless of fit.


The Phases of a SharePoint Data Migration

A well-managed SharePoint data migration follows a structured phased approach that minimises risk, validates each stage before proceeding to the next, and maintains momentum without sacrificing quality.

Phase 1 — Discovery and Planning

The discovery phase encompasses the content audit, the target information architecture design, the permissions mapping, the tooling selection, and the project planning. The output of discovery is a Migration Plan — a document that defines what will be migrated, where it will go, in what order, using what tools, by what timeline, and governed by what process.

The Migration Plan is the single most important document in a SharePoint data migration project. It is the reference point for every migration decision that follows, the document that stakeholders sign off before migration begins, and the baseline against which the migration’s success is measured. Time invested in producing a thorough Migration Plan pays back many times over in reduced complexity and rework during the migration phases that follow.

Phase 2 — Destination Preparation

Before any content is migrated, the destination SharePoint environment needs to be built and validated. Sites need to be created, document libraries need to be configured with the correct metadata columns and content types, permissions need to be established, and navigation needs to be in place.

The destination preparation phase also includes user acceptance testing of the destination structure with a representative group of users — validating that the site structure and navigation are intuitive before any content is added, and identifying any structural issues that would be much more difficult to address after migration.

Phase 3 — Pilot Migration

Before migrating the full content estate, a pilot migration of a representative subset of content — typically one or two document libraries or a single department’s content — validates the migration tooling configuration, the metadata mapping, the permissions replication, and the destination structure. The pilot produces real migration output that can be inspected, tested, and validated by stakeholders before the full migration runs.

Issues identified in the pilot — metadata that is not mapping correctly, permissions that are not replicating as expected, file names that are violating SharePoint’s character restrictions, files that are too large to migrate — are resolved before the full migration runs. The pilot is the quality gate that prevents the issues of a small test becoming the issues of the entire content estate.

Phase 4 — Full Migration

With the pilot validated and any issues resolved, the full migration runs. Large migrations are typically structured in waves — migrating content by department, by site, or by content category, in an order that reflects business priority and operational risk. Critical, frequently accessed content is usually migrated first. Archival content is migrated last or handled separately.

Delta migration runs — capturing content added or modified after the initial migration pass — are typically run immediately before go-live to ensure that the destination contains the most current version of all migrated content. The gap between the initial migration run and go-live should be as short as operationally possible to minimise the volume of delta content.

Phase 5 — Validation and Testing

Every migration wave is followed by validation — checking that content has migrated completely, that metadata has been applied correctly, that permissions are functioning as expected, and that content is accessible to the right users. Validation is performed both technically — using migration tool reports and automated checks — and manually, with stakeholders reviewing their migrated content to confirm that it is complete and correctly placed.

Content that has not migrated correctly — failed files, missing metadata, broken permissions — is identified during validation and remediated before go-live. The validation phase is where migration quality is confirmed rather than assumed.

Phase 6 — Go-Live and Source Decommission

Go-live is the point at which the new SharePoint environment becomes the primary content repository and the source system is either decommissioned or placed in read-only mode. The timing of source decommission should be agreed with stakeholders in advance — typically, the source system is placed in read-only mode at go-live (allowing users to reference it if needed) and decommissioned after a defined period, once the organisation is confident that all critical content has been successfully migrated and adopted in the new environment.

Communication to users about the go-live is critical. Employees need to know that the new SharePoint environment is now live, where their content is, how to access it, and who to contact with questions. A well-planned go-live communication — email, intranet announcement, Teams message — reduces the volume of support queries and sets the right expectation for the transition.

Phase 7 — Post-Migration Support

The weeks immediately following a SharePoint data migration go-live are when user questions, content issues, and minor problems surface. Post-migration support — a defined period during which the migration team is available to address issues, answer user questions, and resolve any content problems that were not caught during validation — is an essential component of every migration project.

Post-migration support also includes monitoring of the new SharePoint environment for any issues that emerge in the weeks after go-live — permissions errors, missing content, failed refresh connections — and rapid resolution of those issues before they affect user trust in the new platform.


Managing Change and Driving Adoption After Migration

A technically successful SharePoint data migration that results in low user adoption is not a successful migration. The technical work of moving content from one system to another is only complete when employees are using the new environment confidently and productively.

Change management is the discipline that bridges the gap between a technically complete migration and genuine adoption. It encompasses communication — keeping users informed throughout the project about what is changing, when it is changing, and what they need to do — training, user support, and the cultural work of helping people develop new habits.

Communication should begin before the migration starts. Employees who understand why the migration is happening, what it will mean for them, and how it will benefit their working lives are more likely to engage positively with the change than those for whom it comes as a surprise. A communication plan that covers pre-migration awareness, migration progress updates, go-live announcement, and post-go-live reinforcement keeps users informed and engaged throughout.

Training should be timed to be useful. Training delivered too early — weeks before go-live — is forgotten by the time users need to apply it. Training delivered at or just before go-live, focused on the specific tasks users need to perform in the new environment, is retained and applied. Video tutorials, quick reference guides, and a designated support contact reduce the friction of the transition period.

Early wins should be communicated. When a department discovers that content they used to spend twenty minutes finding is now accessible in two clicks, that story should be shared. When a team realises that the version control in SharePoint has resolved a problem that used to cost them hours of reconciliation, that story should be told. Positive migration stories build momentum and accelerate adoption across the broader organisation.


Common SharePoint Data Migration Mistakes

Based on our experience delivering SharePoint data migrations for UK businesses, the following are the mistakes we see most frequently — and the ones that cause the most significant problems.

Migrating without a content audit. Organisations that migrate their entire content estate without first auditing it import their existing content problems into their new SharePoint environment. Duplicate files, obsolete content, and poorly organised material arrive in SharePoint in the same state they left the source system, immediately degrading the quality and trustworthiness of the new environment.

Replicating the source folder structure. SharePoint’s capabilities are best exploited with a different structural model from the file server hierarchies that most organisations are migrating away from. Replicating a deeply nested folder structure in SharePoint perpetuates the navigational problems of the source system rather than solving them.

Underestimating permissions complexity. The permissions that govern access to content in a legacy environment are often more complex than they initially appear — with individual file and folder permissions that have been granted and modified over years without systematic oversight. Mapping, validating, and correctly replicating these permissions in SharePoint is time-consuming but critical. Permissions errors that are not caught before go-live create compliance risks and user frustration.

Running a single migration pass without delta. A single migration pass run weeks before go-live leaves a gap — all content added or modified in the source system after that point is not in SharePoint at go-live. Running a delta migration pass in the days immediately before go-live closes this gap and ensures the destination is current at the point users transition to it.

Going live without user training and communication. Users who are surprised by a migration, who do not know where their content has moved, and who have received no training in the new environment will default to frustration and resistance. Communication and training are not optional extras — they are as important as the technical migration work.

Decommissioning the source too quickly. Decommissioning the source system on go-live day — before users have had time to validate that their critical content is correctly present in the new environment — creates significant risk. The source system should remain accessible in read-only mode for a defined period after go-live, providing a safety net for users who cannot immediately find something they need in SharePoint.


Working with NetMonkeys on Your SharePoint Data Migration

NetMonkeys has delivered SharePoint data migrations for UK businesses across a wide range of sectors and source environments — from file server migrations for manufacturing businesses to legacy SharePoint on-premises migrations for professional services firms, Google Drive migrations for technology companies, and Confluence migrations for software development organisations.

Our approach combines deep technical capability in SharePoint migration tooling with a strong emphasis on content strategy, information architecture, and change management. We understand that the technical work of moving files is only part of a successful migration — the content quality, structural design, and user adoption work is equally important and equally rigorous.

Our SharePoint data migration service covers the full migration lifecycle — content audit, information architecture design, tooling configuration, pilot migration, full migration, validation, go-live support, and post-migration assistance. 


Get in touch with the NetMonkeys team today to discuss your SharePoint data migration project. We will give you an honest assessment of the complexity, a clear view of what is involved, and a realistic timeline and cost for delivering it well.


Conclusion

SharePoint data migration is one of the most consequential technical projects a UK organisation can undertake. Done well, it is the foundation of a SharePoint environment that employees trust, use daily, and find genuinely useful for years. Done poorly, it is the origin of an environment that is cluttered with legacy content, burdened with an inherited structural logic that does not serve its new home, and distrusted by the users who needed it to be better than what came before.

The difference between these two outcomes is not primarily technical. The migration tools are capable. SharePoint Online is the right destination. The difference is in the rigour of the content audit, the thoughtfulness of the information architecture, the care taken with permissions and metadata, the quality of the testing and validation, and the investment in communication and adoption.

These are not afterthoughts. They are the migration. NetMonkeys is the partner that treats them as such.