Client Evidence Pack After a Tenant Migration

What proof should I give a client after finishing their tenant migration?

A complete evidence pack includes an item-count reconciliation against the pre-migration inventory, a Teams chat-continuity spot-check, confirmation that retention labels and license assignments landed correctly, and the run log showing what ran and how any conflicts were resolved. Package these against the verification checks already built into a proper migration checklist rather than assembling them from memory after the fact.

"The migration is complete" is not evidence — it is a status update. Three weeks after a client tenant migration wraps, the question that actually lands in your inbox is narrower and harder to wave away: "can you show me that my Teams history is really there?" or "why does this one shared mailbox look different?" If the answer lives only in your memory of a project that closed weeks ago, you are reconstructing evidence under pressure instead of handing over something you already built. The fix costs almost nothing extra, because the verification pass a proper migration project already runs is most of the raw material — the only missing step is packaging it as something the client can read on their own. What a client actually asks for after handover Clients rarely ask about your migration tooling or your Graph throttling estimate — they ask about outcomes they can check themselves. The five questions below are the ones that generate the most post-handover support tickets on a client tenant move, and every one of them has a specific, packageable answer if you built it during the migration rather than after the fact. None of them require a technical explanation of how the migration worked — they require a document the client can read without you in the room. Did everything that was in our old tenant actually land in the new one? Can we trust that nothing was silently skipped or silently duplicated? What happened to our Teams chat history specifically? Do our retention labels and license assignments still hold after the move? What do we do if something looks wrong three weeks from now? Step 1 — Start from the checklist verification pass, not from scratch This pack picks up exactly where the MSP pre-flight checklist (/blog/msp-tenant-to-tenant-migration-checklist/) leaves off. That checklist ends its Step 5 with a verification pass — item counts, a Teams spot-check, retention-label confirmation, and a run log — precisely because that pass is the raw material this evidence pack packages for the client. If that verification step was skipped on a given migration, run it now before assembling anything; there is no shortcut that produces trustworthy evidence after the fact. Step 2 — Package the item-count reconciliation Put source and destination counts side by side, per workload, rather than a single pass/fail line. A client who can see "4,812 mailbox items before, 4,812 after" trusts the migration in a way that "migration successful" never earns on its own — and a mismatch, if there is one, is immediately visible and explainable instead of discovered six weeks later. Reconciliation is also the fastest way to catch a real problem early: a workload that shows a large gap between source and destination counts is worth investigating before you package the pack, not after the client spots it themselves. Mailbox item count and total size, source versus destination OneDrive file count and total GB per user, source versus destination SharePoint document library item counts, source versus destination Step 3 — Attach the Teams and chat-continuity evidence A spot-check of message-history continuity across a sample of channels — including any private channels flagged during pre-flight — answers the "is our chat history really there" question in principle. Exporting the underlying chat history as HTML to each user's OneDrive in the target tenant answers it in practice: it produces a file the client can open and read themselves, which is a stronger deliverable than a verbal assurance that the check was performed. Step 4 — Attach the license and configuration snapshot A complete inventory of subscriptions and per-user license assignments, captured at the destination, proves the licenses a client paid for actually followed their users into the new tenant. This is the same artefact that is useful earlier in the project for migration-planning documentation — capturing it again at handover turns a planning input into a closing proof point at no extra cost. It is also the fastest way to answer a billing question a client raises weeks later: whether a specific user still carries the license tier they expect in the new tenant. Step 5 — Assemble the run log and hand the pack over The run log is the spine the rest of the pack hangs off: what ran, when, and how any conflicts were resolved, since items already present at the destination are detected via content hash and skipped, and conflict-merge rules are configurable but never applied silently — the client should be able to see exactly which rule fired on any collision, not just that "some duplicates were handled." One real example, from a completed migration: 153,584 files, 178 GB total, finished in 36 hours, zero errors, April 2026 — that is the level of detail a run log should carry, not a promise that every tenant will move at the same pace. Hand the four parts over together — reconciliation, chat evidence, license snapshot, run log — as one pack, not four separate emails sent whenever each check finished. What an evidence pack cannot prove An evidence pack documents a Microsoft 365 → Microsoft 365 migration; it says nothing about a cross-platform move involving Google Workspace, Slack, or Box, since those sit outside this migration path entirely. A clean reconciliation on the workloads you checked is not a blanket guarantee on everything else — private Teams-channel chat, library-wide retention-label propagation, and per-user OneDrive sharing-link rewrites are each documented elsewhere as carrying their own caveats, worth stating up front rather than discovering under a support ticket. And because GTools.pro has no multi-tenant dashboard aggregating findings across client tenants — each tenant is its own session, its own vault, its own OAuth consent, and its own export envelope — this pack is assembled and handed over per client, one at a time, not generated automatically from a shared console.

Frequently asked questions

Related topics

• migration evidence pack
• client migration proof
• post-migration verification report
• tenant migration sign-off
• msp client handover checklist