Pre-Migration Assessment: The 1-Page Report That Saves You

You cannot migrate what you have not inventoried. Every migration that "discovered" a 60GB shared mailbox three days before cutover started the same way: someone skipped the assessment, or did a half-hearted version of it, then tried to absorb the surprise later. A proper pre-migration assessment takes two to three working days, produces a 1-page report your stakeholders will actually read, and gives you a number for every risk before you commit to a date. This guide tells you what to inventory, in what order, and how to write the report.

What the assessment is actually for#

A pre-migration assessment answers four questions:

1. What are you moving?
2. Where is it going?
3. What could fail?
4. When and how long?

If your assessment does not produce concrete numerical answers to all four, it is not finished. "About 500 mailboxes" is not an answer. "514 mailboxes, 11 of which are over 50GB, three of which are inactive but on legal hold" is an answer.

The 1-page report is the artefact. Everything else — the spreadsheets, the PowerShell exports, the runbook drafts — supports it. If your CFO or your service-delivery lead cannot understand the migration in 90 seconds from the 1-page report, you have written the wrong document.

The assessment workflow#

Run the assessment in this order. Each step depends on the previous one being complete.

1. Mailbox and resource inventory — what exists, who owns it, how big
2. Identity and authentication inventory — MFA, conditional access, federated logins
3. Mail flow and DNS inventory — MX, SPF, DKIM, DMARC, autodiscover, TTLs
4. Compliance and retention inventory — holds, archives, retention policies
5. Network and endpoint inventory — bandwidth, mobile estate, client mix
6. Risk scoring and report writing

You can run steps 1, 2, and 3 in parallel if you have the people. Step 4 needs the output of step 1, so do not start it until you have the mailbox list.

For the broader plan this feeds into, pair this assessment with the email migration checklist and the email migration project plan so each finding has somewhere to go.

Step 1: mailbox and resource inventory#

This is the longest step. Take the time to do it properly because everything else depends on these numbers.

What to count#

For each mailbox you find, capture:

• Email address (primary SMTP)
• Display name
• Mailbox type: user, shared, room, equipment, group
• Owner (for shared mailboxes — actual human, not "IT")
• Total size in MB
• Item count
• Last login date
• Last sent-item date
• Litigation/retention hold status
• Forwarding rules to external addresses
• Delegate list (for delegated calendars and Send As)
• Archive mailbox size if archive is enabled

The two dates matter. "Last login" tells you if a user is real; "last sent-item" tells you if a mailbox is active. A mailbox with a recent login but no sent items in 18 months is probably a person who only reads; treat it as active but tag for the post-migration "still using this?" check.

What you will find that you did not expect#

In every assessment, you will discover at least three of these:

• A shared mailbox with no current owner because the original owner left
• A distribution list with external members nobody knew about
• A mailbox that was supposed to be decommissioned in 2019 and is still receiving mail
• A "test" mailbox with 40GB of forwarded production mail
• A meeting room mailbox that is double-booked because two calendars are synced to it
• A service account mailbox used by an application that nobody can identify

Each of these becomes a risk line in your final report. Do not try to resolve them during the assessment — that is a separate exercise. Just record them.

Size distribution matters more than total size#

The total payload tells you how long the migration will take in the average case. The size distribution tells you where the long tail is. A 500-mailbox migration where the median is 4GB but five mailboxes are over 80GB will take roughly the same amount of time as a 500-mailbox migration where every mailbox is 8GB, but it will fail differently. The 80GB mailboxes will be the ones that throw Folder UTF-7 conversion error or hit the destination's per-message size limit on a vintage 60MB attachment.

Record the size distribution as: mean, median, 95th percentile, max. Plot the top 20 mailboxes by size. Decide for each of the top 20 whether you migrate them as-is, archive them first, or treat them as a separate wave.

Step 2: identity and authentication#

The mailbox is half the story. The identity is the other half. Many migrations have failed not because the mail did not move, but because users could not sign in to the new system after the move.

What to inventory#

