Free acceptance template ยท project handover
Don't sign off a migration because a progress bar reached 100%.
The right test is whether people can work with the right identities, files, mail flow and permissions. This editable checklist separates a technical transfer from business acceptance, with a named owner and evidence for each test.
Download editable CSV templateAcceptance checks by workload
Choose representatives from different roles and at least one external collaborator where applicable. The following are example test cases, not claims that any customer's system has been tested.
| Workload | Test | Record as acceptance evidence |
|---|---|---|
| Identity | Login to the target using a representative standard user, administrator and external guest | User signs in to the correct identity with expected policies; record exceptions |
| Inbound email | Send from an external sender to primary address and aliases | Messages arrive at the intended target, with trace available |
| Outbound authentication | Send from mailbox and business application that uses the domain | Receiving domain accepts authorised mail; check SPF, DKIM and DMARC results |
| Mailbox data | Compare source and destination sample messages, attachments and key folders | Expected items present, exceptions catalogued, inaccessible content explained |
| Shared mailboxes and delegation | Open a delegated mailbox and send as authorised role | Correct access; no unnecessary global-admin grant |
| Calendar and resources | Open recurring meeting and room/resource booking for test users | Meetings and bookings behave as expected; broken links documented |
| Personal files | Open representative OneDrive files and check link access | Files available to intended user with correct permissions |
| Team-owned files | Open migrated SharePoint library from colleague and guest accounts | Team ownership, external sharing and document formats explicitly accepted |
| Teams collaboration | Review channel files, membership and representative meetings | Known migration limitations and meeting URL follow-up recorded |
| Mobile and desktops | Log in from an actual enrolled device and Outlook profile | Access works or reconfiguration tasks allocated |
| Application integrations | Test third-party email sender, SSO connector and automation triggers | Named app owner signs off; exceptions have rollback or repair owner |
| Support and rollback | Test escalation channel, go/no-go decision and user instructions | Sponsor signs off acceptance with unresolved exceptions separately |
For each row in the CSV, add the responsible user, date, status (not run/pass/fail/accepted exception), evidence reference and the decision owner. Do not put personally identifiable records into shared reports without suitable handling.
What happens when one check fails?
Record the exception
Capture an identifier, affected business process, severity and owner; avoid storing passwords or confidential message content in the general test tracker.
Decide containment
Choose a repair, documented workaround, postponement or recovery action based on the scope and reversibility of the affected workload. A rollback is not always a simple inverse migration.
Obtain business acceptance
The authorised business owner decides whether an exception is tolerable; the technical team supplies evidence rather than signing on their behalf.
Before you schedule the next cutover
For Exchange cross-tenant moves, validate licensed target MailUsers, GUID mappings, hold status and organisation relationships with the prerequisite matrix. For Google Drive to Microsoft 365, file conversions, source ownership and sharing links need their own tests.
Useful vendor reading: Microsoft cross-tenant mailbox migration and Microsoft's migration file limitations.
Planning template, not an executed acceptance report or a guarantee of service. Editorial review required before publication.
Discuss a migration that needs scoping