Move business email in stages: inventory every mailbox, alias and forwarder; create the target accounts; migrate historical mail; verify folders and item counts; change MX only when the target is ready; test inbound and outbound mail; run a final sync where supported; and keep the old service available until new routing is confirmed. Google Workspace users can keep using Gmail with their new business address.
The risky part of an email move is not creating the new mailbox.
It is the cutover between systems while customers are still sending messages.
Plan the migration so old data is copied before mail routing changes and the old service remains available while you verify the new route.
Inventory the current email system
List more than the visible staff addresses.
Include:
- user mailboxes;
- aliases;
- shared addresses such as
accounts@; - forwarding rules;
- distribution lists;
- catch-all addresses if used;
- calendar and contacts requirements;
- mobile and desktop clients;
- scanners or systems that send mail;
- website forms;
- CRM;
- invoice and accounting platforms.
A move can appear successful until the forgotten quotes@ forwarder stops working.
Confirm who controls the domain and DNS
Before the migration date, make sure the business can edit:
- MX records;
- SPF;
- DKIM;
- DMARC;
- verification TXT records;
- autodiscover or provider-specific DNS where required.
Do not discover during cutover that the former web developer still owns the DNS login.
Document access without sharing passwords in the project spreadsheet.
Choose the migration method by the data you need
Different tools move different data.
For example, Microsoft notes that IMAP migration moves email folders but does not migrate contacts, calendars or tasks. Other migration tools can move broader data depending on the source and target.
Write down what must move:
- email;
- folders/labels;
- read/unread state;
- contacts;
- calendars;
- shared mailboxes;
- aliases;
- signatures;
- rules;
- delegated access.
Then choose the supported migration method.
Do not assume “IMAP migration” means a complete account clone.
Create the target mailboxes before changing MX
Provision users on the new service while mail still routes to the old one.
Check:
- correct primary addresses;
- aliases;
- licences;
- mailbox quotas;
- shared mailbox access;
- admin accounts;
- multi-factor authentication;
- recovery methods.
Send internal test messages within the target system if the provider allows it.
The new mailboxes should exist before external senders are directed to them.
Keep the Gmail app, change the address
Moving to a branded business address does not mean staff must give up the Gmail app or Gmail in a browser if that is the app they already use comfortably. With Google Workspace, a user can work in the same Gmail interface while sending and receiving as name@business.co.za.
The migration work is still real. We create the business mailboxes, copy the agreed mail and contacts with the supported migration method, connect the domain, then test incoming and outgoing mail before the old service is closed. Staff should see the same familiar Gmail workflow, with the correct business address, folders and contacts in place.
If a company uses a different target provider, confirm the mobile and desktop app experience before committing to the move. The right outcome is continuity for the team, not a technically successful migration that disrupts their daily work.
Migrate historical mail before cutover
Start copying data while the old provider still receives new mail.
This reduces the amount that must be handled during the final switch.
Monitor:
- completed mailbox count;
- failed items;
- large messages;
- skipped folders;
- quota issues;
- authentication failures.
Review provider-specific migration limits.
Microsoft, for example, documents IMAP item and message-size limits and warns that IMAP does not carry calendars or contacts.
Verify the copied data
Do not accept “migration completed” as the only check.
Sample several mailboxes:
- oldest expected message;
- newest migrated message;
- important folders;
- Sent items;
- attachments;
- search;
- large customer threads;
- mail from several years.
Compare source and target counts where the tools expose reliable counts.
Record known exclusions so users do not report them later as unexplained data loss.
Lower MX TTL before the switch when appropriate
DNS resolvers cache MX information for the record’s time-to-live.
For migrations where you control DNS and the provider recommends it, lower the MX TTL in advance so external systems refresh the destination more quickly after cutover.
Microsoft’s IMAP migration guidance suggests reducing TTL before the final MX change and then restoring a longer value later.
Do this ahead of time. Lowering TTL one minute before cutover does not immediately remove caches that already stored the old value.
Prepare SPF and DKIM for the new sender
Mail routing and outbound authentication are different changes.
Before staff send through the new provider, prepare the required authentication:
- provider included in SPF;
- DKIM DNS records published;
- DKIM enabled in the new service;
- DMARC impact understood.
Keep the old sender authorised while legitimate mail still leaves through it.
Remove old authorisation only after the old path is no longer used.
Change MX when the target is ready
MX records tell external mail systems where to deliver incoming email.
Change them only after:
- target mailboxes exist;
- initial migration is complete enough;
- users can sign in;
- authentication is prepared;
- support contact is available;
- a rollback or old-system access plan exists.
Record the previous MX values before editing DNS.
Test inbound and outbound mail immediately
Use external accounts from more than one provider where possible.
Test:
- external Gmail to new mailbox;
- new mailbox to Gmail;
- Microsoft/Outlook recipient;
- reply chain;
- attachment;
- alias;
- shared address;
- website form;
- invoice/CRM sender.
Inspect SPF, DKIM and DMARC on outbound test messages.
Confirm the website still sends to the right address after the mail provider changes.
Run a final sync
Mail may arrive at the old system during DNS propagation or between the initial migration and MX change.
Use the migration tool’s final, incremental or delta sync where supported.
Google’s migration tooling documents delta migration for catching new or modified content in supported scenarios. Microsoft’s migration workflows also keep synchronisation running during supported migrations until the administrator stops the migration batch.
Follow the method for your specific source and target.
Keep the old system alive while routing settles
Do not cancel the old provider the moment the new mailbox receives its first message.
Monitor old mailboxes for messages that still arrive there.
Check DNS propagation and external routing.
Keep access long enough to complete final verification under your provider’s migration plan.
The exact overlap period depends on the migration method and DNS environment.
Update every connected system
After the mailboxes move, update systems that depended on the old provider:
- website form recipient;
- SMTP settings;
- CRM;
- accounting software;
- scanner;
- WordPress or ecommerce mailer;
- support desk;
- mobile devices;
- Outlook profiles;
- shared mailbox permissions.
A migration is not complete while an old SMTP password remains embedded in the website.
Preserve the business identity
Customers should continue using the same domain address where possible.
A provider change from cPanel email to Google Workspace or Microsoft 365 should not force customers to learn a new public address unless the business is also changing domain.
If the domain changes, plan forwarding and customer communication separately.
Use a handover checklist
Record:
- Mailboxes and aliases.
- Source provider.
- Target provider.
- Data included/excluded.
- Initial migration result.
- DNS TTL change.
- MX cutover time.
- SPF/DKIM/DMARC status.
- Inbound/outbound test results.
- Final sync result.
- Connected systems updated.
- Old provider cancellation date.
Do not close the old account until the evidence supports it.
IDJoy can coordinate website, DNS and business-email changes through its professional email service options so the form, domain and mailbox migration are tested as one system.