SharePoint migration in Australia: a practical guide.

SharePoint migration in 2026 is rarely the simple lift-and-shift exercise that gets pitched in vendor demos. Australian businesses migrate for three reasons: file servers are reaching end of life, on-prem SharePoint farms are no longer cost-effective to maintain, or two tenants need to merge after an acquisition. Each path has different tooling, different costs, and different ways to fail. This guide walks through what each looks like in practice.

The three migration paths Australian businesses actually take

1. File server to SharePoint Online

The most common scenario. A file server (Windows file shares, NetApp, Synology, or similar) is reaching capacity, the hardware is past warranty, or remote work has exposed how brittle VPN-only file access has become. The destination is SharePoint Online with OneDrive for personal storage and Teams-backed SharePoint sites for collaboration.

Sounds straightforward. The complications are file paths longer than 256 characters, illegal characters in filenames (a Windows-tolerated colon, a hash symbol), broken NTFS permissions accumulated over a decade, and the discovery that 60 percent of the content hasn’t been touched in three years and shouldn’t be migrated at all.

2. On-prem SharePoint to SharePoint Online

SharePoint 2013, 2016, or 2019 farms migrating to SharePoint Online. The good news: Microsoft’s Migration Manager handles the heavy lifting for content, lists, and most metadata. The bad news: custom solutions, full-trust code, classic publishing sites, and InfoPath forms (still alive in many Australian organisations) need redesign rather than migration.

The hardest part of this path is usually the workflows. SharePoint 2013 workflows don’t come across; they need to be rebuilt in Power Automate. Organisations that have hundreds of business-critical workflows discover this late and budget poorly for it.

3. Tenant-to-tenant consolidation

Post-acquisition or post-merger, two SharePoint Online tenants need to become one. Identity, content, permissions, sensitivity labels, retention, and Teams all need to migrate while keeping both sides operational. This is the most complex of the three paths and the one where dedicated tooling earns its licence cost (ShareGate, Quest On Demand, AvePoint, BitTitan).

Tenant consolidation in Australia is increasingly common as M&A activity in professional services, construction, and healthcare drives multi-tenant scenarios. Plan for 6 to 12 months and a multi-disciplinary project team that includes identity (Entra ID), security, end-user computing, and business stakeholders.

Cost ranges by scenario

Small business (under 100 users, under 1TB)

Total cost: AUD $15,000 to $40,000 in services. Plus Microsoft 365 licensing if not already in place and migration tooling (ShareGate or Migration Manager). Timeline 4 to 8 weeks. Usually file-server-to-SharePoint Online with one or two pilot sites first.

Mid-market (100 to 1,000 users, 5 to 20TB)

Total cost: AUD $60,000 to $200,000 in services. Plus tooling licence (typically AUD $5,000 to $25,000 depending on volume). Timeline 3 to 6 months. Includes content rationalisation, information architecture, permissions remediation, sensitivity labelling, end-user training, and a phased cutover by site or business unit.

Enterprise / tenant consolidation

Total cost: AUD $120,000 to $750,000+. Highly variable based on tenant size, integration count, and the post-merger identity strategy. Timeline 6 to 12 months. Almost always requires dedicated migration tooling, a migration architect, and an internal programme team alongside the implementer.

The five most common pitfalls

1. Lift-and-shift without rationalisation

The temptation is to migrate everything “just in case.” Don’t. Most file-server content is stale, duplicated, or owned by someone who left three years ago. A pre-migration content rationalisation typically reduces volume by 30 to 60 percent, which speeds the migration, lowers tooling cost, and gives users a cleaner destination.

2. Ignoring permissions until cutover

File-share permissions accumulate cruft. Broken inheritance, orphaned SIDs, individual user permissions that should have been groups, and content shared with people who left the organisation. Discover and fix this in the discovery phase, not in cutover week. The same applies to sharing links in SharePoint Online sources.

3. Under-investing in training

SharePoint Online is genuinely different from a Windows file share. Users who default to the F: drive workflow will recreate the mess in OneDrive within six months. End-user training, champion networks, and ongoing support investment are not optional. The cheapest line items to cut and the most expensive to skip.

4. Skipping the pilot

Run a single representative site through the full migration pattern (discovery, prep, migration, validation, training, support) before scaling. The pilot finds the things you didn’t know to look for. Filename character issues, third-party application paths, or PDF rendering quirks. At a scale where you can fix them.

5. Treating it as an IT project

SharePoint migration is an IT-enabled business change project. The technical work is largely solved. The hard work is changing how teams collaborate, how documents get owned and tagged, and how information governance gets applied. IT-only projects deliver migrations that work and adoption that doesn’t.

SharePoint migration and Microsoft 365 Copilot

If your organisation is planning Copilot adoption (or already has licences), treat your SharePoint migration as the natural moment to fix the foundation Copilot depends on. Copilot grounds against SharePoint and OneDrive content honouring existing permissions. If those permissions are messy, Copilot will surface things people technically have access to that they shouldn’t.

The migration is the opportunity to apply sensitivity labels, remediate over-shared content, define site governance, set up DLP policies, and establish information architecture that Copilot can reason over usefully. Doing migration without thinking about Copilot is a missed opportunity. We cover the Copilot side in detail in our guide to Microsoft 365 Copilot for Australian businesses.

Tooling that earns its licence cost

• Microsoft Migration Manager — included with M365. The default starting point for file-server-to-SharePoint and on-prem SharePoint migrations. Best for straightforward content moves.
• ShareGate — most-deployed third-party tool in the Australian mid-market. Strong reporting, granular control over permissions and metadata, comfortable for non-architect operators.
• Quest On Demand Migration — preferred for tenant-to-tenant consolidation. Strong identity and Teams handling.
• AvePoint Fly — competitive on tenant-to-tenant; strong governance reporting.
• Metalogix Content Matrix — historically strong for legacy SharePoint, still useful for SharePoint 2010/2013 source migrations.

What to do next

Whatever the source, three things make SharePoint migrations succeed: a discovery phase that finds the surprises before they become problems, a phased cutover that limits blast radius, and a serious commitment to end-user enablement after go-live. If you’re evaluating tooling, sequencing, or budget for a migration, we’ll do that scoping with you. We’ve led migrations from single file servers to multi-tenant consolidations across Australia, including the ACT government contractor environment where SharePoint sat alongside Business Central and Defender for Endpoint inside an Essential Eight ML2 deployment.