A business email move affects more than the inbox. An address might receive customer orders, reset an account password, send website enquiries or appear on invoices. The move is ready when those jobs work at the destination—not simply when an administrator has changed the mail records.
Before choosing a cutover date, write down what exists, what will move and who will check the result. The checklist below is designed for a business owner and the person who manages the company’s email to complete together.
1. Confirm who controls the domain and DNS
Domain registration, DNS hosting, website hosting and email can be supplied by different companies. Record which account controls each service and confirm that an authorised person can sign in. Keep an alternative recovery address that will remain accessible during the move.
Changing email providers does not normally require transferring the domain or moving the website. Save a copy of the DNS zone before making changes, and identify the specific mail records the new provider needs. Do not replace an entire DNS zone with an email setup template.
- Name the person authorised to approve mail-routing changes.
- Record the existing MX records and their time-to-live values.
- Identify website, payment, verification and other DNS records that must remain in place.
2. Inventory addresses, data and hidden senders
List active mailboxes and their data volumes, then account for shared addresses, aliases, groups, forwarders and automatic replies. An address such as accounts@example.com may be an alias today but need a separate mailbox tomorrow. Decide that mapping before anyone starts copying data.
Ask each department which systems send email. Website forms, invoicing software, booking systems, scanners and newsletters may still rely on the old provider after employee mailboxes have moved.
- Check whether any messages are stored only on a computer or phone.
- Identify delegated access, shared calendars, contacts and tasks separately.
- Record retention, export and archive requirements with the responsible person.
3. Agree exactly what the migration includes
Ask for a written migration scope that names the source, destination, supported data types, exclusions and validation process. Do not assume that copying an inbox also transfers signatures, rules, contacts, calendars or files.
Microsoft’s IMAP migration documentation, linked below, gives a useful example of this boundary: its IMAP method copies email folders, but not contacts, calendar items or tasks. Confirm the capabilities of the actual migration method proposed for your business.
Discuss authentication requirements, unusually large messages, folder mapping, duplicate handling and any user work needed after the move. Agree how source data will be backed up or exported, and confirm that the export can be read before relying on it.
4. Test a representative mailbox first
Choose a pilot mailbox that reflects real work: recent and older messages, nested folders, sent mail, attachments and the devices the team uses. Compare representative messages and folders at the destination. Counts are useful, but differences in folder and label handling can make a simple total misleading.
Test sign-in, replies, search, attachments, inbound delivery and outbound authentication. Include a shared address or application sender if it is important to the business. Record unresolved problems and assign an owner before expanding the move.
5. Plan cutover, overlap and recovery
Agree a change window, the person publishing DNS, the person checking delivery and the support contact for users. Prepare destination mailboxes and authentication records first. Review caching and TTLs in advance; reducing a TTL at the moment of cutover does not immediately expire records already cached elsewhere.
Keep the old service available for an agreed overlap period and arrange a final synchronisation where the migration method supports it. Some messages can still arrive at the old system while senders use cached DNS.
Write down the conditions that would trigger a pause or rollback. Restoring old MX records changes routing; it does not automatically move messages that have already reached the new provider. A recovery plan must account for mail received by both systems.
6. Sign off the result before cancelling anything
Ask named users to confirm their everyday workflows. Check an external incoming message, an external outgoing message and a reply. Verify that application senders and shared addresses work, and inspect the receiving system’s authentication results for controlled test messages.
Close the migration only after the agreed data checks, final synchronisation and access checks are complete. Keep a record of remaining exceptions and when source accounts, credentials and obsolete DNS records will be retired.
If you are considering Envelaro, request a migration assessment with your current provider, mailbox count, approximate data volume and dependencies. Assessment and evaluation come before a production cutover; migration execution requires an active plan and an agreed paid migration package.
Primary sources
Provider interfaces and requirements change. Check the linked source before applying a production change.