Phase 2: Plan
Turn the assessment into an approved project: agreed scope, a schedule people can follow, named owners, a budget, a risk log and a plan for keeping everyone informed.
What this phase achieves
- Get formal approval for scope, budget and success criteria.
- Build a realistic schedule with dependencies, milestones and owners.
- Make it clear who decides, who does the work and who must be told.
- Start tracking risks, assumptions, issues and decisions from day one.
- Plan how and when each audience will hear about the change.
What to do, in order
- 1
Write the business case
Use the assessment findings and the TCO comparison to state why the move is worth doing, the options considered (including doing nothing), the costs, the benefits and the main risks. Keep it short enough for the steering committee to read. The Business case and ROI template has the structure.
- 2
Agree the project charter
One page that fixes scope, objectives, success criteria, constraints and governance. Be specific: "all mailboxes and the S: drive move to Microsoft 365; the finance app stays on premises" is a scope; "move to the cloud" is not. Get the sponsor to sign the Project charter.
- 3
Identify stakeholders and assign responsibilities
List everyone affected or with influence in the Stakeholder register: executives, department heads, the help desk, external IT providers, your web agency, the DNS registrar contact. Then build a RACI matrix so each task has exactly one accountable person. For example, the mail administrator is responsible for MX changes, the IT manager is accountable, the web agency is consulted and staff are informed.
- 4
Build the schedule
Start from the Master migration project plan and remove tasks that do not apply. Work backwards from fixed dates: a licence or hosting contract end, an end of support date, a quiet trading period. Add lead times for things outside your control, such as purchasing licences, getting a third party to release a domain, or change board meetings.
- 5
Set the budget
Record licences, migration tools, contractor time, training and the overlap period when you pay for both old and new systems in the Budget and cost tracker. Use vendor pricing pages for current figures and include a contingency line agreed with the sponsor.
- 6
Open the risk register and RAID log
Log every risk with likelihood, impact, owner and mitigation in the Risk register. Typical entries: throttling slows the mailbox copy, a large file share exceeds path length limits, DNS access is held by a former agency, a key VM has no tested backup. Track assumptions and dependencies in the RAID log, and record every decision in the Issue and decision log so it is not reopened later.
- 7
Plan communications
In the Communication plan, list each audience, what they need to know, the channel and the date. Staff need to know what changes for them and when; executives need status and decisions; customers may need notice if a website or support mailbox changes. Draft the dates now, even if the content is written in the Execute phase.
- 8
Set up governance and reporting
Agree how often the steering committee meets, what it decides and how status is reported. Use the Steering committee report for a regular summary with RAG status, decisions needed and next steps. Agree the change process early: many organisations need change board approval for DNS, firewall and production changes.
- 9
Confirm resources and access
Book the people and the time: administrators, application owners, testers and any partner. Request the admin roles, service accounts and licences the tools need so they are ready when the design starts.
What you produce
| Deliverable | Free template |
|---|---|
| Schedule with tasks, dependencies and milestones | Master migration project planXLSX |
| Risk register with scores and mitigations | Risk registerXLSX |
| Business case for approval | Business case and ROIDOCX |
| Signed project charter | Project charterDOCX |
| Risks, assumptions, issues and dependencies | RAID logXLSX |
| Issue and decision record | Issue and decision logXLSX |
| Responsibility matrix | RACI matrixXLSX |
| Budget and spend tracking | Budget and cost trackerXLSX |
| Stakeholder list and engagement approach | Stakeholder registerXLSX |
| Communication schedule | Communication planXLSX |
| Regular status report for sponsors | Steering committee reportPPTX |
Before you move to Design
Tick these off with the project sponsor. If any are not true, stay in this phase.
Roles in this phase
| Role | Responsibility |
|---|---|
| Project sponsor | Approves the business case, charter and budget, and chairs or attends the steering committee. |
| Project manager | Builds and maintains the plan, RAID log, budget and reporting. |
| Migration lead or architect | Validates the schedule and technical sequencing, and identifies technical risks. |
| Steering committee | Makes decisions that are above the project manager, such as scope changes and go-live dates. |
| Finance or procurement | Approves the budget and purchases licences and tools. |
| Communications or HR lead | Owns staff messaging and helps time announcements. |
| Service desk lead | Plans support capacity for the migration and hypercare periods. |
Common mistakes and how to avoid them
A scope that says "everything"Name the systems, user groups and data in scope and out of scope in the charter, and route changes through the steering committee.
Forgetting the overlap periodBudget for running old and new systems in parallel until decommission. Ending a contract too early removes your rollback option.
Ignoring lead times you do not controlLicence purchases, domain transfers, change board slots and third-party agencies all take time. Put them in the plan as dependencies.
Several people accountable for one taskUse the RACI to give each task one accountable owner. Shared accountability means nobody follows up.
A risk register that is filled in onceReview risks at every status meeting and close or escalate them. A stale register gives false comfort.
Telling staff too latePut announcement dates in the plan now. People cope with change much better when they hear early and from a familiar source.
Questions
Does a small migration need a full project plan?
Scale it down, but keep the essentials: a scope statement, a schedule with owners, a risk list, a rollback option and a communication plan. Even a small mailbox move goes wrong when nobody owns the DNS change.
What is the difference between the RAID log and the risk register?
The risk register scores and tracks risks in depth. The RAID log is a single place for risks, assumptions, issues and dependencies. Many small projects use only the RAID log.
Who should be on the steering committee?
The sponsor, the project manager, the migration lead and the business owners of the most affected areas. Keep it small enough to make decisions.
When should staff be told about the migration?
As early as the plan is approved, with a short message about what is changing and roughly when. Detailed instructions follow closer to their migration wave.