Enterprise Customer Implementation Checklist Template

Answer the scope questions at the planning meeting. They decide whether the migration phase, the identity task and the pilot task appear.

• Name the implementation lead, technical lead, customer project lead and customer sponsor — tasks and both sign-offs are assigned from these fields
• Answer the scope questions — is data being migrated, is single sign-on or SCIM provisioning in scope, and will a pilot come before full rollout
• Review the sales handoff and statement of work — scope, services hours, dates and every commitment made during the sale
• Agree the mutual action plan — milestones, owners on both sides and dates both companies have signed up to
• Set up the steering group and meeting rhythm — sponsor-level steering every two to four weeks, working sessions weekly
• Agree a RACI for each workstream — one accountable person per workstream, with a named person on each side
• Open the risk and decision log — every risk with an owner, every decision with a date and who made it

• Complete the security questionnaire — the customer’s own or a standard such as the SIG or CAIQ, with your SOC 2 report or ISO 27001 certificate where you have one
• Agree the data processing agreement and sub-processor list — including how the customer is told about future sub-processor changes
• Confirm data residency and hosting region — and note any data that must not leave a region
• Set up single sign-on and SCIM provisioning — shown only when in scope; test sign-in and user creation, update and deactivation with the customer’s identity team
• Complete supplier set-up and the purchase order — so the first invoice is not rejected for a missing PO number

• Configure the environment to the agreed design — workspaces, roles, permissions, templates and notification settings
• Build each integration in a test environment first — with error handling and a named owner on each side
• Test permissions with real roles — sign in as each role and confirm what it can and cannot see
• Run user acceptance testing — the customer’s testers work through scripts written from the success criteria
• Customer project lead approval of UAT results — defects are fixed or accepted in writing before go-live planning starts

Shown only when data is being migrated from another system.

• Agree what moves and what stays behind — by record type and date range, with an archive plan for the rest
• Map fields and clean the source data — duplicates, closed records and free-text values that need to become a list
• Run a trial migration and reconcile counts — record counts plus a sample checked by the customer’s data owner
• Agree the cutover freeze window — when the old system goes read-only and who can approve an exception
• Plan the final migration run — sequence, timings and the reconciliation report for go-live day

• Train the customer’s administrators — user management, configuration changes and how to reach support
• Run train-the-trainer sessions for team champions — so each department has someone who can answer the first questions
• Run the pilot with one team and review the results — shown only when a pilot comes first; agree the criteria for widening the rollout before it starts
• Publish end-user guides and short training — built around the customer’s own workflows, not a product tour
• Send the change communications — what changes, when, why and who to ask, from the customer’s sponsor rather than the vendor

• Run the go-live readiness review — UAT signed off, users provisioned, training done, support staffed and data reconciled
• Confirm the rollback plan and decision point — what would trigger a rollback, by when, and who decides
• Customer sponsor approval of go-live — the checklist halts here until the sponsor approves the date
• Execute the cutover plan — final migration, integrations switched on and the old system set to read-only
• Staff go-live support — named people on both sides, one channel for issues and a daily review

• Run hypercare for the agreed period — daily issue triage and faster responses, for the period set in the statement of work
• Track adoption against the success metrics — active users, workflows in use and the measures agreed at the start
• Close or transfer the open issues — fixed, accepted, or moved to standard support with an owner
• Hold the transition meeting with the CSM — the CSM takes the account with the success metrics, risks and decisions on file
• Run the implementation retrospective — with the customer: what to keep and what to change for the next project