Microsoft 365 retention policy checklist before a tenant migration

What should an MSP confirm before a Microsoft 365 migration drops history?

Confirm four things per tenant before cutover: which retention policies apply, what happens to mailboxes of departed staff, how long Teams chat and channel messages are kept, and who holds the export rights. The tenant's retention settings decide whether years of email and chat survive the move, and they also show whether the customer has the long history that matters for a data licensing conversation.

This checklist is written for the engineer or account manager running the migration plan. It does not ask you to open, copy or describe any message content. You are checking settings and counts, not reading records.

Pre-migration retention checklist

Work through the groups in order. Record answers in the migration ticket, not in a personal notebook.

Mailboxes and archives

• List every retention policy and label that touches Exchange Online, with the scope (all mailboxes, named groups, or specific users).
• Note the oldest item date in a sample of mailboxes, using the admin tools you already use for sizing, without opening messages.
• Check whether online archive mailboxes are enabled and whether older mail has been moved into them.
• Confirm whether any mailbox is under litigation hold or another hold, and who placed it.
• Find mailboxes that are shared, resource or journaling targets; they can hold long, unbroken history.

Inactive mailboxes and departed staff

• Count inactive mailboxes (users deleted while a hold or retention policy preserved the mailbox) and record how many exist.
• Identify mailboxes for departed users that were converted to shared mailboxes instead of deleted.
• Ask who approves removing a preserved mailbox. If nobody can answer, flag it before cutover.

Teams, SharePoint and OneDrive

• Record whether Teams chat and channel message retention is set, and for how long.
• Confirm whether SharePoint sites and OneDrive accounts of former staff were deleted on a schedule.
• Check for a retention policy that deletes after a fixed period; a delete-after rule can explain why a long-lived company has a short history.
• Identify sites that were archived or are read-only but still readable.

Ownership and exit

• Confirm which person at the customer can authorize an export or a change to retention. Document the name and title.
• Confirm that the customer, not the MSP, is the owner of the tenant and its records.
• Decide what is kept after cutover: the old tenant, a full export, or neither.

How to read the results

Which tenants are worth an owner conversation?

Most migrations are routine and should stay that way. A conversation is worth raising only when the customer looks like a company SourceX can work with: US companies with 50+ full-time employees at peak (contractors excluded), several years of documented operations, rights to license, and an authorized sponsor. A tenant with a decade of retained mail, an active Teams history and several connected line-of-business systems fits that profile better than a young tenant that was set up two years ago.

If a tenant fits, treat the owner conversation as a separate step from the migration. Managed service providers can see the settings, but the records belong to the customer, and the customer decides.

What to say to the owner

Keep it short, and keep it separate from the migration status call.

The introduction email builder drafts an owner-approved version. Before any inventory talk, use the mutual NDA checklist so the customer knows who sees what.

What you must never do

• Do not export, forward, upload or describe message content to SourceX or to anyone else. Partners make introductions and give basic fit information only.
• Do not use admin access you hold for migration work to explore records for a referral.
• Do not suggest a payment to the owner. Nothing is binding until the company agrees price and terms and signs.

A tenant that cannot be exported is a red flag; the exportability checklist covers how the customer's IT lead confirms that, system by system. Retired systems matter too, and the archived systems checklist helps find them.

How partner rewards work for an MSP

Partners earn 25% of the eligible platform fees SourceX actually collects from the referred company's licensing deals, capped at $100,000 per referred company. The reward is paid only after the buyer pays and SourceX receives its fee; an introduction, meeting or signed agreement alone does not trigger payment, and no reward is guaranteed. The reward is a share of SourceX's fee and is never deducted from what the company receives. Read the program terms and check your customer contracts for any rule on referral compensation first.

Next step

Run the checklist on your next scheduled migration and note which tenants have long, intact history. If one fits and the owner is open to it, register as a partner and make the introduction, or have the owner apply at sourcex.si/apply with your referral link.