A safe business email migration prepares the destination before changing MX records. The business should inventory mailboxes, aliases, groups, shared addresses, calendars, contacts, archives, devices, applications, and every service that sends email using the domain.
Google Workspace, Microsoft 365, and Titan Email can all support branded business email. The right choice depends on collaboration tools, administration, licensing, migration source, user habits, compliance needs, and budget. The migration plan matters as much as the provider name.
1. Inventory the current environment
- Primary mailboxes and mailbox sizes
- Aliases, forwarding addresses, groups, shared mailboxes, and distribution lists
- Calendars, contacts, tasks, archives, rules, signatures, permissions, and delegates
- Website forms, CRM, ecommerce, accounting, ticketing, newsletters, scanners, and applications that send mail
- Mobile devices and desktop email clients
- Retention, legal hold, backup, or eDiscovery requirements
2. Confirm what the selected migration method supports
Do not assume that every folder, rule, permission, or collaboration object will move. Google’s migration documentation lists supported and unsupported Outlook data. Microsoft provides different paths for on-premises, hybrid, and cross-tenant mailbox moves. For any other provider, confirm supported migration methods, required domain verification, mailbox preparation, and data limitations before the move.
3. Prepare the destination
- Add and verify the business domain without changing production MX records.
- Create licensed users, aliases, groups, and shared addresses.
- Configure administrators, MFA, password policy, recovery contacts, and least-privilege access.
- Record the provider’s MX, SPF, DKIM, verification, and any autodiscover records.
- Plan DMARC carefully so legitimate senders are not rejected unexpectedly.
- Lower DNS TTL in advance when the existing provider and DNS service allow it.
4. Run a pilot migration
Choose a small group that represents real use: a normal user, an executive or owner, a shared address, a large mailbox, and a user with calendars or delegates. Check mail, folders or labels, dates, attachments, contacts, calendars, permissions, and sending from every required alias.
5. Plan the cutover
| Before MX change | During cutover | After cutover |
|---|---|---|
| Destination users ready, pilot passed, DNS records prepared, support contacts notified | Change MX and authentication records, monitor both providers, record propagation | Verify internal and external mail, forms, applications, spam handling, mobile devices, and aliases |
| Source access retained and migration report reviewed | Run the planned primary or delta migration | Retry failures, reconcile counts, and keep source access through the agreed validation period |
6. Protect website and application mail
Website forms should not rely on an arbitrary server identity. Record which service sends transactional mail, which domain or subdomain it uses, and how it is authenticated. SPF must include all legitimate senders without exceeding technical limits, DKIM should be enabled where supported, and DMARC policy should be introduced with reporting and verification.
7. Keep an ownership and handoff record
The business should receive provider-admin ownership, mailbox assignments, billing responsibility, DNS records, recovery contacts, migration results, known limitations, and a process for adding or removing users. Passwords should be delivered through an appropriate secure channel, not placed into ordinary project notes.
Provider documentation
- Google Workspace: what Outlook data is and is not migrated
- Google Workspace Admin: Gmail data migration workflow
- Microsoft 365 mail migration advisor
- Microsoft 365 cross-tenant mailbox migration
Review Aimsparkk business email services. Email can be purchased separately or added during hosting onboarding, while the provider account and DNS records remain clearly documented.