12. Deploy

This stage crosscuts all areas of an ERP programme. This is how each workstream can feed into the deployment stage to prepare for cutover.

Service transition

The Service Transition Lead acts as the ‘gatekeeper of production’. They set transition criteria to be met before go-live. This presents a healthy challenge to the programme’s ‘drive to go-live’. Key items are:

• Service transition criteria
• Service transition plan
• Hypercare support model
• Hypercare entry / exit criteria
• Support model
• Knowledge transfer
• Knowledge articles
• ITSM (IT Service Management) tool setup
• Production change order
• Support team impact analysis
• Support team skills matrix
• Up-skilling and resourcing plan
• Monitoring and alerting setup
• Disaster recovery arrangements
• Update and evergreening model
• Daily / twice daily incident call
• Change approval board setup
• First occurrences to be monitored
• Usage telemetry
• Hypercare exit criteria

Cutover preparation

There should already be a cutover strategy in place. Develop this into a high-level cutover plan, including business, technical and full scope production data migration activities.

These documents are needed in preparation for cutover:

• Deployment plan
• Readiness criteria
• Readiness report
• Rehearsal scope
• Entry and exit criteria
• Cutover POAP (Plan on a Page)
• Runbook template
• Runbooks
• Detailed cutover plan (ready for rehearsal)
• Backout plan (to get services back online if the cutover fails)
• Cutover sitrep (situation reports)

Runbooks

Use the high-level plan to lead a ‘familiarisation campaign’ to:

• Get people on board
• Recommend a cutover format
• Introduce runbook templates
• Begin population of the runbooks

Walkthrough

Runbooks are combined to create the detailed cutover plan. This is then checked in a ‘walkthrough’ where all team members talk through the tasks start to finish.

Rehearsals

The goal of rehearsals is to demonstrate that the team can successfully execute the cutover as planned, given the time and resources available. They also identify unknown factors that would scupper a cutover, e.g., out-of-hours resource power-downs.

Rehearsal 1 (R1)

R1 is technology-focused, to prove:

• The main components of the system can be connected
• Data sets migrated (not necessarily full volume)
• Key user group representatives given access

There will be many challenges and lessons to be learnt in R1, so set aside plenty of time. Lessons from R1 should be

Rehearsal 2 (R2)

This is the full and should include:

• The full, actual team that will execute the cutover.
• Full volume data migration.
• Timings as they would be on the actual cutover.
• Entry and exit calls should be included, to get Heads-of comfortable with decision making and the information they will be presented.

The full rehearsal is done to prove the cutover can be done logistically and identify any unknown factors that could derail the event. The list is long and unknown, until you try it.

Rehearsal (R3)

It’s prudent to plan-in an additional contingency rehearsal, known as R3.

Cutover entry call

This call is to get the Heads of each function and technology capability together and confirm a) all readiness criteria have completed or mitigated and b) you can enter cutover. Such criteria are:

Pitfall: Expecting to resolve un-met criteria in the entry call.

Its risky to agree entering cutover without green lights across the board. Senior leaders may need time to consider the risks and mitigations, plus get advice from their subject matter experts.

Solution: Hold readiness checkpoints in the run-up to the cutover entry call, to drive inspection and resolution of incomplete tasks.

Cutover execution

Everything that has been rehearsed now happens for real. This will vary in each cutover. The main steps are:

• Warm up comms to users
• Enable cutover team access
• Tech go-live (enable integrations and processing in the new ERP)
• Hypercare starts to manage the new system
• Connectivity checks
• Migrate bulk real data to the new ERP and check it
• Confirmation comms to users: last entries in the old ERP
• Source systems frozen
• Process in-flight transaction data
• Migrate the delta data to the new ERP and check it
• Check functionality that can be reversed if needed
• Cutover exit call – get a fix-forward or backout decision
• Point of no return
• Functional go-live (enable a small set of business users)
• Live proving (carry out a set of critical operations)
• Enable all remaining users

Useful terminology

‘Fix-forward only’ The new ERP becomes the system authority and single source of truth for data. If there are any issues, they need to be fixed rather than returning to the previous system.

‘Functional go-live’ This is the exciting part. All remaining users are enabled, and communications are sent to announce the go-live. The new solution is now operational and the source of truth for data.

‘Point of no return’ The latest point at which the backout plan can be comfortably initiated to return to the previous system, without impacting business operations.

Hypercare

In hypercare the solution is now processing live transactions. However, the programme team still assists by participating in daily (or more frequent) calls to capture and resolve issues. Key activities and information in hypercare

• Hypercare incident report
• Daily / twice daily incident call
• First occurrence monitoring results
• Usage telemetry
• Hypercare exit criteria (results)

Hold a hypercare exit call to make sure the solution works well and the support teams can comfortably look after the new system.

Pitfall: Not rehearsing hypercare

The team may struggle to turn around a fix with fresh, untrodden ways of working.

Solution: Rehearse assessing and fixing incidents using the hypercare model.