A Microsoft 365 migration is one of the few IT projects where the technical work is straightforward and the planning is where projects succeed or fail. Moving mailboxes is a solved problem. Moving them without losing mail, breaking scan-to-email, orphaning shared calendars, stranding a line-of-business application that relies on SMTP relay, or leaving staff unable to find their files on Monday morning — that requires a plan.
This guide sets out how Australian businesses should plan a Microsoft 365 migration: the phases, the realistic timelines, the costs, the mistakes we see most often, and a step-by-step planning sequence you can apply to your own environment.
What does a Microsoft 365 migration involve?
A Microsoft 365 migration moves your email, files, collaboration and identity from an existing platform into a Microsoft 365 tenant. The source is usually one of four things: an on-premises Exchange server, Google Workspace, a hosted IMAP or cPanel mail service, or an older Microsoft 365 tenant being consolidated after an acquisition.
There are five workloads to account for, and they have very different characteristics.
Identity. Accounts, groups, licences and authentication. Either cloud-only in Entra ID, or synchronised from on-premises Active Directory with Entra Connect. Identity is planned first because everything else depends on it.
Email. Mailboxes, shared mailboxes, distribution groups, calendars, contacts, rules, and mail flow — including MX records, SPF, DKIM, DMARC, connectors, and any device or application that sends mail through your domain.
Files. Network file shares or Google Drive moving to SharePoint Online, OneDrive and Teams. This is where most of the effort goes, because file shares accumulate a decade of permissions, path lengths, duplicate content and abandoned data.
Collaboration. Teams structure, channels, meeting policies, external sharing rules and governance. Migrating a legacy chat platform is optional; building sensible Teams governance is not.
Devices and applications. Outlook profiles, OneDrive sync, Windows sign-in, Intune enrolment, multi-function devices, ERP and accounting integrations, and anything that authenticates against your old mail server.
Our Microsoft 365 migration package covers all five workloads at a fixed price, and the environment is handed over to our managed Microsoft 365 service on completion.
Microsoft 365 migration phases
Phase 1 — Discovery and planning (1–3 weeks)
Inventory everything: mailbox count and sizes, public folders, shared mailboxes, distribution lists, DNS records, domains, applications sending mail, file share sizes and permission structures, devices, operating system versions, and line-of-business software dependencies. Decide on the identity model, the licensing mix, and the cutover approach. Produce a migration runbook with rollback points.
Phase 2 — Tenant preparation (1 week)
Provision the tenant, verify domains, configure Entra ID, apply the security baseline (Conditional Access, MFA, Defender policies, audit logging), configure Exchange Online policies including retention and quarantine, create the SharePoint site architecture, and set Teams governance and external sharing controls. Doing security configuration before migration is far cheaper than retrofitting it afterwards.
Phase 3 — Pre-staging (1–4 weeks)
Pre-seed the data. Mailboxes are synchronised in the background while users continue working on the old system; file shares are copied to SharePoint and OneDrive with permissions mapped; delta syncs run repeatedly so the final cutover only moves recent changes. Pre-staging is what makes a low-downtime cutover possible.
Phase 4 — Cutover (a weekend, typically)
Change MX records, run the final delta sync, reconfigure Outlook profiles and OneDrive clients, repoint multi-function devices and applications, and verify mail flow in both directions. A well-planned cutover produces no lost email — mail sent during DNS propagation is queued and delivered, not bounced.
Phase 5 — Adoption and hypercare (2–4 weeks)
Floor-walking or dedicated support in the first week, staff training on Teams, SharePoint and OneDrive, cleanup of residual issues, decommissioning of the old platform, and documentation handover. Adoption is the phase most often cut for budget reasons and the one that determines whether staff actually use the platform you paid for.
Common Microsoft 365 migration mistakes
Migrating the file share as-is. Lifting a twenty-year-old H: drive into SharePoint reproduces every structural problem it had, plus new ones — path length limits, unsupported characters, and permission sprawl that becomes unmanageable. Restructure into a small number of sites and libraries with permissions inherited from Microsoft 365 groups.
Leaving security until after go-live. MFA, Conditional Access and legacy authentication blocking are easier to enforce before users have established habits. Migrating first and securing later means a second change-management exercise.
Forgetting the things that send email. Photocopiers, alarm systems, ERP invoicing, CRM notifications, backup alerts, website contact forms. Each needs a decision — authenticated SMTP relay, connector, or an external service — before MX records change.
Underestimating OneDrive known-folder move. Redirecting Desktop, Documents and Pictures to OneDrive is excellent practice and generates a large initial sync. On a constrained internet connection, staging this across departments matters.
No licence plan. Buying Business Standard and discovering three months later that you need Business Premium for Intune and Conditional Access is an avoidable cost. Decide the security posture first, then the licence.
Ignoring public folders and shared mailboxes. These are frequently undocumented, heavily used, and discovered at cutover. Inventory them in discovery.
Assuming "no downtime" means "no change". Staff need to know their password prompt will look different, that their files are now in OneDrive, and where to ask for help. Communication is a project deliverable.
How long does a Microsoft 365 migration take?
Timelines depend on user count, data volume, source platform and internet bandwidth, not on complexity of the software.
| Size | Typical elapsed time |
|---|---|
| 1–15 users, simple mail only | 1–2 weeks |
| 15–50 users, mail plus file shares | 3–5 weeks |
| 50–150 users, mail, files, Teams, Intune | 6–10 weeks |
| 150–500 users, hybrid identity, multiple sites | 3–5 months |
Elapsed time is dominated by pre-staging and coordination, not engineering hours. A 40-user migration might take four weeks of calendar time and two weeks of actual work. Bandwidth matters: 2 TB of file data over a 50 Mbps upload link takes roughly four days of continuous transfer, which needs to be planned rather than discovered.
Microsoft 365 migration costs in Australia
Two costs exist: the project fee and the ongoing licensing.
Project fees for Australian migrations in 2026 typically run:
- 1–15 users, mail only — $2,500 to $6,000
- 15–50 users, mail and files — $6,000 to $18,000
- 50–150 users, full workload with Intune and security baseline — $18,000 to $45,000
- 150+ users or hybrid identity — quoted on scope
Licensing is per user per month. Business Basic suits users who only need web and mobile apps; Business Standard adds desktop Office; Business Premium adds Intune, Entra ID P1, Defender for Business and Azure Information Protection, and is the correct baseline for any business that intends to meet the Essential Eight.
Insist on a fixed price with a written scope. Migrations quoted hourly transfer all discovery risk to you, and discovery risk is the largest variable in the project. Ask specifically whether the security baseline, data pre-staging, out-of-hours cutover, user training and post-migration hypercare are in scope — those four items are where "cheap" quotes usually differ.
HowTo: Plan a Microsoft 365 migration for your business
Step 1 — Inventory the current environment
Document mailbox count and sizes, shared mailboxes, distribution groups, public folders, file share volumes and permissions, DNS records, and every device or application that sends email through your domain.
Step 2 — Choose the identity model
Decide between cloud-only identity and directory synchronisation from on-premises Active Directory. Cloud-only is simpler and appropriate for most businesses without an on-premises server dependency.
Step 3 — Select licensing
Match plans to user roles. Choose Business Premium where Intune device management, Conditional Access and Defender for Business are required, which is the case for any business targeting Essential Eight Maturity Level 2.
Step 4 — Design the SharePoint and Teams structure
Map existing file shares to a small set of SharePoint sites and document libraries aligned to teams and functions, and define external sharing and retention policies before any data moves.
Step 5 — Build and secure the tenant
Provision the tenant, verify domains, and apply the security baseline — MFA, Conditional Access, legacy authentication blocking, audit logging, Defender policies and retention — before user data arrives.
Step 6 — Pre-stage mailbox and file data
Run background synchronisation of mailboxes and file content while users remain on the old system, then repeat delta syncs so the cutover moves only recent changes.
Step 7 — Communicate and train
Tell staff what is changing, when, and what they need to do. Deliver short role-based training on Outlook, Teams, SharePoint and OneDrive before cutover, not after.
Step 8 — Execute the cutover
Change MX records out of business hours, run the final delta sync, reconfigure Outlook and OneDrive clients, repoint devices and applications, and verify inbound and outbound mail flow.
Step 9 — Run hypercare and decommission
Provide intensive support for the first one to two weeks, resolve residual issues, verify backups and licence assignments, then decommission the legacy platform and hand over documentation.
Planning support from Mycelium 365
Mycelium 365 is a Microsoft Solutions Partner based in Melbourne, delivering fixed-price Microsoft 365 migrations for businesses across Australia and New Zealand. Every migration includes discovery, a written runbook, a hardened security baseline applied before cutover, out-of-hours cutover, user training and two weeks of hypercare — after which the environment moves onto our managed helpdesk so the same engineers who built it continue to support it.
The best migration is the one your staff barely notice. That outcome comes from planning, not from the migration tool.