Old Mailbox to New Mailbox Migration

Executive summary

This paper defines a controlled same-tenant migration pattern for copying the contents of a retired Exchange Online mailbox into a separately provisioned active mailbox. The recommended design uses the old mailbox only after Exchange Online reports it as soft-deleted or inactive, preserves its identity evidence, reassigns approved SMTP aliases to the new mailbox, adds the old LegacyExchangeDN as an X500 proxy address, and then uses the Mailbox Replication Service through New-MailboxRestoreRequest to copy content.

The operation is a content restore, not an identity merge. It does not by itself migrate the old Microsoft Entra identity, OneDrive, Teams data, licenses, group membership, mailbox-level permissions, delegates, mobile partnerships, or client configuration. Those dependencies require separate workstreams or acceptance decisions.

What this paper corrects

1. Deletion is a gated cutover action, not a routine first step. The exact operation depends on whether the object is cloud-only or synchronized from on-premises.

2. A 30-day soft-deleted state is a recovery window, not a backup strategy. The source must be positively verified before any restore begins.

3. The X500 address is the durable LegacyExchangeDN compatibility mechanism. Microsoft documents that AllowLegacyDNMismatch is being deprecated in the cloud; the design therefore adds X500 and does not rely on the switch.

4. Archive restore is expressed with -SourceIsArchive and -TargetIsArchive. It is not modeled as a primary-mailbox restore that merely substitutes archive GUIDs.

5. A hold changes the lifecycle to an inactive mailbox and may extend preservation. It is a compliance input, not an error condition to bypass.

1. Context and objectives

The initiating support discussion proposed retiring an old account, allowing its Exchange Online mailbox to become recoverable, assigning the former email address and LegacyExchangeDN to a new mailbox, and restoring primary and archive content. That intent is valid for a narrow scenario: two different mailboxes in the same Microsoft 365 tenant where the business wants the new mailbox to receive the old address and historical content.

Objectives

1. Preserve historical messages, calendar items, contacts, and folder content from the old mailbox by copying them into the new mailbox.

2. Redirect new mail sent to the approved old SMTP addresses to the new mailbox with the shortest practical routing interruption.

3. Preserve reply compatibility for messages and cached recipients that reference the old LegacyExchangeDN.

4. Maintain legal, retention, security, and identity-governance controls throughout the change.

5. Provide deterministic checkpoints, rollback choices, and evidence suitable for a change record.

2. Scope, assumptions, and non-goals

Key assumptions to confirm

1. The old identity is approved for retirement; otherwise use a coexistence or export/import pattern instead of deleting it.

2. The target mailbox is not the same mailbox reattached to a new sign-in. If the goal is identity recovery, restore the deleted user/mailbox from the same system where it was deleted.

3. The target mailbox can absorb the source primary and archive data without breaching mailbox, recoverable-items, or archive limits.

4. The source is not an inactive mailbox with an auto-expanding archive; Microsoft states that this scenario cannot be recovered or restored using the normal inactive-mailbox workflow.

5. Business owners accept either a folder merge or an isolated TargetRootFolder. This paper recommends an isolated root for controllability unless seamless folder merging is an explicit requirement.

3. Target architecture

The design separates three concerns: identity and address authority, the mailbox data plane, and governance evidence. This separation prevents a directory synchronization decision from being mistaken for a mailbox-copy operation.

Architecture components

4. Decision logic and supported pathways

Supported source states

Soft-deleted source. Exchange Online retains a deleted user mailbox for a limited recovery period, normally 30 days. The change team must treat the observed deletion timestamp—not a planned date—as the operational clock and complete the restore with contingency time remaining.

Inactive source. A mailbox placed on an applicable hold before deletion can remain as an inactive mailbox. Restoring copies content to the target while preserving the inactive source. Compliance ownership and target retention requirements remain in force.

Hard-deleted or unresolvable source. The design stops. New-MailboxRestoreRequest cannot reconstruct a permanently purged source. Escalate to backup, eDiscovery, or Microsoft Support options only if they are independently available and authorized.

5. Governance and safety controls

Required approvals

1. Change approval for source retirement, mail-address cutover, and the expected user-impact window.

2. Business-owner confirmation that the target mailbox is the correct legal and operational recipient of the old content.

