Cloud migrations rarely fail on the data. They fail on permissions nobody mapped, a line-of-business application nobody tested, and a Monday morning when forty staff cannot find the folder they have used every day for six years.
This is a phase-by-phase checklist for Australian SMEs moving to Microsoft 365, Google Workspace or Azure — from the first audit through the cutover weekend and the fortnight afterwards that decides whether the project is judged a success.
Timeline at a glance
| Phase | Duration | Outcome |
| 1. Discovery and audit | 1 – 2 weeks | You know what you actually have |
| 2. Design and licensing | 1 week | Target architecture agreed |
| 3. Build and secure | 1 week | Tenant configured and hardened |
| 4. Pilot | 1 week | Problems found while they are cheap |
| 5. Data migration | 1 – 2 weeks | Mail and files synchronised |
| 6. Cutover | 1 weekend | Live on the new platform |
| 7. Hypercare | 2 weeks | Adoption embedded |
Four to eight weeks is realistic for 20 to 50 staff. Compressing it below four weeks usually means skipping the pilot, which is where the expensive surprises live.
Phase 1 — Discovery and audit
Nothing else works if this is rushed. You are building an inventory of what exists, not what people think exists.
- Mailbox count and size, including shared mailboxes, distribution lists and aliases
- Total file data volume, and the depth of folder nesting
- Current permission structure — who has access to what, and why
- Line-of-business applications and how they authenticate
- Anything that sends email from your domain: accounting software, CRM, booking systems, the website contact form
- Devices, operating systems and which are out of support
- Existing DNS records, and who controls the domain
- Current backup arrangement and retention requirements
The item most often missed is the last one on the email list. Applications that send mail from your domain break silently after a migration if their sending configuration is not carried across, and nobody notices until a customer says they never received an invoice.
The permissions problem
Legacy file servers accumulate permissions over years. Folders inherit access from structures that no longer make sense, and individuals hold rights granted for a project that finished in 2019.
Do not migrate that mess. Map it, then design a clean structure aligned to how the business works now. A migration is the one moment where restructuring is politically achievable, and skipping it means carrying the problem into the new platform permanently.
Phase 2 — Design and licensing
Decide the destination architecture before touching anything.
- Which platform, and which licence tier per user role — not everyone needs the same
- Where shared data will live: SharePoint sites or Google shared drives, structured by team or function
- Naming conventions for sites, drives and groups, written down
- Confirmed Australian data residency, in writing from the vendor
- Retention and archiving policy matched to your legal obligations
- Third-party backup product selected
On that last point: neither Microsoft 365 nor Google Workspace is a backup. Both replicate data for availability and offer recycle bins and retention, but neither gives you point-in-time recovery against accidental deletion beyond the retention window, malicious deletion by a compromised account, or ransomware encrypting synced files. Budget $3 to $8 per user per month for a proper backup.
If you are still weighing platforms, our Microsoft 365 versus Google Workspace comparison covers the decision for Australian businesses.
Phase 3 — Build and secure
Configure security during the build, not after go-live. Retrofitting controls onto a live tenant with staff already working is considerably harder.
- Enforce multi-factor authentication for every user, without exception
- Apply Conditional Access or Context-Aware Access policies
- Create separate privileged administrator accounts, distinct from daily accounts
- Configure SPF, DKIM and DMARC for your domain
- Enable audit logging and set retention
- Apply device compliance policies
- Configure external sharing rules deliberately, rather than accepting defaults
SPF, DKIM and DMARC are the quiet essentials. Configured incorrectly, your legitimate mail lands in spam folders after cutover and everyone concludes the migration broke email.
Phase 4 — Pilot
Migrate five to ten people first. Choose deliberately: one person from each department, at least one heavy user, and at least one person who is sceptical about the change. Sceptics find problems enthusiasts overlook.
Run the pilot for a full working week and confirm:
- Mail sends and receives correctly, internally and externally
- Calendars, shared calendars and delegate access work
- Mobile devices connect without manual reconfiguration
- Files open with the right permissions from the right places
- Printing and scan-to-email still function
- Line-of-business applications authenticate
- Meeting room and resource bookings behave
Scan-to-email is the classic casualty. Office multifunction devices are frequently configured to relay through the old mail server, and stop working the moment it is decommissioned.
Phase 5 — Data migration
Bulk data moves before cutover, not during it. Mail and file synchronisation typically runs over several days in the background while everyone keeps working normally.
- Run an initial full synchronisation, then incremental passes
- Verify item counts against the source, not just “completed successfully”
- Migrate shared mailboxes and calendars, which often need separate handling
- Recreate distribution lists and groups
- Communicate a content freeze date for large shared repositories
- Reduce DNS TTL values 48 hours before cutover
Lowering DNS TTL in advance is a small step that saves real pain. It means the MX change propagates in minutes rather than hours if something needs reverting.
Phase 6 — Cutover
Do it on a Friday evening. It gives two days to resolve anything unexpected before the business needs the platform.
- Run the final incremental synchronisation
- Change MX records to the new platform
- Update SPF, DKIM and DMARC records
- Reconfigure any application or device that sends mail from your domain
- Send test mail in both directions with external addresses
- Verify mobile devices for a sample of users
- Confirm the old platform is receiving nothing new before decommissioning
Keep the old environment running read-only for at least 30 days. It costs very little and it is your safety net if something was missed.
Phase 7 — Hypercare
The fortnight after go-live determines whether the migration is remembered as smooth or painful. The technology is usually fine by now; the humans are adjusting.
- Provide on-site or highly responsive support for the first two days
- Run short role-specific training sessions, not one generic session
- Publish a one-page guide covering where files now live
- Verify the first backup completes and perform a test restore
- Review audit logs for misconfigured access
- Collect friction points and fix them in week two rather than deferring
Budget for training explicitly. The most common cause of a migration being judged a failure is not technical — it is staff who were never shown where anything went.
Frequently asked questions
How long does a cloud migration take for a small business?
Four to eight weeks end to end for 20 to 50 staff, including discovery, pilot, migration and post-go-live support. The cutover itself is typically a single evening. Most of the timeline is preparation and testing, which is what keeps the cutover uneventful.
Will we lose email during the migration?
A properly staged migration loses nothing. Mail is synchronised before cutover, and the old environment is kept running read-only afterwards so anything in transit is captured. Loss generally occurs when MX records are switched before synchronisation completes.
Do we still need backup after moving to the cloud?
Yes. Microsoft 365 and Google Workspace replicate data for availability but do not provide point-in-time recovery. Neither fully protects against deletion beyond the retention window, a compromised account deleting data, or ransomware encrypting synced files. Third-party backup is standard practice on both.
Is our data stored in Australia after migration?
Both platforms offer Australian data regions, but it depends on how the tenant is provisioned and which services you use. Confirm your data region during the design phase and obtain written confirmation, particularly if you have NDIS, healthcare or financial services obligations.
What is the most common cloud migration mistake?
Migrating the existing permission structure unchanged. Legacy file servers accumulate years of ad hoc access, and copying that into SharePoint or Google Drive carries the problem forward permanently. The second most common is skipping the pilot phase to save a week.
Can we migrate without downtime?
Effectively yes. Staff keep working throughout discovery, build and data synchronisation. The only disruption is the cutover window, usually a Friday evening, and most staff notice nothing beyond signing in again on Monday.
The bottom line
A successful cloud migration is mostly preparation. Audit properly, redesign permissions rather than copying them, pilot with real users, and budget for the fortnight after go-live. Skip any of those and the project will still technically complete — it will just be remembered badly.
The Anand Technologies handles cloud migration and setup for Australian businesses, including Microsoft 365 deployment and support and shared drive and business storage design. For a migration plan scoped to your environment, get in touch.