This free software implementation checklist picks up a new business application once the contract is signed and carries it to the day the tool it replaces is switched off. IT managers, application owners and MSPs use it for SaaS and installed software alike. It covers owners and success measures, single sign-on, provisioning and integrations, data migration, a pilot with real users, training, a go-live decision by a named approver, hypercare and adoption measured against a baseline. Migration and retirement tasks appear only when the rollout needs them.
Choosing software and implementing it are different projects, often run by different people. Selection ends with a signed contract and a set of reviews: security, data protection, supplier checks. Implementation has to turn that into a tool people use every day, and the handover is where conditions get lost. The security review said MFA was required; the tenant went live with local passwords switched on.
ITIL 4 treats change enablement, deployment management and release management as separate practices. A new business application passes through all three, then needs one thing no deployment tool records: people changing how they work.
Covers: requirements, shortlist, trial, security and data protection review, contract.
Owned by: the business sponsor and procurement.
Output: a signed contract and a list of conditions the reviews attached to it.
Covers: owners, configuration, integrations, migration, pilot, training, go-live, hypercare and retirement.
Owned by: a business owner and a technical owner together.
Output: a tool in use, measured against a baseline, with the old one switched off.
Covers: support tickets, access changes, updates, renewals and licence reviews.
Owned by: the service desk and the application owner.
Output: a supported service with a renewal date someone is watching.
Moving the devices you already run to a new version of Windows, macOS or Linux is a different job, built around compatibility testing, deployment rings and a rollback window. It has its own Operating System Upgrade Rollout Checklist.
Seven phases take a new application from contract to adoption. Three answers on the first task decide whether the migration phase, the installed-client task and the retirement phase appear.
The answers on the first task shape the rest of the checklist.
The last task appears only for installed software.
Tasks appear only when data migration is in scope. A tool that starts empty goes straight to the pilot.
The go-live approver named in Phase 1 signs off on the fourth task. The checklist halts there, and nothing moves to cutover until they record a decision.
Tasks appear only when the new application replaces an existing one. Retirement is where many rollouts stall, so it gets its own phase and its own dates.
Phase 1 asks for three to five success measures with a baseline, and Phase 6 checks them at 30 and 90 days. Pick from the list below the ones that match why the tool was bought, and take the baseline before go-live, while the old numbers still exist.
| Measure | Where the data comes from | When to check | What it tells you |
|---|---|---|---|
| Active users as a share of licences | The application’s admin or usage report | Weekly in hypercare, then at 30 and 90 days | Whether people sign in at all; a low figure usually means an access or awareness problem |
| Share of the process running in the new tool | Record counts in the new tool against the old tool or spreadsheet | 30 and 90 days | Whether the old workaround is still alive alongside the new tool |
| Time to complete the core task | Timestamps in the new tool against the Phase 1 baseline | 90 days | Whether the tool delivered what the business case promised |
| Hypercare tickets per 100 users | The service desk category created in Phase 4 | Weekly during hypercare | Whether training and configuration are landing; the line should fall week by week |
| Licences assigned but not used | Last sign-in dates in the admin console | 90 days, and again before renewal | Seats to reclaim or reduce before the renewal date |
| Sign-ins to the old tool after go-live | The old tool’s audit log | Weekly until it is switched off | Exactly who still depends on the old tool, and why |
Licences assigned is not adoption: a seat given to everyone on day one says nothing about who uses it. An organisation-wide average also hides the team that never moved, so break every measure down by team and take the gaps to those teams’ managers. The 90-day figures have a second use: they arrive before most first renewals, in time to set the next licence count from real usage.
The go-live approver is picked in a members field in Phase 1, and the decision task is assigned to them. The checklist halts there until they record approved or not approved, and the activity trail keeps who decided, when and why.
Conditional logic reads the first task and shows the migration phase, the client packaging task and the retirement phase only where they apply. Dynamic due dates count each phase forward from the start, so a pilot that overruns shows up as overdue tasks.
Pilot issues and migration counts go into tables inside their tasks, with reconciliation reports attached. Changes agreed at the hypercare review go into a new template version, so the next rollout starts from the improved one.
Go-live is one change among many that week. The approval mechanics, from risk assessment to the post-implementation review, live in the IT Change Management Checklist. For programmes where the people side is the larger risk, CheckFlow’s change management checklist software shows how readiness checks and training gates work across whole programmes.
During hypercare, the new ticket category is watched every morning through the IT Help Desk Daily Checklist. A year later, the question becomes whether you are paying for seats nobody uses, which the Software License Audit Checklist answers by comparing entitlements with real assignments and usage.
The handover from selection (what was bought and the conditions the reviews attached), named owners and success measures with a baseline, configuration of single sign-on, provisioning, permissions and integrations, data migration with a trial and a sign-off, a pilot, training, and a go-live decision with a rollback point. Many checklists stop at go-live. A useful one carries on through hypercare, adoption at 30 and 90 days, and switching off the tool it replaced.
Two to four weeks is common for a business application, and longer for systems with monthly cycles: the first month-end a finance team runs in a new tool is effectively a second go-live. End hypercare on criteria as well as a date: ticket volume back to normal, no open severe issues, and support handed to the service desk and the application owner.
Choose three to five measures before go-live and record a baseline for each. Active users as a share of licences, the share of the process now running in the new tool, time to complete the core task and support tickets per user are common choices. Check them at 30 and 90 days, broken down by team.
Under UK GDPR, a data protection impact assessment is required before processing that is likely to result in a high risk to individuals, for example large-scale processing of special category data or systematic monitoring of publicly accessible areas. The ICO recommends doing one whenever you are in doubt. The DPIA belongs in selection, before the contract is signed. This checklist confirms it was completed and turns its conditions into configuration tasks, so they are checked in the live settings rather than left on paper.
Set the date before go-live, falling after the rollback point and the end of hypercare. Make the old tool read-only first so people can still look things up, then archive what the retention schedule requires, switch it off and give notice on the contract. A system left running “just in case” keeps old workarounds alive, and you pay twice.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