3. Records-management or legal approval whenever Litigation Hold, eDiscovery hold, Microsoft 365 retention, delay hold, or another preservation control is present.

4. Identity-owner confirmation of the correct source-of-authority path and any downstream HR, application, SSO, or service-account dependencies.

5. Security confirmation that adding old addresses and historical content to the target does not expand access beyond policy.

Go / no-go gates

6. End-to-end migration runbook

Phase 0 - Plan and freeze

1. Open the change record with scope, old/new identities, maintenance window, owners, validation plan, communications, and rollback decision points.

2. Freeze address, license, hold, retention, delegate, and archive changes for both mailboxes until acceptance.

3. Confirm whether the old mailbox has an auto-expanding archive, whether the target archive is enabled, and whether any application sends as the old identity.

Phase 1 - Capture source and target evidence

1. Capture old ExchangeGuid, ArchiveGuid, LegacyExchangeDN, primary SMTP address, proxy addresses, recipient type, archive status, hold indicators, mailbox sizes, item counts, and relevant permissions.

2. Capture the target equivalents and confirm it is healthy, licensed, accessible, and has enough capacity.

3. Export the results to the secured change record. Do not rely on a notepad-only copy or SMTP address as the source identifier.

Phase 2 - Prepare address ownership

1. Decide whether the former primary SMTP address will become a secondary alias on the target or the target's new primary/reply address. Lowercase smtp denotes a proxy alias; uppercase SMTP denotes the primary address in proxyAddresses representations.

2. If the old address must be released before source deletion, first assign the old object a unique parking primary address, then remove the former SMTP proxy from the authoritative directory.

3. In hybrid, use supported on-premises Exchange recipient-management commands and allow synchronization to complete. Do not make a cloud-only change that Entra Connect will overwrite.

Phase 3 - Retire the old identity through the approved authority

1. Cloud-only: use the approved Microsoft 365 / Entra deletion workflow, or the explicitly approved Exchange Online removal path. Do not perform both.

2. Hybrid: retire the on-premises object or remote mailbox using the organization's supported Exchange/identity process, then synchronize. Do not follow an on-premises deletion with an unreviewed cloud Remove-Mailbox command.

3. If the old account must remain, stop and redesign. Disable-RemoteMailbox is not a drop-in substitute and has licensing and archive sequencing requirements.

Phase 4 - Verify the source state

1. Query Exchange Online using the recorded ExchangeGuid. Confirm exactly one source appears as soft-deleted or inactive and that its LegacyExchangeDN and expected metadata match.

2. Record the observed deletion/inactive timestamp and calculate the working deadline. Escalate immediately if the source cannot be found.

3. Do not proceed based only on Get-MailboxStatistics output or a reused SMTP address; the mailbox object and state must be explicit.

Phase 5 - Activate routing compatibility on the target

1. Verify the old SMTP address is no longer assigned to any active recipient, group, contact, mail-enabled public folder, or conflicting directory object.

2. Add the approved old SMTP aliases to the target through the correct source of authority.

3. Add X500:<old LegacyExchangeDN> to the target. Retain it after migration unless a documented reason requires removal; it prevents IMCEAEX/non-delivery failures for old cached recipients and replies.

4. Allow synchronization and Exchange propagation to complete; then test inbound mail to the old address before starting the content restore.

Phase 6 - Restore primary mailbox content

1. Create a uniquely named New-MailboxRestoreRequest using the source ExchangeGuid (or inactive-mailbox distinguished name) and the active target identity/GUID.

2. Use TargetRootFolder for an isolated, auditable copy unless the business explicitly chooses a folder merge.

3. Monitor the request through completion, preserving the detailed report and any skipped-item or failure information.

Phase 7 - Restore archive content if required

1. Confirm the target archive is active and sized. Run a separate restore request with -SourceIsArchive and -TargetIsArchive.

2. Use a TargetRootFolder for archive restores, particularly when mapping primary content into an archive, so restored content remains visible and identifiable.

3. Stop and redesign if the documented inactive auto-expanding archive limitation applies.

Phase 8 - Validate, accept, and close

1. Complete technical content, routing, X500, archive, permission, and client-access tests; compare source baselines with target deltas.

