Phase 3: Design
Decide exactly where everything lands, how it gets there and how you will prove it worked. A good design means the Execute phase is following steps, not making decisions.
What this phase achieves
- Define the target environment and record the decisions behind it.
- Map every source user, mailbox, share, site or server to its exact destination.
- Group the work into waves that respect dependencies and business calendars.
- Have security, retention and network settings ready before any data lands.
- Write the technical procedure and the test approach before the first pilot.
What to do, in order
- 1
Design the target state
Document the future environment in the Target-state architecture: tenant or account structure, identity source, regions, naming conventions, and where each kind of data lives. Record why each decision was made. Examples: home drives go to OneDrive and department shares go to SharePoint libraries; the website moves to managed hosting with email staying in Microsoft 365; VMs land in a dedicated subscription with their own virtual network.
- 2
Map identities and licences
In the Identity and licence mapping sheet, list each source account against its target account, username or UPN, mailbox type and licence. Decide what happens to shared mailboxes, leavers, service accounts and aliases. If the domain itself is moving between tenants, plan the order carefully; see move a domain between Microsoft 365 tenants.
- 3
Map data and retention
Map each source location to a target location, for example
\\fs01\financeto the Finance site Documents library, or a Google shared drive to a SharePoint site. Use the Data retention mapping to carry retention policies, holds and labels across, and decide what is archived instead of moved. - 4
Plan the waves
Use the Migration wave plan to group users and workloads. Keep dependent items together (a team and the shared mailbox they use, an app server and its database). Start with a pilot of IT and willing early adopters, avoid month-end for finance and peak periods for sales, and keep executives and their assistants in the same wave so delegated calendars keep working.
- 5
List every DNS and network change
In the Network and DNS worksheet, record every record that will change with its current value, target value and TTL: MX, Autodiscover, SPF, DKIM, DMARC, A and CNAME records for websites, and any firewall rules, VPN routes or IP addresses for servers. Plan to lower DNS TTLs ahead of cutover. The DNS and email cutover guide covers mail records in detail.
- 6
Map URLs for website moves
If URLs change, map every old URL to its new address in the URL redirect map (301s), including product pages, blog posts, images and PDFs that rank or are linked from elsewhere. See change domain without losing SEO and WordPress migration.
- 7
Set the security baseline
Configure and verify the Security baseline checklist in the target before data arrives: MFA, conditional access, admin role separation, data loss prevention, sensitivity labels, backup and logging. For Microsoft 365, the Essential Eight for Microsoft 365 guide is a useful reference. Moving data into an unprotected tenant creates a gap that is hard to close later.
- 8
Write the technical runbook
The Technical migration runbook is the step-by-step procedure for each workload: prerequisites, exact commands or console steps, expected results, and how to check them. Write it so another administrator could follow it. Base each workload on the relevant guide, for example Exchange to Exchange Online, file server to SharePoint or VMware to AWS.
- 9
Define the test strategy
Decide in the Test strategy what will be tested, by whom and what "pass" means. Typical tests: item counts match between source and target mailboxes, file permissions are correct, a migrated VM boots and its application answers, website forms submit and send mail, search and calendar sharing work. Agree the exit criteria for the pilot and for each wave.
- 10
Review the design
Walk the architecture, runbook and test strategy through with the people who will run them and with security. Record decisions in the issue and decision log and get the design signed off before building anything in production.
What you produce
| Deliverable | Free template |
|---|---|
| Target environment and design decisions | Target-state architectureDOCX |
| Source to target identity and licence map | Identity and licence mapping sheetXLSX |
| Wave groupings and dates | Migration wave planXLSX |
| DNS, firewall and network change list | Network and DNS worksheetXLSX |
| Retention and hold mapping | Data retention mappingXLSX |
| Step-by-step technical procedure | Technical migration runbookDOCX |
| Target security configuration verified | Security baseline checklistDOCX |
| Test scope, method and exit criteria | Test strategyDOCX |
| Old to new URL redirect map | URL redirect map (301s)XLSX |
Before you move to Execute
Tick these off with the project sponsor. If any are not true, stay in this phase.
Roles in this phase
| Role | Responsibility |
|---|---|
| Migration lead or architect | Owns the target-state architecture and signs off the design. |
| Identity administrator | Builds the identity and licence mapping and configures sign-in. |
| Messaging, file or infrastructure engineers | Write the runbook for their workload and test it in a lab. |
| Network and DNS administrator | Owns the network and DNS worksheet and firewall changes. |
| Security and compliance lead | Approves the security baseline and retention mapping. |
| Test lead | Writes the test strategy and recruits testers. |
| Web developer or agency | Builds the redirect map and staging site for website moves. |
Common mistakes and how to avoid them
Copying the old structure without thinkingA ten-year-old folder tree with broken permissions does not improve by moving. Use the move to simplify, but agree changes with data owners first.
Splitting people who work togetherKeep teams, their shared mailboxes, delegates and shared calendars in the same wave.
Leaving security until after the data landsConfigure MFA, conditional access and labels first. Retrofitting controls to live data is harder and riskier.
Forgetting non-obvious DNS recordsInclude DKIM, DMARC, Autodiscover, verification TXT records and subdomains used by marketing and third-party services.
A runbook only the author can followHave a second administrator dry-run it in a test environment and fix every step they question.
No definition of successWrite measurable exit criteria in the test strategy, such as matching item counts, so pass and fail are not a matter of opinion.
Questions
How many migration waves should I have?
Enough that each wave is small enough to support and roll back. Small organisations often use a pilot plus one main wave; larger ones use several waves grouped by department or dependency.
Should I restructure data during the migration?
Only where the benefit is clear and the data owner agrees. Restructuring adds testing effort, so keep it to changes users will notice and value.
What goes in a technical migration runbook?
Prerequisites, the exact steps or commands for each workload, what you should see after each step, how to verify the result and what to do if a step fails.
Do I need a test environment?
A test tenant, staging site or isolated network is strongly recommended for proving the runbook. If you cannot have one, use a pilot group of IT staff in production with an agreed rollback.