Key takeaways

• A SharePoint migration is a restructure: decide what comes across and where it lives before anything moves.
• Audit first. Permissions, duplicates and stale files are cheaper to fix before the move than after it.
• Copy in stages and keep the old site live. Nothing is deleted from the source until the owner confirms the new copy.
• Not everything should be migrated: duplicates, outdated files, personal files and very large raw media usually stay behind.
• Timeline depends on scope, which is set in the first two weeks once the tenant, permissions and documents have been reviewed.

What is a SharePoint migration?

A SharePoint migration is the process of moving an organisation's files, pages and information from an existing platform, such as a legacy intranet, a content management system or an earlier SharePoint, into SharePoint Online in Microsoft 365. Done well, it includes redesigning the structure that content will live in, not only transferring it.

Why copying everything across doesn't work

A like-for-like copy moves the problems with it. The patterns Dapth's SharePoint developers see most often in inherited environments:

• Sites that grew without a plan. Several sites, many abandoned, with no clear owner.
• Broken permissions. It becomes very difficult to tell who has access to what.
• Duplicate documents. Several versions of the same file, none obviously current.
• Folders inside folders. Documents sit in deep folder trees with no tags, so finding one means already knowing where it lives.
• One library for everything. Finance, IT and HR files share one document library when separate libraries, each with its own purpose and metadata, would make them searchable.

Structure is the second half of the problem. On one recent WA government project, the legacy Umbraco intranet was not organised around teams, so its structure did not translate into SharePoint. Rather than replicate it, Dapth redesigned the information architecture as department-based sites connected to a central hub.

How a SharePoint migration works, step by step

This is the sequence Dapth's SharePoint team follows. It sits inside Dapth's five-stage delivery process: Diagnose, Design, Develop, Deliver, Support.

1. Understand the environment (the first two weeks). Review the existing tenant, permissions, documents and pain points. Meet stakeholders, map current processes and workflows, identify priorities, and agree scope and requirements before design starts.
2. Audit before you move. Assess what exists and who owns it. Check permissions and documents, and clean up duplicates before they travel.
3. Decide what comes across. Not everything moves. Content is sorted into keep, link, or leave behind (see the table below).
4. Map to the new structure. Match content to the new information architecture, the metadata model and the page templates, with separate libraries for separate purposes.
5. Pilot with a small group. Build and test the new site first with a small group of users from the client's organisation, and collect their feedback before the full move.
6. Copy in stages, don't cut. Users are notified when their documents are ready to move and provide the final revision. Files are locked while they are copied so the latest version is the one that moves. The old site stays in place, and the document owner confirms the new copy is good.
7. Go live, train and support. Train staff, then provide ongoing support so the platform keeps meeting the organisation's needs.

What should you migrate, link or leave behind?

Use this triage on every content area before it moves.

How do staff keep working during a migration?

The organisation doesn't stop for a migration, so the move is staged. The source documents stay where they are while the new SharePoint site is built and tested with a small group first. Documents are copied, not moved, and the original is not deleted. Users are told when their content is ready to migrate, supply a final revision, and the owner validates the new copy before anyone relies on it.

What are the real risks, and how do you spot them early?

The risk people worry about most is the right one: losing or corrupting documents. Dapth's approach to it is mechanical. Copy rather than cut, lock files so the latest version is the one that moves, and have the owner confirm the result.

Two further risks come from Dapth's project risk register:

• The migration tool doesn't map content correctly. Pilot the migration early with validation steps to check data accuracy, and keep a manual or semi-automated fallback with additional resource if it fails.
• Not enough internal capacity to manage the migrated content. This is rated likely on Dapth's register. Identify content owners early and provide training and transition support.

A third is easy to underestimate: delays in signing off the information architecture. The mitigation is early collaborative design workshops with fixed review periods.

What does a migration look like in practice?

On that project, the legacy Umbraco intranet had limited search, limited design flexibility and low engagement. Dapth delivered a hub-and-spoke SharePoint Online intranet: a central hub connecting department sites for areas including Finance, HR, IT and Procurement, with categorised document libraries, a staff directory and news.

Several decisions came from treating the migration as a restructure:

• Not everything moved. Key pages and historical news articles were migrated, not all existing content.
• Content stayed current. News was kept in step with the legacy site's new postings during the transition so the new intranet wasn't an out-of-date archive.
• Document sets were linked, not moved, so staff can still search for them from SharePoint.
• A design phase came before the build, so staff would find it approachable rather than intimidating.

Rebuilding the pages and news took time, but the result is a single, trusted starting point with consistent navigation.

How long does a SharePoint migration take?

It depends on scope. Many of Dapth's SharePoint projects run as a sprint-based build of about six weeks, as Relationships WA did when it moved its intranet from Kentico to SharePoint. Larger, multi-department programmes take longer. Scope is agreed in the first two weeks, once the tenant, permissions and documents have been reviewed.

When is SharePoint the wrong destination?

SharePoint is strong for document management, intranets and team collaboration, but it is not designed for everything. A public-facing website is better served by a CMS such as Xperience by Kentico. Business operations such as inventory, accounting and sales belong in an ERP such as Odoo. Dapth's recommendation follows the need, not the platform. See also: SharePoint or a CMS: which does your organisation need?

About Dapth

Dapth is your Perth digital consultancy, building connected digital systems from websites and intranets to applications, software, ERP and AI tools. For more than 15 years we have helped WA businesses, government agencies and organisations unlock advantages like streamlined workflows, increased efficiency, cost savings, new revenue and more powerful marketing.

We start with your organisation, not the technology: your users, your operations and your objectives. Then we connect everything across four areas:

• Digital Consultancy: Digital strategy, service design and UI and UX design that map how your customers, people and systems should work together, before anything is built.
• Customer Experience: Websites and digital experience platforms on Xperience by Kentico (Kentico Gold Partner), Sitefinity, Umbraco and Payload CMS, plus ecommerce.
• Employee Experience: Intranets and employee portals on Microsoft SharePoint, and workflow automation that takes the double handling out of everyday work.
• Operational Systems: ERP with Odoo as our primary platform (we are an Odoo partner), plus custom software, apps and the integrations that connect them.