Growth Insight
Business Email Migration Checklist: Google Workspace, Microsoft 365, or Titan Email
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.
Related Questions
Common questions around this topic.
These answers support search visibility and help buyers understand the decision before speaking with the agency.
Should MX records be changed before mailboxes are ready?
No. Create and verify the destination domain, users, aliases, groups, security settings, and migration path before changing production mail delivery.
Do all providers migrate the same email data?
No. Mail, folders, labels, calendars, contacts, rules, signatures, permissions, groups, and archives have provider-specific limitations that should be reviewed before the move.
What are SPF, DKIM, and DMARC?
They are domain-level email authentication controls used to identify permitted senders, verify signed messages, and publish handling and reporting policy. Their records must reflect every legitimate sending service.
Should old email service be cancelled immediately after cutover?
Usually no. Keep the source available through migration verification and any required delta or retry period, then cancel only after mail flow, data, devices, and users are confirmed.
Can Aimsparkk sell and configure business email separately from hosting?
Yes. Business email can be purchased as a separate managed setup or added during hosting onboarding, with provider and DNS requirements tracked separately.
Next Step
Turn the topic into a clear project scope.
Use this insight as a starting point, then map it to the website, service pages, content, campaigns, automation, and tracking work your business actually needs.