• Source IdP (Active Directory, Azure AD, Google Workspace, Okta, etc.)
• Destination IdP and whether it matches the source
• Authentication method: password, federation, pass-through, password hash sync
• MFA enforcement (per user, per group, conditional)
• Conditional access policies that touch mail (block legacy auth, require compliant device, require MFA from outside corporate IP)
• App passwords in use (these break with modern auth)
• OAuth app consent for the source mailbox (Zoom, Salesforce, etc. that have read access)
• Number of users without MFA enrolled

The last one matters more than people expect. If 12% of your users have not enrolled in MFA at the source, they will fail their first sign-in to the destination if the destination requires MFA. Plan a pre-cutover MFA enrolment campaign or you will get 12% of your population calling the help desk in the first 30 minutes.

Service accounts#

Service accounts that send or receive mail are the silent killer of migration day. Inventory:

• The service account email address
• The application that uses it
• The authentication method (basic auth, OAuth, app password, SMTP relay)
• The owner of the application (a human name, not a team)
• Whether the application can be reconfigured for OAuth before cutover

Any service account still using basic SMTP auth at cutover is a service account that will break. Get the application owners on the project plan early.

Step 3: mail flow and DNS#

DNS is where good migrations come unstuck. Three records matter most.

MX, SPF, DKIM, DMARC, autodiscover#

For your primary domain and every secondary domain that receives mail:

• Current MX record(s) and their priority
• Current SPF record — every include, every IP block
• Current DKIM selectors and their public keys
• Current DMARC policy (none, quarantine, reject) and the rua/ruf reporting addresses
• Current autodiscover record (CNAME or A) and what it points to
• TTL on each of the above

The SPF audit is the most underestimated piece of the assessment. Companies routinely have SPF records that include 15 senders, half of which have not been used in two years. The migration is your opportunity to clean them up — but you must inventory them first so you do not remove something that turns out to be still in use.

For background on how MX records affect cutover sequencing, see the MX record glossary entry.

TTL planning#

Note current TTLs. Do not change them yet. Plan to lower them to 300 seconds 48–72 hours before cutover, then raise them again afterwards. Recording the current TTL in your assessment makes the rollback simple if you need it.

Inbound and outbound flow#

Trace the actual path of an email in and out of your environment.

Inbound: external sender → MX → spam filter? → archive? → mail server → mailbox. Each hop is something you may need to reconfigure.

Outbound: client → mail server → outbound gateway? → external recipient. The outbound gateway often gets forgotten and is the cause of post-migration "we cannot send to Gmail" tickets.

Step 4: compliance and retention#

This step is short to describe and long to do. The deliverable is a list of every legal, retention, or compliance obligation that touches mailboxes you are about to move.

What to capture#

• Any mailbox on litigation hold, with the case reference
• Any mailbox on retention hold, with the policy
• Any retention policy in force (e.g. "delete everything after 7 years")
• Any journaling rule (copy of every message sent to a separate archive)
• Any data residency requirement (mail must stay in EU, US, etc.)
• Any regulator-specific requirement (FINRA, HIPAA, GDPR-derived obligations)

The destination platform must be able to honour every one of these. If it cannot, you have an architectural decision to make before you cut over, not after.

Step 5: network and endpoint#

The migration runs as fast as the slowest link between source and destination — or, more often, as fast as the per-IP throttle the destination imposes on you.

What to measure#

• Egress bandwidth available on the network from which the migration tool will run
• Whether the migration tool will run from on-prem, from a cloud VM, or from end-user laptops
• The per-IP connection limit you can reasonably expect from the destination (test it; do not assume)
• The mobile estate: iOS, Android, blend; managed (MDM) or BYOD
• The desktop client mix: Outlook, Apple Mail, Thunderbird, native webmail
• Browser mix for webmail users

Mobile and desktop client inventory matters because reconfiguration after cutover is the single largest source of post-migration support load. If 80% of your users are on managed iOS, you can push an MDM profile and they will not need to do anything. If 80% are BYOD Android, every one of them needs a setup walkthrough.

Step 6: writing the 1-page report#

The report has six sections. No more, no less. If you cannot fit it on one page in 11-point font, cut.

