Phase 6: Close
Stabilise the new environment, hand it to the people who will run it, switch the old system off safely and record what you learned. A project is not finished until the old system is gone and someone else owns the new one.
What this phase achieves
- Resolve post-go-live issues and bring support back to normal levels.
- Hand the new environment to operations with runbooks, monitoring and a support model.
- Decommission the old system without losing data or breaking anything still using it.
- Capture lessons learned and confirm whether the expected benefits were delivered.
- Get formal acceptance and close the project.
What to do, in order
- 1
Run hypercare and log every issue
Log every post-go-live issue in the Hypercare issue log with priority, owner and status, even ones fixed on the spot. Patterns tell you what to fix centrally: several users with Outlook profile problems point to a script, not a desk visit (see reset an Outlook profile). Agree with the sponsor the criteria for ending hypercare, such as no open high-priority issues and ticket volume back to normal.
- 2
Prepare operations to take over
Work through the Service transition checklist with the team that will run the new environment: monitoring and alerts configured, backup tested, admin access and break-glass accounts documented, licensing and renewal owners named, vendor support contracts in place. For Microsoft 365, check the Essential Eight controls are still applied after the move.
- 3
Hand over formally
Deliver the Handover to operations pack: as-built documentation, operational runbooks, known issues and workarounds, contacts and escalation paths. Get the operations lead to accept it in writing. Until they do, the project team still owns support.
- 4
Confirm nothing still uses the old system
Before switching anything off, check for remaining use. Examples: message trace or logs on the old mail server for mail still arriving or relaying from printers and apps; file server access logs for users or scripts still reading old shares; web server logs on the old host for traffic from stale DNS caches or hard-coded IPs; network connections to a source VM from other servers. Track down and move every remaining dependency.
- 5
Decommission safely
Follow the Decommission checklist in order: take a final backup or archive and confirm you can restore it, keep data the retention mapping says must be kept, set the source read-only, then shut down, wait an agreed period with the system off but recoverable, and only then delete. Remove stale DNS records, service accounts, firewall rules and licences, and cancel hosting or support contracts. For an on-premises Exchange server, follow Microsoft guidance rather than simply switching it off; see Exchange to Exchange Online. For VMs, remove replication jobs and source VMs only after the waiting period; see VMware to Azure or VMware to AWS.
- 6
Run the post-implementation review
Hold a review with the project team, operations and business owners. Use the Post-implementation review to compare the outcome with the charter: scope delivered, schedule, budget, quality and the benefits in the business case. Some benefits, such as reduced support effort, can only be measured some time after go-live, so schedule a follow-up check.
- 7
Record lessons learned
Capture what worked, what did not and what to change in the Lessons learned register, with a concrete action and owner for each. Feed actions into the templates and runbooks for your next migration, so the next mailbox, file or website move starts from a better baseline.
- 8
Close the project
Complete the Project closure report: final scope, budget against the tracker, open items transferred to operations, and sign-off from the sponsor. Archive the project documents, close the RAID log and release the project team.
What you produce
| Deliverable | Free template |
|---|---|
| Post-go-live issues with owners and status | Hypercare issue logXLSX |
| Safe shutdown and removal of the old system | Decommission checklistDOCX |
| Outcome and benefits review | Post-implementation reviewDOCX |
| Lessons learned with actions | Lessons learned registerXLSX |
| Operational readiness confirmed | Service transition checklistDOCX |
| Handover pack accepted by operations | Handover to operationsDOCX |
| Final report and sponsor sign-off | Project closure reportDOCX |
Before you move to business as usual
Tick these off with the project sponsor. If any are not true, stay in this phase.
Roles in this phase
| Role | Responsibility |
|---|---|
| Project sponsor | Agrees the hypercare exit criteria and signs off project closure. |
| Project manager | Runs the review, lessons learned and closure report. |
| Service desk lead | Manages the hypercare issue log and returns support to normal. |
| Operations or managed service lead | Accepts the handover and takes ownership of the new environment. |
| Migration engineers | Fix remaining issues, confirm the old system is unused and perform decommissioning. |
| Security and compliance lead | Confirms archives meet retention needs and that old data is disposed of properly. |
| Finance or procurement | Cancels old licences and contracts and confirms final costs. |
Common mistakes and how to avoid them
Switching off the source the day after cutoverConfirm nothing still uses it, keep it read-only for an agreed period, and take a restorable final archive before deleting.
Forgetting to cancel old servicesList every licence, hosting plan, domain service and support contract in the decommission checklist, with renewal dates.
Handover without acceptanceGet operations to review and accept the handover pack in writing, or the project team keeps getting the calls.
Leaving stale DNS and accounts behindRemove old records, service accounts and firewall rules. Stale entries cause confusing faults and security gaps later.
Lessons learned that nobody readsTurn each lesson into an action with an owner, and update your templates and runbooks.
Never measuring the benefitsSchedule a follow-up check against the business case, even if it is short.
Questions
How long should hypercare last?
Until the agreed exit criteria are met, such as no open high-priority issues and support volume back to normal. Set the criteria with the sponsor before go-live rather than picking a date.
When can I delete the old system?
After you have confirmed nothing still uses it, taken and tested a final archive, met any retention requirements and passed an agreed waiting period with it switched off but recoverable.
What goes in a handover to operations?
As-built documentation, operational runbooks, monitoring and backup details, admin and break-glass access, known issues, vendor contacts and escalation paths.
Is a post-implementation review worth it for a small project?
Yes, even a short one. Writing down what went wrong and what to change makes the next migration faster and safer.