Business Email Migration Checklist for Small Teams

Moving business email is a controlled handover of company communications. The target is not simply a successful login: the right people must receive new mail, retain the history they need and continue using the systems that send customer messages.

Use this checklist to plan a move to Aiinak Workspace with your administrator. It is a planning guide, not a promise of an automatic migration tool or full compatibility with every source provider. Confirm the transfer method and acceptance evidence for your actual accounts before changing email routing.

Make a mailbox and sender inventory#

Record every mailbox, its owner, approximate size and required history. Identify aliases, forwarding, groups, shared addresses and any addresses published on your website or printed materials. Confirm which of these behaviours your destination configuration supports; do not assume that creating a mailbox recreates every source-provider feature.

List applications that send from the domain, including contact forms, invoices, CRM, support and newsletters. Record who controls their credentials and sender configuration without placing passwords in the project checklist. Keep the people responsible for DNS and the old email service involved through cutover.

Agree the destination scope and allowances#

Create the business workspace and review its mailbox count, email storage and shared file capacity. A personal Aiinak account can be your sign-in identity, while the company workspace remains a separate setup. Buying personal storage does not increase the company’s mailbox count.

Review current Workspace allowances and decide which users and data belong in the pilot. AI employees, Twin and paid app upgrades have separate inclusions. Agree account recovery, administration, support expectations and any contractual requirements before proceeding.

Pilot a representative user#

Use a user with real workflow requirements rather than an empty mailbox alone. Test signing in, sending externally, receiving externally, replies and attachments. Check the visible From address and message authentication headers. Verify access from the clients the team intends to use, based on supported configuration.

Test the chosen method for transferring message history and confirm folders, dates, attachments and counts where applicable. Separately plan contacts, calendars and documents. An email-routing change does not migrate those records, and a successful file transfer does not preserve every sharing permission automatically.

Prepare DNS and a rollback decision#

Keep a copy of the current MX and authentication records. Use the exact values supplied for the destination domain. Coordinate SPF, DKIM and DMARC with every authorised sender, and review existing DNS TTLs so the team understands the transition window.

Name a cutover owner and a rollback decision maker. Agree what failure would stop the switch, who will monitor both services and how messages received during a transition will be reconciled. A rollback is more than restoring a DNS record: account for mail already delivered to either provider.

Run cutover acceptance checks#

• Every required address exists and the correct person can access it.
• External inbound and outbound messages, replies and attachments succeed.
• Website and invoicing senders continue to work with the intended identity.
• Transferred history matches the agreed scope and exceptions are recorded.
• Administrators can manage the team and users know where to obtain help.

Keep the old service until the agreed checks pass and retained data has been reconciled. Do not delete the source accounts merely because the first message arrived. Record unresolved issues, owners and deadlines before closing the migration.

Start with the custom-domain setup guide, review Google Workspace alternative evaluation criteria, or create your business workspace for a pilot.