Business email migration checklist: records, routing and handover

List everything attached to the email address

A mailbox is part of a wider working system. An address might receive website enquiries, send invoices, own shared calendars and act as the recovery address for a supplier account. Moving its messages leaves each of those connections needing a separate check.

Prepare one row for every person, shared address, alias and group. Record the owner, source mailbox, destination, approximate size and any forwarding. Add the phones and desktop applications used by each person. Mark inactive accounts whose records still need retention.

Agree who controls the domain and DNS account. Keep the existing service available through verification and the agreed overlap period. A destination account alone does not recover records held inside an inaccessible source account.

Choose a migration method for each record type

An IMAP migration into Microsoft 365 transfers email. Contacts, calendar items and tasks require separate handling. A Google Workspace migration can include mail, contacts and calendars when the required account access and configuration are in place.

Put those differences into the proposal. Name the source, destination, migration method, excluded records and treatment of errors. Confirm how shared calendars, recurring events, delegation and local archives will be handled. Ask for a sample export when the source system or mailbox condition is uncertain.

• Microsoft: email migration methods
• Microsoft: moving Google Workspace email and calendars

Run a pilot with a working mailbox

Choose a mailbox with old folders, attachments and the features your staff use. Agree the sample checks in advance. Compare the same date range in both systems and investigate missing items. Message totals need interpretation where a service represents labels, duplicates or archived records differently.

Test a new incoming message, an external reply, an alias, a calendar invitation and the staff member's phone. Record the result and the person accepting it. Resolve pilot failures before applying the same method across the company.

Write the cutover and recovery sequence

The plan should name the person making the DNS change, the planned window and the checks immediately afterward. Establish the new mailboxes and sending configuration first. Keep a copy of the prior DNS records and agree what evidence would trigger recovery action.

Test invoices, forms and other application messages separately from staff email. Check the authentication result on an actual received message. Mail sent to Gmail needs to meet its authentication and delivery requirements. A DNS record check alone leaves message behaviour untested.

For a hypothetical ten-person firm, the acceptance sheet might contain ten staff sign-ins, three shared addresses, two application senders and one shared calendar. This is a planning example. The correct test count follows the actual inventory.

• Gmail sender requirements

Close the move with a signed inventory

Retire the previous service after the agreed checks, outstanding errors and retention decisions have been resolved. Record the migration dates, completed batches, exceptions, DNS changes and responsible administrator. Confirm where backups or exports are held and who controls them.

Ask for a written support window and an escalation route for missing mail. Staff should know how to report a problem with the sending address, recipient, time and error message. These details make the final handover useful when an issue appears several days later.