Business email / Checklist
Moving business email? Account for the calendars and shared addresses too.
Imagine a two-person office with two inboxes, an accounts address and a shared calendar. A quote that simply says “move the email” leaves several questions unanswered.
I would put those items into the brief before choosing a migration method. People need to know where their working information will be when they start using the new service.
List what people actually use
Include individual mailboxes, shared addresses and who can access them. Then add calendars, contacts, old archives and any rules or forwarding arrangements that staff rely on.
An address may be a mailbox, an alias or a group. Record its purpose and the access people need in the destination service; copying the spelling of an address does not establish that its behaviour has been recreated.
Ask about devices and applications too. A phone, desktop mail application or website sending service may need its own part of the change plan.
| Item in the fictional office | Question for the move |
|---|---|
| Two individual inboxes | Which source maps to each destination account? |
| Accounts address | Who receives it and who needs permission to send? |
| Shared calendar | Which method moves its contents and access? |
| Older archive | Where is it stored and how will staff find it? |
Check what the migration method includes
Microsoft’s IMAP migration documentation says that method moves mail folders, while contacts, calendar items and tasks are outside its scope. That is a reason to plan those items separately, rather than discover the gap after the inboxes have moved.
The source and workflow matter. Google’s data import documentation has different paths for IMAP and Exchange Online. Its Exchange Online workflow can include calendars and contacts, subject to its requirements; the IMAP path copies email. Avoid assuming every tool moves the same information.
Against each inventory item, name the proposed method and what will be checked. Keep any item needing separate work visible in the scope and quote.
Source: Microsoft: IMAP mailbox migration scope; Google Workspace: data import methods and reports
Plan existing content and new mail separately
Copying yesterday’s messages does not direct tomorrow’s mail to the new service. Account for the domain’s mail routing, the provider’s authentication requirements and the services that send for the business.
Agree the transition order and who will make each change. Keep the old service available for the agreed verification and recovery period, rather than closing it as soon as an import reports it has finished.
Google describes import reports and later delta imports for supported workflows. Those reports help identify failed or skipped content and later additions; use them alongside the checks agreed for the business.
Decide what completion looks like before the move
Agree samples of old messages and calendar items to inspect, then plan authorised sending and receiving checks. Confirm access to shared addresses and the devices staff actually use. Keep a list of unresolved items with an owner.
Keep the agreed checks, results and unresolved items with the migration record. Close the old service only after the agreed sign-off and recovery arrangements have been dealt with.
Sources
Checked on 23 October 2026.
- Microsoft: IMAP mailbox migration scope
IMAP migration includes mail folders but excludes contacts, calendars and tasks.
- Google Workspace: data import methods and reports
Source-specific import workflows, account mapping, reports and supported later delta imports.