- Templates |
- Software implementation plan
Software implementation plan template
Plan a software rollout from configuration and data migration to testing, training and launch. Adapt the six-month sample to your system, team and deadlines.
- 7 phases
- 36 tasks
- 3 milestones
- 50 dependencies
- About 6 months
- Updated October 11, 2026
A plan for rolling out software you have chosen
This template covers configuring a system, migrating data, connecting other tools, testing, training and launch. It models about six months of work, including extra support after launch, often called hypercare. Assign each task to your team, vendor or implementation partner according to the agreed scope.
If you are building the software itself, use the software development plan. This example is for introducing an existing CRM, finance, HR or ERP system.
What are the seven phases?
The sample overlaps data preparation, configuration and integration work. Training materials are prepared during testing, with team training before the launch decision. The dates below describe this example, not a standard duration for every rollout.
| Phase | Weeks | What happens | Owners |
|---|---|---|---|
| Discovery and design | 1 to 6 | Kickoff with the scope and the target date, the current processes mapped, the requirements and fit-gap list, the vendor's design workshops. Ends on Design signed off. | PM, ops, vendor |
| Configuration | 3 to 13 | Environments, the core modules, roles and single sign-on, a walkthrough by the super users and the changes it produces. | Vendor, IT, super users |
| Data migration | 2 to 16 | The audit, seven weeks of cleansing, the field mapping, then two trial loads, each reconciled against the old system by the finance lead. | Finance lead, ops, IT |
| Integration | 7 to 15 | The spec of what moves between systems, the build by the vendor, and testing with the first trial load's data. | IT, vendor |
| Testing | 11 to 22 | Test scripts written from the process map, the system test, user acceptance testing, the fixes, and the go or no-go decision. | PM, IT, super users, vendor |
| Training and change | 13 to 21 | The announcement, super-user training, the how-to guides, and every team trained on the tested system. | PM, vendor, super users |
| Go-live and hypercare | 23 to 28 | The old system frozen, the weekend switch to the new system (cutover), Monday launch, four weeks of extra support, handover and a 30-day review. | Ops, IT, vendor, PM |
Role names appear at the start of tasks. Replace them with owners, including the super users: people who learn the system early, help test it and support colleagues.
Adapt the plan before kickoff
- Choose the launch window. Check business deadlines, busy periods and support availability, then work back through the required tasks.
- Estimate data work after an audit. Replace the sample's seven-week cleansing period with an estimate based on the records, quality issues and people available.
- Separate the integrations. Give each connection its own specification, build and test tasks.
- Assign the super users. Confirm that they have time for testing and training alongside their usual work.
- Remove work that does not apply. A system with no historic data to move may not need a migration phase. Check the remaining testing dependencies after removing it.
Rehearse the data migration
The sample includes two trial loads. The first tests the field mapping and prepared data in the configured system. The finance lead checks record counts, balances and sample records against the old system.
Corrections feed into the second load, which checks whether the changes worked. Integration tests also use reconciled data. Adjust the number and scope of rehearsals to the migration risk and the checks your team needs.
Agree the conditions for launch
The sample's go or no-go milestone waits for three things: user acceptance testing fixes, a reconciled second trial load and team training. Add your own release conditions, such as security approval, support readiness and an agreed fallback plan.
- Train on a tested workflow. The sample links team training to the system test and completed guides, reducing the need to repeat training after changes.
- Plan the cutover. Cutover is the switch from the old system to the new one. This example freezes changes, loads and checks the final data over a weekend, then launches on Monday. Choose a window that fits your operation and keep weekend work visible.
- Include support after launch. Hypercare means a period of extra support while users begin working in the new system. The sample allows four weeks, followed by handover and a review. Agree support coverage and issue handling with the people responsible.
Turn on Critical path to see which linked tasks control the finish date. With Auto schedule on, extend a data or testing task and review the effect on launch before accepting the new dates.
What changes for an ERP rollout?
An ERP may connect finance, stock, purchasing and sales, so review these parts of the example in more detail:
- Data scope: decide which history, open items and balances must move, and how retained records will remain accessible.
- Launch timing: agree how the switch fits the accounting period and operational calendar.
- Connections: plan and test each required bank, payroll, warehouse or sales integration.
- Support coverage: allow time to support important business cycles, including the first month-end close where relevant.
Use those decisions to estimate the schedule. If the work does not fit the proposed launch, revisit the scope, capacity or date with the team.
Review progress week by week
Use Month zoom for the overall rollout and Week zoom during cutover and early support. Collapse the groups for a summary of the seven phases and three milestones.
The Estimate column separates effort from elapsed time. A task can span several weeks while requiring fewer hours of work. Check both the dates and the hours against each owner's other commitments.
Breeze
Timen
