Workstream 01
Test the server and directory assumptions first
Document the Exchange version and patch level, accepted domains, mailbox counts and sizes, archive policies, mail routing, third-party applications and current DNS authentication. Identify whether users are created in local Active Directory and synchronised to Microsoft Entra ID; that may determine the available migration and ongoing identity management approach.
Inspect recipient types separately: ordinary user mailboxes, shared mailboxes, public folders, rooms and service accounts may not all follow the same path. Retention and legal hold requirements belong in the discovery worksheet, because a technically complete move can still fail a records obligation if data was excluded without consent.
| Inventory element | Why it changes the plan | Acceptance evidence |
|---|---|---|
| Exchange version and topology | Supported migration methods differ | Architecture and compatibility review |
| Directory source | Identity and coexistence may depend on AD | User provisioning and login test |
| Mail flow and relays | External systems may still target old hosts | Inbound/outbound, SPF/DKIM checks |
| Shared and retained data | Different recipient or retention workflows | Owner and records sign-off |
Workstream 02
Pick a cutover shape the business can support
A small organisation may choose a simpler migration with a single agreed cutover, while a larger or more complex estate may need staged coexistence. Neither is automatically better. Consider the number of departments, weekend working, staff travel, external mail dependencies and how quickly the source server can be restored or kept available when validation fails.
Move a representative pilot that includes a typical mailbox, a large mailbox and a shared or delegated case. Rehearse Outlook sign-in, search, sending, receiving, calendar delegation and mobile device behaviour. Capture discovered exceptions; don't silently change the scope to call the test successful.
What to capture before the decision
- Identify supported migration route before licensing software
- Inventory shared, service and application mail dependencies
- Pilot with ordinary, large and delegated mailboxes
- Document stop/go criteria and routing backout conditions
- Confirm mailbox, calendar and client acceptance checks
Workstream 03
Decommissioning is a separate deliverable
The Exchange server may have duties beyond hosting ordinary inboxes. SMTP relays, address-book lookups, printers, scanners and on-premises identity dependencies can continue to call it long after every user appears in Microsoft 365. Retiring the machine is therefore a later decision based on evidence, not an automatic consequence of the last migration batch finishing.
A proposal should distinguish discovery, engineering changes, the mailbox transfer, DNS and mail-flow cutover, user communications and the approved decommissioning procedure. A clean acceptance report lists exceptions and responsible owners, as well as what was actually moved.
Workstream 04
Exchange source topology changes the migration design
An on-premises Exchange organisation with hybrid identity, public folders, delegated permissions and compliance requirements is fundamentally different from a single-hosted Exchange mailbox set. Record Exchange version and support status, mailbox databases, network reachability, Entra Connect synchronisation, certificates, Autodiscover, public folders and any journaling or transport rules. The right method must be chosen against supported Microsoft paths, not the fact that both platforms are called Exchange.
Treat the cutover of mail flow separately from mailbox movement. Capture connectors, TLS requirements, spam filtering, mobile clients, device management, mail-enabled application senders and helpdesk ownership. Preserve the exact scope of any legacy Exchange shutdown, including archival, discovery and legal-retention requirements.
| Environment detail | Why it matters | Evidence before change |
|---|---|---|
| Exchange version and hybrid state | Controls supported migration/coexistence path | Topology and health review |
| Directory synchronisation | Identity source of authority and writeback | Sync design and UPN mapping |
| Transport/journaling rules | Mail flow and compliance may depend on legacy routing | Rule and connector inventory |
| Public folders/shared access | Not equivalent to user mailbox moves | Owner-approved separate migration plan |
Workstream 05
A safe Exchange acceptance wave
Use a pilot population that includes a large mailbox, delegated users and any shared objects the business considers critical. Record expected client configuration and fallback. After moving, test Outlook profile discovery, modern sign-in, mobile access, shared mailbox permissions, recipient autocomplete and a real external send/reply path.
Agree when the on-premises environment may be retired and what records must remain available. Removing infrastructure before completing identity, app-routing and compliance dependencies creates risks that do not show in an Exchange move report.
What to capture before the decision
- Verify supported source versions and hybrid prerequisites
- Test a real delegated user and external mail routing
- Map public folders and legacy connectors
- Record post-move identity and client support
- Retire legacy components only with explicit owner approval
Treat the old server as a dependency to retire deliberately. A well-scoped migration leaves the business with a repeatable mail-flow test and an honest list of remaining infrastructure, rather than a progress bar that says 100%.
Source documents and limitations
These references establish current vendor behaviour; they do not verify an individual customer's configuration or imply Microsoft affiliation. Technical claims should be rechecked before execution.