Phase 4: Execute
Prove the design works with a pilot, then copy data in waves while preparing users. By the end, the target holds validated data and people know what will change for them.
What this phase achieves
- Prove the runbook and tools with a pilot before the main migration.
- Get users and change approvers to sign off that the target works.
- Copy data in waves and keep it in sync until cutover.
- Validate that what arrived matches what left.
- Prepare staff so day one is not a surprise.
What to do, in order
- 1
Run the pilot
Migrate a small group, usually IT staff and willing early adopters, using the runbook exactly as written. Follow the Pilot test plan. For a mailbox move, check mail flow, calendars, delegates and mobile devices. For a file move, check permissions, sync clients and long paths. For a website, test on a staging URL or with a hosts file override. For a VM, run a test failover in an isolated network. Fix the runbook wherever reality differed.
- 2
Run user acceptance testing
Ask business users to work through the UAT test scripts and sign-off: open a shared mailbox, edit a file in a migrated library, run a month-end report against the migrated server, place a test order on the new shop. Record pass, fail and evidence, and fix failures before signing off.
- 3
Raise and approve changes
Submit a Change request (CAB) for each production change: batch start, DNS change, firewall rule, server shutdown. Include impact, timing, test evidence and the backout plan. Approval protects you and makes sure the help desk and other teams know what is coming.
- 4
Communicate and train
Send the emails in the User communication pack on the dates in the communication plan: announcement, what to expect, actions before the move, the evening before and day one. Publish the Quick-start guide for staff showing what changes, such as new sign-in, where files now live or reconfiguring a phone. Deliver the Training plan to the people who need more than a guide, such as power users and the service desk.
- 5
Start the bulk copy
Start the initial copy for each wave well ahead of its cutover date, then run incremental syncs so the final pass is small. Examples: create migration batches in Exchange Online (see create a migration batch), run the SharePoint Migration Tool or a third-party tool against file shares, replicate VMs with Azure Migrate or AWS Application Migration Service, copy a website and its database to the new host. Watch for throttling and errors daily.
- 6
Validate the data
Compare source and target in the Data validation report: mailbox item counts and sizes, file counts and total size per library, database row counts, page counts on the new site. Investigate every difference and record why it is acceptable or how it was fixed. Microsoft recommends checksums, row counts and file counts as validation checks for workload migrations.
- 7
Prepare website search signals
For a website move, work through the pre-launch part of the SEO migration checklist: crawl the old site, record rankings and top pages, build and test the redirects from the design phase, prepare the new XML sitemap and confirm canonicals and analytics on staging.
- 8
Report progress daily
Send a short Daily status report during active migration: what moved, what failed, open issues and what happens next. It keeps sponsors informed without extra meetings and builds the evidence for the go / no-go decision.
- 9
Repeat for each wave
After each wave, review what went wrong, update the runbook and communication pack, and confirm the next wave is still ready. Do not start a new wave while the previous one still has unresolved critical issues.
What you produce
| Deliverable | Free template |
|---|---|
| Pilot scope, tests and sign-off | Pilot test planDOCX |
| User acceptance results and sign-off | UAT test scripts and sign-offXLSX |
| Approved change requests | Change request (CAB)DOCX |
| Daily progress and issue report | Daily status reportDOCX |
| Staff emails from announcement to day one | User communication packDOCX |
| Day-one guide for staff | Quick-start guide for staffDOCX |
| Training schedule and attendance | Training planXLSX |
| Source versus target comparison | Data validation reportXLSX |
| Website search and redirect checks | SEO migration checklistXLSX |
Before you move to Cut over
Tick these off with the project sponsor. If any are not true, stay in this phase.
Roles in this phase
| Role | Responsibility |
|---|---|
| Migration engineers | Run batches, copies and replication, monitor errors and update the runbook. |
| Test lead and UAT testers | Run the pilot and acceptance tests and record evidence. |
| Change advisory board | Reviews and approves production changes. |
| Communications lead | Sends the user communication pack on schedule. |
| Trainers and champions | Deliver training and help colleagues on day one. |
| Project manager | Publishes the daily status report and manages issues and risks. |
| SEO lead or web agency | Owns redirects, sitemaps and search checks for website moves. |
Common mistakes and how to avoid them
Treating the pilot as a formalityPick pilot users who will actually test, give them scripts, and be willing to delay if it fails.
Starting the bulk copy too lateLarge mailboxes, file shares and VM disks take time to copy. Start early and use incremental syncs so cutover is a small final pass.
Trusting the tool report aloneCompare counts and sizes yourself and spot-check content, permissions and metadata with real users.
Communications that arrive with the changeSend notices in advance on the agreed dates, and tell people what they need to do, not just what IT is doing.
Forgetting the service deskBrief and train the help desk before the first wave. They take the calls.
Changing the design mid-waveLog requested changes and apply them between waves through the decision log, not during an active migration.
Questions
How big should the pilot be?
Large enough to cover each kind of user and data you will migrate, such as a shared mailbox, a delegate, a mobile user and a large file library, but small enough to roll back easily.
What should I validate after copying data?
Counts and sizes at minimum: mailbox items, file counts, database rows or page counts. Then spot-check permissions, metadata and a sample of real content with the owners.
Can users keep working during the bulk copy?
Usually yes. Most mail, file and VM replication tools copy in the background and then sync changes, so users keep working in the source until cutover.
Do I need change board approval for a small migration?
If your organisation has a change process, use it. If not, at least write down the change, its timing and its backout steps, and tell the people affected.