Section 1: scope#

Two lines:

Migrating [count] mailboxes ([X] user, [Y] shared, [Z] resource) and [N] distribution lists from [Source platform] to [Destination platform]. Domains in scope: [list]. Total payload: [TB / GB].

Section 2: timeline#

Three lines:

Assessment: complete. Estimated migration duration: [N weeks]. Proposed cutover window: [date, time, timezone]. DNS freeze: 48 hours from [date].

Section 3: top 5 risks#

Numbered, one line each, with a probability and impact. Example:

1. 11 mailboxes over 50GB may exceed per-mailbox time budget — Medium / High
2. 27 service accounts still on basic auth, owners not all identified — High / Medium
3. 4 mail-enabled distribution lists with external members not approved by security — Medium / Medium
4. SPF record contains 4 unused includes that must be cleaned before cutover — Low / Low
5. 12% of users not enrolled in MFA at source — High / High

Section 4: assumptions#

Five short lines that, if any one is wrong, the plan needs revision. Stakeholders sign off on these.

Section 5: cost#

The licensing line for the destination, the migration tool cost, and any consulting if applicable. Do not pad. Stakeholders trust round, defensible numbers more than they trust precision they suspect is fake.

Section 6: recommendation#

One paragraph. "Recommend proceeding with [strategy]. Cutover on [date] is achievable subject to the assumptions above. Risk 5 (MFA enrolment) requires a 4-week prep campaign starting [date]."

The recommendation is the most important sentence in the document. Write it last. Write it confidently. If you cannot recommend proceeding, say so explicitly and propose an alternative.

What to do with the longer outputs#

The 1-page report is for the stakeholders. The underlying artefacts are for the migration team.

Keep these in your migration workspace:

• Full mailbox inventory CSV
• Service account list with application owners
• DNS record snapshot (MX, SPF, DKIM, DMARC, autodiscover, TTLs)
• Compliance hold register
• Top-20 largest mailboxes detail sheet
• Identity gap list (users without MFA, basic-auth-only apps)

These artefacts are the working memory of the migration. They feed the runbook, the wave plan, and — after cutover — the post-migration validation checks.

Common assessment mistakes#

A handful of patterns recur across assessments.

Skipping shared mailboxes. Shared mailboxes are not user mailboxes. They have separate licensing rules, separate delegation, and often separate retention. Treat them as a category in their own right.

Trusting the displayed mailbox count. Admin consoles often hide soft-deleted mailboxes, archive mailboxes, and inactive holds. The displayed number is usually 10–20% smaller than the real count. Always export and count yourself.

Ignoring autodiscover. If autodiscover is misconfigured, every Outlook client in your environment will fail to find the new server until DNS propagates. Inventory the current autodiscover record and the planned new one before you announce a cutover date.

Underestimating mobile. "Most people use webmail" is rarely true. Even when self-reported, the mobile reconfiguration step is what generates the largest single bucket of tickets after cutover.

Writing a 30-page report. A 30-page report is a confession that you cannot pick what matters. Pick what matters.

A pre-cutover checklist derived from the assessment#

If your 1-page report goes green, the following actions kick off the migration project. Each one traces back to a specific section of the assessment.

• Resolve all "unknown owner" shared mailboxes
• Enroll the remaining 12% of users in MFA
• Migrate or retire all basic-auth service accounts
• Clean SPF includes
• Lower DNS TTLs at T-2 days
• Schedule the cutover wave plan
• Brief the help desk using the migration runbook

The full operational guide that connects these is the complete email migration guide.

Tools for the inventory work#

You do not need a specialised assessment product to do this work. Native admin tooling — PowerShell for Exchange and Microsoft 365, the Google Workspace admin SDK, IMAP server queries for self-hosted estates — gives you everything you need. The discipline is in writing the queries down so the inventory is reproducible, not in the tool choice.

If you want to validate IMAP-side mailbox sizes and item counts against what the admin console reports, an IMAP-native scanner like Mailbox Taxi can give you a second reading. Discrepancies between admin-side reporting and IMAP-side reality are common; the assessment is the right time to find them.