Publish Date
20/07/2026
Categories
Blogs
Many SharePoint migration challenges start long before any files are moved. Duplicated content, unclear ownership, inherited permissions and unsupported customisations can all create problems if they are simply carried into a new environment.
Whether you’re planning a SharePoint Online migration from SharePoint Server, moving files from a network file share, migrating from Google Drive, Dropbox or Box, or completing a tenant-to-tenant migration, success depends on preparation.
A strong SharePoint migration plan helps organisations decide what should move, where it belongs and how success will be measured before migration begins.
What is SharePoint migration planning?
SharePoint migration planning is the process of connecting the business reasons for a move with the technical and governance decisions required to complete it successfully.
It involves understanding the source environment (where your data/content currently is) and target environments (where you would like your data/content to be after the migration), defining scope and ownership, assessing content and permissions, identifying remediation requirements, and agreeing how migration, testing and support will be managed.
Effective planning reduces risk, improves user adoption and helps ensure the new environment supports future business needs rather than replicating old issues.
Step 1: Define the business outcomes and migration scope
Before discussing tools or timelines, establish why the migration is happening.
Common drivers include:
- improving collaboration
- supporting remote working
- enhancing search capabilities
- strengthening security
- retiring legacy infrastructure
Your source environment could be SharePoint Server, file shares, Google Drive, Dropbox, Box or another Microsoft 365 tenant – whatever it is, a clear scope should identify which sites, departments, libraries and data sources are to be included in the migration, which should be excluded, and who owns each area in this source environment.
You should also define business owners, technical stakeholders and content owners early and success criteria should be agreed upfront, including target dates, acceptable downtime in the business and how migration success will be measured. Alongside this, it’s very important you think forward with how you are going train and teach staff the new environment you are migrating to too.
Step 2: Inventory and assess the source scope
A successful migration starts with understanding what you actually have, almost like your inventory.
Your inventory should capture content volumes, file counts, growth trends and storage locations. It should also identify stale, duplicated or orphaned data that no longer provides business value.
It’s important to remember that assessment of this inventory is equally important. Organisations often discover unsupported file types, naming issues, excessive folder structures or path-length limitations that could affect migration. Metadata, content types, document versions, permissions, external sharing and sensitive information should also be reviewed.
Where custom workflows, forms, web parts or third-party integrations exist, these should be documented early as they may require redesign or alternative migration approaches.
Step 3: Decide what to migrate, archive, restructure or delete
One of the biggest mistakes in SharePoint migration planning is assuming everything should be moved.
A better approach is to categorise content based on business value and retention requirements: Active, owned and compliant content should usually be migrated. For information that must be retained but is rarely used, may be better suited to an archive.
Migration can also provide an opportunity to restructure information where existing folder hierarchies or metadata models are no longer fit for purpose. For example, content deletion should only take place under approved governance and retention processes.
Reducing unnecessary content often lowers migration risk, improves user experience and simplifies long-term management.
Step 4: Design the target information structure
The destination environment should be designed around how people work today, not how systems were configured years ago.
This includes decisions around SharePoint sites, hub sites, Teams-connected sites and document libraries. Metadata structures, naming standards, content types and navigation should all support easier content discovery and management.
Governance should also be built into the design through site ownership rules, lifecycle management, retention labels, sensitivity labels and sharing controls. Ultimately, the goal is to create an environment where users can find information quickly and confidently.
Step 5: Map identities, permissions and external sharing
Permissions should never be migrated blindly.
Migration planning provides an opportunity to review access models and align them with a least-privilege approach. Consider how users and groups will be managed through Microsoft Entra ID, how guest access should work and whether any permissions require simplification.
Review areas with broken inheritance (where a file/folder no longer inherits permissions from its parent), identify content with no accountable owner and remove unnecessary access associated with former employees or outdated projects.
While some permissions may be preserved during migration, every environment should be assessed individually rather than assuming all permission structures can move unchanged.
Step 6: Review customisations, workflows and integrations
Not everything in SharePoint is content.
Many organisations rely on workflows, forms, custom solutions and connected business applications to support day-to-day operations. Legacy workflows, macros, custom code and unsupported components may not behave the same way in a modern SharePoint Online environment.
Understanding these dependencies early helps avoid surprises later. In some cases, migration may involve redesigning or modernising business processes instead of simply moving them.
Step 7: Choose the migration approach and tooling
There is no single approach that suits every migration. The right migration approach depends on the source environment, content complexity and business requirements. There are a range of migration approaches, like staged, wave-based, hybrid and cut-over:
- A cutover migration moves everyone to the new environment at the same time
- A staged migration spreads the move over a few weeks or months with both environments operating during the transition.
- A wave-based migration is where departments or business units are migrated in phases to reduce disruption and risk.
Some projects use a hybrid of the above approaches. For example, some businesses use a phased, wave-based approach where departments move gradually. Others use a cutover strategy that moves content within a defined migration window.
It’s important to note that tenant-to-tenant migrations, heavily customised environments and large-scale file server to SharePoint migrations often require specialist planning, a mix of migration approaches and tooling.
Microsoft’s SharePoint Migration Tool (SPMT) can support assessment and migration activities, and its scan capability provides valuable insight into content readiness. However, tooling should follow assessment findings, not drive them.
For organisations evaluating assessment tools, it’s worth noting that Microsoft’s legacy SharePoint Migration Assessment Tool (SMAT) is not a long-term recommendation, with support ending on 1 October 2026.
Step 8: Pilot, test and remediate
A pilot migration should represent the real environment, not just the easiest content to move.
Include a mix of business-critical, high-volume and higher-risk content so that testing reflects production conditions. Validate file counts, metadata, permissions and document versions. Test your integrations, workflows, search functionality, links and user access.
Business owners should formally review pilot results and document any defects. Findings can then be used to refine/tweak estimates, mappings, migration waves and cutover plans.
Step 9: Plan migration waves, cutover and rollback
Once you’ve tested the migration, the next question should be ‘How are we actually going to move everyone across?’
Most organisations don’t migrate everything at once. Instead, they split the project into migration waves. For example, HR might move first, followed by Finance, then Sales. This allows the team to learn from each phase, reduce risk and avoid overwhelming users or IT support teams. You could also group by risk levels or operational impact.
You’ll also need a clear cutover plan, which is the process of switching users from the old system to the new one. This includes deciding:
- When users stop making changes in the old system (sometimes called a freeze period)
- When the final data sync and any delta migration passes will take place
- Who is responsible for formal go/no-go approvals before migration and go-live
- How users and stakeholders will be informed through planned communication schedules
- What support will be available to users during and immediately after cutover
It’s also important to plan for what happens if things don’t go to plan. That’s where a rollback plan comes in. If critical issues are discovered after migration, everyone should already know:
- Who makes the decision to pause or reverse the migration
- What conditions would trigger a rollback
- How access to the old environment would be restored if needed
Step 10: Prepare users, governance and post-migration support
Technology alone does not make a migration successful.
Users need clear communication, training and ongoing support to help them adopt new ways of working. IT support teams should be prepared for common questions, while governance owners should understand their ongoing responsibilities.
The migration plan should also include decommissioning legacy platforms, reviewing governance controls and supporting users during the initial adoption period. These activities help organisations realise the long-term benefits of the migration investment.
SharePoint Migration Planning Checklist
Use this downloadable checklist during your project planning workshops and stakeholder reviews.
Even after your migration is complete, maintaining a well-managed SharePoint environment is essential. Ongoing governance helps ensure the platform remains secure, organised and aligned with best practices, including regular reviews of document access, user permissions and ownership.
When should you use a SharePoint migration partner?
Many organisations successfully manage straightforward migrations internally. However, specialist support can be valuable when:
- Your environment is large or poorly documented
- You have multiple content repositories that need consolidating
- The project involves tenant-to-tenant migration
- Compliance, security or business continuity requirements are complex
- Legacy customisations require assessment
- You lack internal resources for migration capacity/specialist expertise
- Independent advice on tooling, governance or migration strategy is needed
How Cobweb supports SharePoint migrations
While every migration is different, successful projects typically follow a structured approach.
Cobweb supports organisations from start to finish when it comes to SharePoint migrations, including project planning, pre-migration assessment, data review and clean-up, infrastructure preparation, governance and security design, migration delivery, testing, user adoption and training.
This ensures both technical and business considerations are addressed, helping organisations move to SharePoint Online with greater confidence and reduced risk.
FAQs: SharePoint Migration
A SharePoint migration plan should cover scope, content assessment, information architecture, permissions, governance, user training, compliance requirements, testing, migration waves, cutover planning, rollback procedures, communications and post-migration support.
The timeline completely depends on how complex your environment is – content volume, source systems, network performance, customisations, compliance requirements and business availability should all be taken into account when looking at timings. Planning and assessment often have a significant impact on overall delivery times too.
Low-value, duplicate, stale or orphaned content should be reviewed before migration. Information that must be retained but is no longer actively used may be more appropriate for archiving.
In most cases, permissions and metadata can be preserved and migrated. However, this depends on the source system, target design and migration tool capabilities. Assessment is essential before making assumptions.
A file server to SharePoint migration typically involves assessing file structures, permissions and metadata, designing a target SharePoint architecture, cleaning up content, testing migrations and completing phased migration waves.
Common causes include poor planning, unclear ownership, excessive legacy content, unsupported customisations, inadequate testing, weak governance and insufficient user adoption preparation.
The SharePoint Migration Tool can be effective for many migration scenarios. However for larger more complex projects, tenant-to-tenant migrations, compliance requirements and customised environments, you may benefit from specialist migration expertise and tooling.
Planning a SharePoint migration?
Cobweb can help assess your current environment, develop a practical SharePoint migration plan and support delivery from discovery through to user adoption. Whether you’re moving from SharePoint Server, file shares, third-party platforms or another Microsoft 365 tenant, starting with the right plan can significantly reduce risk and improve outcomes.
We’d be more than happy to hear about your requirements. If you think outsourcing to a partner might be the right decision for you, you can contact us here.