Prepare an Exchange migration: inventory mailboxes, addresses and dependencies

A mailbox list alone is not a migration plan. Aliases, delegation, calendars and sending applications must also be known. This guide builds an inventory; it starts no migration and changes neither DNS nor permissions.

Define scope and data sources

Record source system and version, target tenant, responsible person and inventory date. Distinguish on-premises Exchange, Exchange Online and other mail platforms. A cloud query is not a complete inventory of an on-premises server. Collect only authorized objects and store the inventory in the protected project folder without passwords or tokens.

One traceable row per object

  1. Record stable object ID, display name, sign-in identifier, primary SMTP address, all additional addresses, mailbox type and owner. The sign-in identifier, Alias property and additional SMTP addresses are different things.
  2. Add mailbox size, archive, relevant retention requirements and required target license. Separate user, shared and resource mailboxes. Keep distribution lists, contacts, public folders and Microsoft 365 groups in separate lists instead of treating them as ordinary user mailboxes.
  3. For existing Exchange Online mailboxes, an authorized administrator can read Get-EXOMailbox -ResultSize Unlimited -Properties EmailAddresses. Without explicit ResultSize, the default is 1,000. The result is a starting point for cloud mailbox objects, not a complete export of every recipient type, size and permission.
  4. Map every source object to a planned target and responsible person. Explicitly mark missing data and conflicting addresses; do not resolve them through unreviewed deletion or renaming.

Add dependencies

Inventory Full Access, sending rights, group membership, forwarding and important Inbox rules. Ask about shared calendars, room bookings, mobile devices, local PST files and scanners, printers and applications sending email. For connections, record only methods, endpoints and owners, not secrets. Also document mail routing, connectors, accepted domains and DNS responsibility.

Choose a migration path and pilot

Only after inventory, select a supported migration path using current Microsoft prerequisites for source and target. IMAP transfers only emails from mail folders, not contacts, calendars or tasks; target mailboxes must already exist. A successful mail import therefore does not prove complete migration.

Plan a representative pilot, backup, rollback criteria and eventual cutover. Define acceptance tests beforehand: sign-in, internal and external delivery, alias reception, calendars, delegation and application sending. In the pilot, compare agreed reference objects and error/skipped-item reports, not just a green overall status. Assign an owner and due date to unresolved dependencies. Only an agreed inventory with clarified exceptions provides the basis for the separately authorized move.

Sources