The confirmed brief for this case study is a Drivetekrec project concerning a move from Google Workspace to Microsoft 365. Project dates, status, detailed scope and achieved results have not yet been verified, so this page explains the work that the migration requires without presenting those planning controls as completed outcomes.
A business email migration is not a single switch. It combines two related workstreams:
- preparing Microsoft 365 identities, licences, mailboxes and the data migration; and
- changing the domain’s live DNS records so new mail reaches the intended platform and authorised senders continue to authenticate correctly.
Keeping those workstreams separate makes the dependencies easier to understand. Mailbox data can be prepared and copied without changing where new messages are delivered. Conversely, changing MX records affects mail routing but does not move historical email, calendars, contacts or files.
Establish the current position
The first stage is discovery. Before a migration method or cutover window can be chosen, the project needs a reliable inventory of the services, accounts and access involved.
That includes confirming:
- who controls the domain registration and which nameservers are authoritative;
- who can change the live DNS zone and what records it currently contains;
- the Google Workspace and Microsoft 365 administrator access available;
- the users, aliases, groups and shared addresses that need an equivalent destination;
- whether the data scope includes Gmail, Calendar, Contacts, My Drive or shared drives;
- website forms, applications and third-party services that send using the domain; and
- any compliance, retention, coexistence or staged-migration requirements.
This is where WEBS Ltd’s experience across Google Workspace support, Microsoft 365, domains and DNS and business email support is important. The inventory needs to cover the whole mail path rather than only the source and destination admin consoles.
Prepare Microsoft 365 before mail routing changes
The destination needs to be ready before any public mail-flow change. The required Microsoft 365 tenant, licensing and identity arrangement must be confirmed, followed by the users, mailboxes, shared mailboxes, aliases, groups and permissions that belong in scope.
Domain verification can be planned without immediately redirecting live mail. This allows the destination configuration and administrator access to be checked while Google Workspace continues to handle the existing service.
The source inventory also determines the migration method. Gmail messages, calendars, contacts, Drive content and shared-drive content have different behaviours and may not all use the same tooling or sequence. WEBS Ltd would select and document the method only after the required data types, quantities and constraints are known.
Treat DNS as its own controlled change
The domain registrar, authoritative DNS provider and email platform perform different jobs. Moving mailbox data does not require a domain transfer, while transferring a domain does not migrate email. If a registrar, nameserver or hosting change is also required, it should be planned separately through the wider website and domain migration service.
For the email cutover, the live DNS plan needs to identify:
- the Microsoft 365 verification and mail-routing records required;
- the MX change that directs new inbound email;
- every legitimate sending service that must remain represented in SPF;
- the DKIM records and activation sequence for Microsoft 365;
- the existing DMARC policy and the evidence needed before tightening it; and
- any Google Workspace, website, CRM or third-party sending dependency that must remain active during transition.
This prevents a common mistake: replacing records for the old platform without checking what else relies on them. WEBS Ltd can coordinate this work with existing domain, DNS and hosting support so ownership and access are clear before the change window begins.
Sequence the migration and cutover
The detailed runbook depends on the confirmed scope, but the required sequence is straightforward in principle:
- Document ownership, access, accounts, data and connected sending services.
- Prepare the Microsoft 365 destination and prove that administrators can manage it.
- Configure the migration method and complete an agreed pilot or pre-stage where appropriate.
- Reconcile source and destination identities, aliases, groups and shared addresses.
- Agree the change window, user communications, validation checks and decision points.
- Make the planned mail-flow and authentication changes in the documented order.
- Test inbound and outbound delivery, authentication and user access from outside the organisation.
- Reconcile remaining data and retain the previous service until the agreed evidence supports closure.
This sequence distinguishes preparation from cutover. It also creates checkpoints where the team can pause rather than continuing through an unclear or failed validation result.
Plan for continuity and contingency
Continuity cannot be promised without knowing Drivetekrec’s current configuration, migration method and cutover requirements. The plan therefore needs to establish whether the move requires coexistence, staged groups, a final synchronisation or a single coordinated cutover.
A usable contingency plan records the last known working state, the records being changed, who has authority to reverse them and the conditions that would trigger that decision. DNS time-to-live values may be adjusted in advance where that supports the chosen approach, but DNS propagation is only one dependency; account readiness, data state and client configuration also need to be considered.
Validate before calling the migration complete
Successful sign-in is not enough evidence on its own. Validation should cover the items agreed in the scope, which may include:
- inbound and outbound messages using external test accounts;
- internal delivery, aliases, groups and shared mailbox behaviour;
- SPF, DKIM and DMARC results in received-message headers;
- user access to the data types included in the migration;
- mobile, desktop and browser access where those clients are in scope;
- website forms and approved third-party senders; and
- a documented comparison of the expected and actual destination inventory.
Post-migration support should then follow the agreed support period: resolving user access issues, checking delayed or missed items, reviewing mail-flow evidence and only retiring the previous service when the completion criteria have been met.
This scope-led account records the dependencies and end-to-end planning required for a Google Workspace to Microsoft 365 migration without claiming a migration method, validation result or outcome that has not been confirmed.