2. Obtain business and compliance acceptance, export request reports, and attach evidence to the change record.

3. Remove completed restore-request objects only after evidence has been retained. Removing a request record does not undo copied content.

4. End the freeze and transfer any outstanding non-mailbox work to named owners.

7. PowerShell reference implementation

7.1 Connect and declare change-scoped variables

Connect-ExchangeOnline



$OldId = "[email protected]"

$NewId = "[email protected]"

$ChangeId = "CHG000000"

$OldPrimary = "[email protected]"

$PrimaryRequest = "OldToNew-Primary-$ChangeId"

$ArchiveRequest = "OldToNew-Archive-$ChangeId"

7.2 Capture immutable mailbox identifiers and baselines

$old = Get-Mailbox -Identity $OldId -ErrorAction Stop

$new = Get-Mailbox -Identity $NewId -ErrorAction Stop



$old | Format-List DisplayName,PrimarySmtpAddress,ExchangeGuid,ArchiveGuid,

LegacyExchangeDN,ArchiveStatus,RecipientTypeDetails,LitigationHoldEnabled,

InPlaceHolds,RetentionHoldEnabled,DelayHoldApplied,DelayReleaseHoldApplied

$old.EmailAddresses | Sort-Object



Get-MailboxStatistics -Identity $OldId |

Format-List ItemCount,TotalItemSize,TotalDeletedItemSize,LastLogonTime



if ($old.ArchiveStatus -eq "Active") {

Get-MailboxStatistics -Identity $OldId -Archive |

Format-List ItemCount,TotalItemSize,TotalDeletedItemSize

}



$new | Format-List DisplayName,PrimarySmtpAddress,ExchangeGuid,ArchiveGuid,

LegacyExchangeDN,ArchiveStatus,RecipientTypeDetails

Hybrid note. Capture the corresponding on-premises remote-mailbox object as well. Use Set-RemoteMailbox (or the organization's supported Exchange recipient-management tooling) for synchronized email-address changes; use Set-Mailbox only for cloud-managed recipients.

7.3 Locate and positively identify the recoverable source

$OldExchangeGuid = $old.ExchangeGuid # Persist this value before deletion.



$source = Get-Mailbox -SoftDeletedMailbox -Identity $OldExchangeGuid `

-ErrorAction SilentlyContinue



if (-not $source) {

$source = Get-Mailbox -InactiveMailboxOnly -Identity $OldExchangeGuid `

-ErrorAction Stop

}



$source | Format-List Name,DistinguishedName,ExchangeGuid,ArchiveGuid,

LegacyExchangeDN,PrimarySmtpAddress,ArchiveStatus,IsInactiveMailbox

7.4 Add old routing identities to a cloud-managed target

$OldLegacyDn = $source.LegacyExchangeDN



# Use lowercase smtp when the old address should remain a secondary alias.

Set-Mailbox -Identity $NewId -EmailAddresses @{

Add = "smtp:$OldPrimary", "X500:$OldLegacyDn"

}



# If the former address must become the target's default reply address:

# Set-Mailbox -Identity $NewId -PrimarySmtpAddress $OldPrimary

For a synchronized target, execute the equivalent address changes with Set-RemoteMailbox on-premises, synchronize, and verify the result in Exchange Online. An SMTP proxy can be assigned to only one recipient at a time.

7.5 Submit the primary restore (recommended isolated-root pattern)

$TargetGuid = (Get-Mailbox -Identity $NewId -ErrorAction Stop).ExchangeGuid

$TargetRoot = "Former Mailbox - $OldId"



New-MailboxRestoreRequest -Name $PrimaryRequest `

-SourceMailbox $source.ExchangeGuid `

-TargetMailbox $TargetGuid `

-TargetRootFolder $TargetRoot

For an inactive mailbox, Microsoft also documents using the source DistinguishedName. Because the X500 proxy is added to the target, the design does not rely on -AllowLegacyDNMismatch. Omit TargetRootFolder only when a native-folder merge is the approved behavior.

7.6 Submit a separate archive restore

if ($source.ArchiveStatus -eq "Active") {

New-MailboxRestoreRequest -Name $ArchiveRequest `

