Migrating an Old Mailbox to a New System: A Practical Checklist

For many companies, email is more than correspondence. It is an archive of agreements, invoices and conversations with clients. So when you move from an old mail service to Microsoft 365 or Google Workspace, the main question is: will we keep all of our messages? The good news is that, done in the right order, the risk is greatly reduced. Below is a simple checklist.

1. Start with an inventory

Before migrating, write down what you have now:

• all mailboxes and the approximate size of each;
• aliases (additional addresses on the same mailbox), shared mailboxes, forwards and group addresses, for example info@ or sales@;
• who reads mail on which device: computer, phone, tablet;
• whether there are automatic archiving or deletion rules on the server.

This list will show you what to migrate and what not to forget.

2. Find out what is transferred and what is not

An IMAP-based migration on both platforms mainly transfers mail folders. According to Microsoft's documentation, only the user's inbox and other mail folders are migrated. Microsoft's explanations also state that contacts, calendar entries and tasks are not transferred this way. So you need to migrate the calendar and address book separately, or move them manually. The same applies to mail rules that you had set up in the mailbox.

Microsoft's IMAP migration also has limits. A maximum of 500,000 messages can be migrated per mailbox, and a single message must not exceed 35 MB. If someone has a very large or many-year-old mailbox, take this into account in advance.

3. Prepare the new system

On the new platform, create an account for each person in advance and add the required aliases. For each user, Google Workspace's data migration service asks for the old mailbox address, its IMAP password and the new Workspace address. On some IMAP servers a regular password is not enough and a separate app-specific password is needed. The migration must be started and run by a super administrator. IMAP must be enabled on both the old and the new account. For a small team, up to 20 users, you can enter the data directly in the admin console; for a larger one, a CSV file is required. One old address cannot be migrated to more than one new user.

4. Turn off archiving rules

This step often goes unnoticed. Microsoft's migration tool cannot see archiving and mail records management rules that are active in the old system. If such a rule deletes or moves a message during the migration, the tool will count that message as “lost”. This makes it harder to tell what was actually lost. Microsoft recommends turning off such rules before migrating.

5. DNS: lower the MX record TTL in advance

Migrating mail is two separate jobs: copying the old messages and redirecting new messages through MX records. MX records determine which server your domain's mail goes to. TTL specifies how long other servers on the internet keep this record. If the TTL is long, the change may not propagate for a whole day, and new messages may keep arriving at the old server. According to one practical recommendation, you should lower the MX record TTL at least 24-48 hours before the switch, for example to 300 seconds. Some DNS providers limit the minimum value, so first check what range is allowed. On the day of the switch, it is already too late to do this.

6. One test mailbox first

Before migrating everyone's mail, migrate one real mailbox as a trial. Check the folder structure, search, opening of attachments and the number of messages. If something goes wrong, you will fix it now rather than after migrating the whole company.

7. Switch day: copying messages and MX

The correct order is this: first the main copy, then the MX record switch, then an additional synchronization. After the MX change, some messages may still arrive at the old server, because DNS propagation takes time. So after the switch, run a repeated (delta) synchronization so that these messages come over as well. When switching, delete the old MX records so that mail does not accidentally keep going to the old system. One guide advises keeping the old mailbox active for about another 30 days, until you are sure that nothing has been missed.

8. After the switch

• check that new messages are arriving in and leaving from the new system;
• on the new provider, recheck the SPF, DKIM and DMARC records so that your messages do not end up in spam (we have a separate article on this topic on our blog);
• send everyone the new sign-in instructions, set up mail on phones and in Outlook, and turn on two-step authentication;
• when everything is stable, set the TTL back to its usual value. Only after that, close the old service.

In short, the rule is simple: first the inventory and preparation, then copying the messages, and switching the MX record last. If you are thinking of one or two mailboxes, you can do this yourself. If you have many employees, shared mailboxes or a very large archive, it is better to ask for help.

If you need support, Appy.ge is a Georgian IT company and an official Microsoft CSP partner. It also sets up Google Workspace and will help you plan and carry out your mail migration.

Sources:
• What you need to know about migrating your IMAP mailboxes to Microsoft 365 or Office 365 - Microsoft Learn — https://learn.microsoft.com/en-us/exchange/mailbox-migration/migrating-imap-mailboxes/migrating-imap-mailboxes
• migrate IMAP to office 365 - Microsoft Q&A — https://learn.microsoft.com/en-us/answers/questions/5887227/migrate-imap-to-office-365
• Migrate email from an IMAP account - Google Workspace Admin Help — https://knowledge.workspace.google.com/admin/migrate/migrate-email-from-an-imap-account?hl=en
• Business Email Migration Guide: 10 Steps for 2026 - Prestige Technologies — https://www.prestigetechnologies.com/blog/business-email-migration-guide/