Workstream 01
Put the estate into a workload map
Split the estate into Exchange mailboxes, calendar and delegates, Entra identities, files in OneDrive or SharePoint, Google Drive material, Teams conversations and channels, applications, devices and third-party senders. Each may demand a different migration mechanism and team. Record an approximate object count and size rather than treating every user as one identical unit.
Include ownership and approvals: who can release the corporate domain, who can approve new external sharing, who is responsible for an executive mailbox on hold, and who decides that data may be decommissioned. These are business controls, even when the technical engineer has administrator permissions.
| Workstream | Discovery evidence | What changes the quote |
|---|---|---|
| Mailbox and archive | Count, source platform, archive sizes and delegation | Licence eligibility, exceptional volume and aftercare |
| Files and shared spaces | Drive/SharePoint sites, file count, links and guests | Conversion, ownership mapping and access remediation |
| Identity and applications | UPNs, verified domains, SSO apps and device estate | Provisioning, domain coordination and support |
| Teams collaboration | Chats, meetings, channels, apps and retention needs | Supported orchestration versus separate rebuild work |
Workstream 02
Identify genuine blockers before reserving a cutover
Check source and target administrator rights, supported licence SKUs, domain ownership, migration-tool constraints, service-account senders, legal or retention holds and the expected coexistence route. In native cross-tenant work, a target MailUser or unprovisioned OneDrive may need to be prepared in a precise order. A discovered hold must be discussed with compliance, not bypassed to make a deadline.
Estimate which blockers can be resolved during preparatory work and which require another department, supplier or legal owner. Set an explicit stop rule: no final cutover booking when critical recipient mapping, domain control or preservation approval remains unresolved.
What to capture before the decision
- Document source/target ownership before requesting any privileged access
- Record licensing and supported migration methods per workload
- Identify third-party senders and external sharing dependencies
- Classify legal holds and preservation requirements
- Separate critical blockers from optional enhancements
Workstream 03
Design a pilot that represents real risk
A token test mailbox rarely captures what can go wrong. Choose a typical user, a mailbox with delegation, someone with a large archive, a department owning shared files and at least one external guest. Record the expected outcome for each user before the transfer. Include a realistic daily working task, such as opening a team document and sending an invoice from an authorised system.
Acceptance means the named owner completes each expected business journey on the destination, not merely that a migration batch reports a green status. Use explicit evidence for mailbox search, device sign-in, delegated reply, external mail flow, permissions and the retained source records.
Workstream 04
Turn the assessment into a comparable proposal
Ask suppliers to price discovery, licensing, migration tooling, data movement, permission remediation, domain and mail-flow cutover, user communications and time-limited aftercare separately. A quotation that simply multiplies employees by a price hides assumptions about file sizes, exceptions and restoration of disrupted workflows.
Require measurable deliverables and a change-control process. A good proposal states what is excluded, who authorises unexpected work, how the customer verifies completion, and which changes cannot be reversed. If the required volumes are still unknown, propose a bounded discovery phase rather than presenting a confident fixed price.
What to capture before the decision
- Written workload scope and exclusions
- Named pilot testers and acceptance checklist
- Risk register with decision-makers and deadlines
- Separate customer licences from professional fees
- Specified aftercare hours and escalation route
The purpose of readiness assessment is to prevent a confident but unsupported implementation promise. You should leave with a useful map even if the project is not immediately ready to proceed.
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.