-SourceMailbox $source.ExchangeGuid -SourceIsArchive `

-TargetMailbox $TargetGuid -TargetIsArchive `

-TargetRootFolder "Former Mailbox Archive - $OldId"

}

7.7 Monitor and preserve the detailed request report

Get-MailboxRestoreRequest -Name $PrimaryRequest |

Get-MailboxRestoreRequestStatistics -IncludeReport |

Format-List Status,StatusDetail,PercentComplete,ItemsTransferred,

BytesTransferred,FailureType,Message



Get-MailboxRestoreRequest -Name $ArchiveRequest |

Get-MailboxRestoreRequestStatistics -IncludeReport |

Format-List Status,StatusDetail,PercentComplete,ItemsTransferred,

BytesTransferred,FailureType,Message

8. Validation and acceptance

Technical validation checklist

1. Request status is Completed or otherwise explicitly accepted after review; PercentComplete is 100 and the detailed report has been retained.

2. ItemsTransferred and BytesTransferred are plausible against the recorded source baseline; any skip, warning, or failure is classified and accepted.

3. The restored root/folder hierarchy is visible in Outlook on the web and at least one supported Outlook client.

4. Representative email, calendar, contact, task, attachment, and custom-folder samples open successfully across early, middle, and recent date ranges.

5. If archive was included, the target archive is accessible and restored content is visible under the planned root.

6. Search indexing delay is recorded separately from restore completeness; user acceptance should not treat immediate search behavior as the only evidence.

Mail-flow and compatibility checklist

1. Inbound mail to the target's original primary address succeeds.

2. Inbound mail to each approved old SMTP alias succeeds.

3. Outbound messages use the agreed primary/reply address.

4. Replying to a historical message and selecting an old cached recipient does not generate an IMCEAEX NDR; the X500 proxy remains present.

5. Autodiscover, Outlook on the web, mobile, and shared/delegated access work as separately designed.

6. Connectors, transport rules, applications, scanners, CRM systems, and journaling dependencies referencing the old address were tested or reassigned.

Acceptance evidence

9. Rollback and recovery

Rollback is stage-dependent. A mailbox restore is an asynchronous copy, not a transaction. If content was merged into native folders, separating it later may be difficult; this is the strongest reason to prefer TargetRootFolder for the initial restore.

10. Risks, operating model, and recommendations

Principal risks and mitigations

RACI

Architect recommendations

1. Pilot with non-critical mailboxes that represent both primary-only and primary-plus-archive cases. Capture real restore duration, propagation time, and validation effort.

2. Standardize a pre-change evidence export and a GUID-based mapping sheet; never use display name or SMTP alone as the migration key.

3. Default to an isolated TargetRootFolder for the first production wave. Move to native-folder merge only after business testing establishes that collision behavior is acceptable.

4. Keep X500 aliases after migration. Treat them as compatibility data, not temporary clutter.

5. Automate read-only discovery and validation first. Keep identity deletion and purge decisions manual, peer-reviewed, and change-controlled.

6. Review Microsoft documentation and tenant behavior again before production execution; Exchange Online service behavior and cmdlet support can change.

Appendix A - Interpretation of the original command sequence

Appendix B - Microsoft references

The design was validated against the following Microsoft Learn documentation on 3 September 2026. Tenant behavior, licensing, and cmdlet support must be rechecked at implementation time.

1. Delete or restore user mailboxes in Exchange Online — Soft-deleted lifecycle, 30-day recovery behavior, hybrid restore outline, and deletion cautions.

2. Restore an inactive mailbox — Inactive-source identity, X500 prerequisite, primary/archive restore syntax, TargetRootFolder, and auto-expanding archive limitation.

3. New-MailboxRestoreRequest — Cmdlet syntax, source/target semantics, archive switches, and legacy-DN behavior.

4. Remove-RemoteMailbox — Hybrid on-premises command scope, directory synchronization dependency, and remote mailbox lifecycle.

5. Disable-RemoteMailbox — Keep-user scenario, license prerequisite, archive sequencing, and synchronized removal behavior.

6. Proxy address conflict when adding an email address in Exchange Online — One-recipient address uniqueness and conflict-discovery guidance.

7. Get-MailboxRestoreRequestStatistics — Detailed restore-request monitoring and report retrieval.

Document status