New Software Implementation Checklist Template

What the Software Implementation Checklist Covers

1. 1
   Phase 1

   Phase 1: Handover & Ownership

   6 tasks

   The answers on the first task shape the rest of the checklist.

   • Open the implementation record and record what was bought — product, edition, licence count, renewal date, and whether it is SaaS or installed, replaces an old tool or needs data migrated
   • Confirm the security and data protection reviews were closed at selection — carry every condition they set, such as MFA or UK data residency, into Phase 2 as a task
   • Name the business owner, technical owner, go-live approver and champions — the business owner decides how the tool is used; IT keeps it running
   • Set three to five success measures and record today’s baseline — without a baseline taken before go-live, nobody can show what changed
   • Agree what is in the first release and what waits — features added during configuration are a common reason go-live dates slip
   • Fix the go-live date around the business calendar — avoid month-end, peak trading and the week the key users are on leave
2. 2
   Phase 2

   Phase 2: Configure & Integrate

   7 tasks

   The last task appears only for installed software.

   • Configure in a sandbox or test tenant first where the licence includes one — promote settings to production once they are agreed, not while they are still being debated
   • Connect single sign-on and switch off local passwords — a local login bypasses MFA and survives the leaver process
   • Provision and deprovision users from directory groups — SCIM or a scheduled sync, so access follows group membership and ends when someone leaves
   • Map roles and permissions to groups — least privilege, with a named administrator and a named backup
   • Apply the conditions from the security and data protection review — retention, audit logging, data location and external sharing, each checked in the live settings
   • Build and test each integration with its own service account — record an owner and what breaks if the integration stops
   • Package the client and deploy it to a test group of devices — confirm it updates through your normal patch process rather than by hand
3. 3
   Phase 3 — Migration Only

   Phase 3: Data Migration

   6 tasks

   Tasks appear only when data migration is in scope. A tool that starts empty goes straight to the pilot.

   • Decide what moves and what stays behind — older history often stays in a read-only export rather than cluttering the new tool
   • Map every field from the old system to the new one — including values that have no home, with a decision for each
   • Clean the data before it moves — duplicates, leavers’ records and closed items carry their mess into the new tool
   • Run a trial migration and reconcile it — record counts and totals per type, plus a sample of records checked end to end
   • Have the data owner sign off the trial result — the person who uses the data, not the person who moved it
   • Set the final extract date and freeze changes in the old system — anything entered after the last extract is lost
4. 4
   Phase 4

   Phase 4: Pilot, Training & Comms

   6 tasks

   • Run a pilot with one real team doing real work — two to four weeks is a common length; a demo to IT staff is not a pilot
   • Log every pilot issue with a decision — fix before go-live, work around, or accept, each with an owner
   • Build short training for the tasks each role does most — five task guides per role beat a tour of every feature
   • Brief managers before their teams hear about it — a manager who cannot answer questions quietly slows adoption
   • Announce go-live with dates, what changes and where to get help — including what happens to the old tool and when
   • Brief the service desk and set up a ticket category — known issues, the escalation route to the technical owner and the vendor support process
5. 5
   Phase 5

   Phase 5: Go-Live Approval & Cutover

   6 tasks

   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.

   • Raise the change record for go-live — attach the pilot results, cutover plan and rollback plan; approval runs through your normal change process
   • Set the rollback point — the last moment you can switch back without losing work entered in the new tool
   • Check the go/no-go criteria — pilot issues closed or accepted, training delivered, data signed off, support ready
   • Record the go-live decision — the named approver records approved or not approved, with the reason
   • Cut over — final data load, access switched on for every user group, old tool set to read-only where it is being replaced
   • Test the key journeys with real users on day one — sign-in, the three most common tasks and every integration
6. 6
   Phase 6

   Phase 6: Hypercare & Adoption

   6 tasks

   • Run hypercare for a fixed period with a daily check-in — two to four weeks is typical, with one named owner for issues
   • Group hypercare tickets by theme — repeated questions become guide updates; repeated faults go to the vendor or to problem management
   • Measure the success measures at 30 and 90 days — against the baseline from Phase 1, not against a general feeling
   • Find the teams that have not moved and ask their managers why — usage by team shows where the old workaround lives on
   • Hand over to business-as-usual support — admin runbook, vendor contacts, support route and the renewal date in the contract register
   • Close hypercare with a short review — note what to change in this template before the next rollout
7. 7
   Phase 7 — Replacements Only

   Phase 7: Retire the Old Tool

   6 tasks

   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.

   • Set the retirement date and announce it — a fixed date moves the last holdouts better than reminders do
   • Export and archive the records you must keep — against the retention schedule, in a format someone can still open in five years
   • Make the old tool read-only, then switch it off — and remove it from single sign-on and the software catalogue
   • Give notice on the old contract before its renewal date — check the notice period, because auto-renewal clauses can require notice months ahead
   • Remove leftover installs, integrations and service accounts — a dead integration can still hold live credentials
   • Update the asset register and the licence records — licences you stopped paying for should leave the books too