Migrate a Small Australian Office to Google Workspace

Moving a small Australian office to Google Workspace is more than an exchange between Gmail and Outlook. Mail, calendars, contacts, shared files, identities, DNS, security policies, and staff habits must move in a controlled order, with a way back if messages or documents fail to arrive.

I use a staged approach for these engagements: inventory first, prove the destination with a pilot team, then change routing during a short cutover window. This suits Australian offices where staff may work across Sydney, Melbourne, or regional sites and rely on NBN services, fixed wireless, or mobile failover rather than identical connectivity at every location.

Define the migration scope and service baseline

Start with a written inventory of every mailbox, shared folder, calendar, contact group, website, database, and application the office depends on. Record who owns each resource, where it is stored, who can access it, and whether it needs to remain available after the migration. This becomes the source of truth for testing the new environment.

Compare Workspace editions against the office’s actual requirements rather than choosing by feature count. Look at mailbox storage, Google Groups, shared drives, retention, audit features, migration tools, support, and endpoint integration. Australian customers benefit from local-currency billing and GST-compliant invoices, but should also include third-party migration software, administrator time, and ongoing support in the budget.

Assign clear ownership before purchasing licences. Identify the Workspace super administrator, a backup administrator, help-desk contacts, and business owners responsible for approving data access. Small teams often outgrow a shared administrator account; named accounts with least-privilege roles provide a better audit trail and make staff changes easier to manage.

Build the identity and data migration plan

Create the Workspace tenant around the company’s primary domain, then provision named accounts rather than personal Gmail addresses. Configure aliases for former staff or common functions, groups for departments, and shared drives for business material. The domain structure should reflect how the organisation communicates instead of copying an old Exchange structure without review.

Plan mail migration according to the actual source. An Exchange or Microsoft 365 mailbox may require a supported migration service, while older PST files and IMAP accounts can use different import paths. Preserve mailbox folders where useful, but recreate critical rules, signatures, delegates, calendar resources, and contacts separately because automated tools may not transfer every setting.

Set rules for ownership and retention before copying files. Scan documents for malware, identify personal information, and resolve duplicate or obsolete material. Shared-drive permissions should be tested with representative users, including contractors and staff who inherited access from previous employees. Keep the source available during verification, but appoint one authoritative destination to prevent parallel edits.

Configure DNS and execute the cutover

Lower the relevant DNS time-to-live values at least 24 to 48 hours before cutover and save the existing configuration. In Google Admin Console, generate the required SPF and DKIM records, then add them alongside Google’s MX records at the domain registrar. Introduce DMARC gradually, first with monitoring and only later with quarantine or rejection policies.

Keep the existing mail service available during the pilot. Deliver pilot messages to selected Workspace mailboxes while checking inbound and outbound delivery, attachments, calendar invitations, shared calendars, and access from mobile devices. Staff using Outlook can test the relevant Google clients, but web and mobile applications should also be verified before production changes.

A useful pattern is described in blue-green deployment on AWS: treat the new configuration as a parallel environment, verify it, and only then change production routing. The same discipline helps prevent a DNS error from becoming an office-wide outage. An Australian company using a .com.au domain should also confirm auDA registration details and renewal contacts during this stage.

Secure accounts, data, and devices

Require multifactor authentication for every user, with passkeys or security keys preferred for administrators and sensitive roles. Use context-aware access where the chosen Workspace edition supports it, and restrict third-party OAuth applications. Legacy IMAP, POP, app passwords, and shared credentials should be disabled when they are no longer required.

Review obligations before moving personal information. Where the Privacy Act 1988 and Australian Privacy Principles apply, document lawful collection, access controls, retention, and handling of access requests. If the selected edition and contract support Australian data residency, specify it during provisioning and confirm which data categories it covers. The vendor agreement should also support required notifications and secure exit arrangements.

Manage endpoints as part of the migration rather than treating them as a separate concern. Enforce operating-system updates, disk encryption, screen locks, and managed browser policies. Remote-wipe capability is useful for lost devices, while separate administrator workstations reduce the impact of a compromised ordinary user account.

Prepare people for a smooth transition

Run role-based training rather than a generic demonstration. Reception staff need to know how shared calendars, signatures, and contact groups work; sales staff need shared-drive access and mobile search; administrators need licence management, recovery options, and audit reports. A short written guide should include direct links to Google Workspace, internal support, and the fallback process.

Accessibility belongs in the pilot. Staff who need an alternative route into email can evaluate VoiceOut Outlook as an accessibility aid during the old-to-new workflow test, while confirming that it meets their technical requirements. Verify text scaling, keyboard navigation, screen-reader behaviour, captions, and accessible document templates before full rollout.

Publish support arrangements that match Australian business hours. Include the Google support route, a local managed-service provider where available, escalation contacts, and a process for urgent mail or access problems. Commercial electronic messages sent by the business must also follow the Spam Act 2003, including accurate sender identification and an effective unsubscribe mechanism.

Test operations, recovery, and running costs

Test the complete service rather than individual applications. Send and receive messages with external organisations, verify SPF and DKIM alignment, inspect DMARC reports, open shared files as different permission groups, and confirm that calendars and contacts appear correctly on managed devices. Include scenarios such as password reset, lost device, departed employee, and recovery after an administrator mistake.

Monitor the first weeks with Workspace reports, delivery logs, administrator alerts, and the Google Workspace Status Dashboard. Track bounced mail, suspicious sign-ins, storage growth, licence use, and support tickets. Establish recovery targets for mail and documents, then document the steps required to meet them. Drive synchronisation is not a complete backup strategy, so critical collections also need a tested export or third-party retention process.

Keep the old platform read-only for an agreed period and schedule its final shutdown only after stakeholders sign off. For a companion public website still hosted on PHP, the queue and worker settings covered in optimising PHP-FPM performance should be checked before launch traffic rises. Local offices should also document their NBN outage procedure and tested 4G or 5G fallback.

Run a controlled rollout and commit to the next step

The pre-cutover gate should cover these controls:

• A complete inventory with an owner, destination, migration method, and retention requirement for every business resource.
• A correctly configured Workspace tenant with named administrators, least-privilege roles, multifactor authentication, and suitable data-residency terms.
• Prepared DNS records covering MX, SPF, DKIM, and a carefully staged DMARC policy, with the existing configuration backed up.
• Pilot approval covering mail flow, calendars, contacts, shared-drive permissions, mobile access, external delivery, printing, and accessibility requirements.
• A tested rollback pack containing legacy access, DNS snapshots, critical exports, recovery credentials, and clear decision authority.

At launch and during stabilisation, use a separate operating checklist:

• Keep the previous mail service read-only for the agreed retention period and monitor forwarding or archival requirements.
• Review delivery failures, administrator alerts, storage growth, user issues, and support demand daily during the first week.
• Revoke legacy passwords, app passwords, OAuth grants, temporary accounts, and unnecessary service credentials after verification.
• Test restoration of a representative mailbox and document collection before declaring the migration complete.
• Review licences, third-party charges, migration costs, and actual usage after 30 days, then schedule the legacy system shutdown.

Choose a pilot group now, assign an inventory owner, and book a 60-minute migration design session with Karl Katzke before changing DNS or moving production mail.