Phase 1: Assess
Find out exactly what you have, who uses it and what it depends on, then decide whether and how each piece should move. Every later phase is built on what you learn here.
What this phase achieves
- Build a complete, owned inventory of the users, data, applications and servers in scope.
- Map the dependencies that will break if one item moves without another.
- Choose a migration approach for each workload: move as is, change platform, replace, keep or retire.
- Identify licensing, security, compliance and network constraints before they become surprises.
- Give the sponsor an evidence-based readiness verdict and a rough cost comparison to decide on.
What to do, in order
- 1
Agree the scope question
Write down, in one or two sentences, what the business wants to achieve and what is in and out of scope. "Move all mailboxes and the shared drive to Microsoft 365" or "Move the three line-of-business VMs off the ageing host" is enough to start. Without this, discovery never ends.
- 2
Inventory what you have
Export the facts from the systems themselves rather than asking people from memory. Examples:
- Mailbox move: every mailbox, shared mailbox, archive, distribution list and resource, with size and item count.
- File server move: every share, its size, file count, top-level folders, longest paths and owners.
- Website move: every domain, page URL, form, plugin, integration and the email that runs on the same domain.
- VM move: every server with OS version, CPU, memory, disk, IP address and what runs on it.
Record each item in the Mailbox and data inventory or the Application inventory and dependency map.
- 3
Find an owner for everything
Every mailbox, share, site and application needs a named business owner who can answer "who uses this?" and approve its move or retirement. Items with no owner after reasonable effort are strong candidates to archive or retire, but get that decision in writing.
- 4
Map dependencies
Trace what each item talks to. A scanner that emails reports through an on-premises Exchange server, an accounting app that reads a mapped drive letter, a website contact form that sends through a mail relay, a VM that authenticates against a domain controller staying behind. Dependencies decide which items must move together in the same wave.
- 5
Assess identity, licensing and security
Check how users sign in today and how they will sign in after the move (for example Active Directory to Entra ID). List current licences and what the target needs. Record retention policies, litigation holds, data residency rules, MFA and conditional access so the design phase can carry them across. Use the Licensing assessment and Security and compliance assessment.
- 6
Check the network and DNS
Note who controls each domain and its DNS host, current MX, SPF, DKIM and DMARC records, available bandwidth for bulk copies, and any firewall or proxy that will block migration traffic. Losing access to a DNS registrar account is a common and avoidable cause of delay.
- 7
Decide a path for each workload
Use the Workload 7R decision matrix to give every item one of: rehost, replatform, refactor, repurchase, retire, retain or relocate. For example, a file server may be repurchased as SharePoint (see the file server to SharePoint guide), a VM may be rehosted (see VMware to Azure), and an old intranet may simply be retired.
- 8
Evaluate migration tools
For each workload, list the native vendor tool and any third-party tools, then score them against your requirements in the Migration tool evaluation scorecard: what content types they move, delta sync support, reporting, throttling behaviour and support. Run a small test copy with your preferred tool before committing.
- 9
Compare costs and document the current state
Fill in the TCO and cost comparison using the vendor's current pricing pages and your real costs. Draw the Current-state architecture so the design team and change board share one picture of today.
- 10
Score readiness and report
Bring the findings together in the Migration readiness assessment: a score per area (identity, data, apps, network, security, people) and a clear verdict of ready, ready with conditions, or not ready. Present it to the sponsor with the blockers that must be fixed first.
What you produce
| Deliverable | Free template |
|---|---|
| Readiness verdict and scores | Migration readiness assessmentXLSX |
| Application inventory and dependency map | Application inventory and dependency mapXLSX |
| Migration path per workload | Workload 7R decision matrixXLSX |
| Mailbox, file and data inventory | Mailbox and data inventoryXLSX |
| Current and target licence comparison | Licensing assessmentXLSX |
| Retention, hold and compliance findings | Security and compliance assessmentDOCX |
| Diagram and description of today's environment | Current-state architectureDOCX |
| Tool shortlist and recommendation | Migration tool evaluation scorecardXLSX |
| Cost of staying versus moving | TCO and cost comparisonXLSX |
Before you move to Plan
Tick these off with the project sponsor. If any are not true, stay in this phase.
Roles in this phase
| Role | Responsibility |
|---|---|
| Project sponsor | Sets the business goal, accepts the readiness verdict and decides whether to proceed. |
| Migration lead or architect | Runs discovery, owns the inventory and recommends the path and tool for each workload. |
| System administrators | Export inventories and reports from mail, file, web and virtualisation platforms. |
| Application and data owners | Confirm who uses each item, how important it is and whether it can be retired. |
| Security and compliance lead | Identifies retention, hold, privacy and residency requirements. |
| Finance or procurement | Supplies current licence and contract details for the cost comparison. |
Common mistakes and how to avoid them
Inventory from memoryExport from the systems. People forget the shared mailbox the scanner uses and the share accounting maps at logon.
Ignoring hidden dependenciesAsk "what else stops working if this moves?" for every item, and check service accounts, scheduled tasks, mail relays and hard-coded paths.
Moving everything because it is easier than decidingUse the 7R matrix to retire or archive stale data and apps. Less to move means a faster, cheaper project.
Losing track of who controls DNSConfirm registrar and DNS host logins now. Recovering an account owned by a former staff member or agency can take a long time.
Choosing a tool from a feature list aloneRun a test copy with real data and check what did not move before you commit.
Skipping complianceFind litigation holds, retention requirements and residency rules now. Some block or complicate a move and must be designed around.
Questions
How long should a migration assessment take?
It depends on the size and complexity of the estate. A small office with one mail system and one file share can be assessed quickly; a large estate with many applications needs longer. Stop when the gate criteria are met, not at a fixed date.
Do I need a discovery tool?
For mail and files, the admin reports in the source platform are usually enough. For servers and applications, a discovery tool such as Azure Migrate or AWS Application Discovery Service helps find dependencies you would otherwise miss.
What is the 7R model?
A way to give each workload one path: rehost, replatform, refactor, repurchase, retire, retain or relocate. It forces a decision per item instead of moving everything the same way.
What if the assessment says we are not ready?
That is a useful result. List the blockers, assign owners and dates to fix them, and reassess those areas before moving to the Plan phase.