Change the service.
Keep the thread.

Know what exists.

Record domains, mailboxes, aliases, groups, forwarding, shared addresses, devices and applications that send mail. Include website forms, scanners, booking systems and billing tools.

Confirm access to the domain account and DNS. Record the current settings securely, the change contacts and the approved source of truth.

Agree the destination.

Confirm platform features, licences, storage, access permissions, authentication and migration support. Decide how messages and other required data will be copied, how the copy will be checked and what cannot move automatically.

Prepare users and recovery contacts. Keep existing service access available for the agreed transition period.

Prove the important journeys.

Test an approved pilot: inbound and outbound mail, external replies, aliases, shared-address permissions, devices and application sending. Check relevant DNS and sending authentication using the destination provider’s instructions.

Do not assume changing MX records moves old messages, calendars, contacts or sending permissions. Each required component needs its own acceptance check.

Make an agreed change.

Schedule the DNS change with responsible people available. Follow the migration plan, watch for delivery failures and keep users informed. DNS caches and in-flight messages mean a change is not instant everywhere.

Define when to pause or reverse a change before starting. Reverting DNS does not undo every message delivery or data change; recovery must account for activity on both systems.

Finish deliberately.

Reconcile required data, repeat delivery tests and check real user workflows. Review forwarding, obsolete accounts and access. Remove the old service only after agreed acceptance and retention arrangements are complete.