Succeeding with go-lives
It could be a complex ERP implementation. Or an implementation of a new IT service impacting thousands of users. Or maybe a large-scale industry-specific system transformation with catastrophic impact for the business if failing.
Your project management is focused on getting all development and test activities done to have the product ready for the go-live. Now, questions start to surface.
Here, you may want to look at cutover management to back your implementation. Cutover management is the planning and coordination of activities and tasks required for a successful go-live with as low business impact as possible.
In terms of benefits realisation, a successful cutover is not only the final gate to finally enabling project benefits to be harvested to the full extend.
A successful cutover also ensures that fallback to previous system and data state is possible so you avoid worst-case scenarios.
Consider the cutover stage as a heart transplant. You replace vital components in the business while doing everything to ensure that the business is kept running and suffers as little as possible from the procedure.
If you start addressing some of the questions above too late, you are not alone. Both studies1 and our experience tell us that companies often keep cutover out of focus in the programme or project until it is too late to execute cutover with a controlled approach, mitigating the risks of a failed go-live.
Often, companies focus on delivering quality on time at the expense of cutover planning. It is a paradox since the cutover phase is the most vital phase of any digital transformation, and all parties seem to know the importance when being asked.
If you engage cutover management too late, it is limited what you can do to minimise risks and have mitigating actions in place.
Begin with the end in mind
Dr. Stephen R. Covey
That is why we always recommend considering cutover management within the initiation phase of the programme or project and frontload cutover activities as a key principle in the cutover approach.
Cutover management is a dedicated discipline. It is a proposition if you are running large and complex IT projects and if you will suffer severe negative impact from a failed go-live. Extensive experience from cutover phases leading to major go-lives has been the basis for a proven cutover method and tools, which is why cutover management should not be perceived as an add-on to existing project management.
Often, a failure at the go-live (or cutover) stage of a project will implicate:
In this viewpoint, we present our key learnings on how you effectively mitigate risks using a thorough cutover approach by sharing:
When you go through the process of moving from one set of business processes, system support and data to a new operational model, you always introduce risks. Some scenarios in the world of today may be forgotten when designing the world of tomorrow. That is why best practice within requirements management is ongoing involvement of the operational organisation in design and development. Thorough testing is a ubiquitous trait of good IT projects.
Similarly, when we move from the world of today to the world of tomorrow, the process is embedded with risk. This is due to the complex of interdependencies that set requirements for sequencing of start/ stop of specific business processes, integrations, system components and data migration.
In order to remove risks, you must work actively on your project to reveal and resolve issues that may occur and introduce mitigations for known or disclosed risks prior to entering the critical cutover period. You minimise cutover risks through thorough planning and rehearsals of the cutover period and by carrying out all the activities that are possible to carry out prior to entering the actual cutover period.
To operationalise the essential principle of frontloading, you structure your cutover management activities around three phases: planning, pre-cutover and cutover.
During the initiating activities in cutover management, you establish clear roles and responsibilities for the cutover activities. In a typical project, you do not settle a dedicated cutover manager position from the point of project initiation; however, the responsibility of frontloading the cutover and ensuring that the cutover activities are addressed must be established already as part of the programme or project organisation.
Cutover planning requires broad stakeholder involvement from the project team as well as the affected system and process owners in the receiving organisation. It is part of cutover management to ensure that all stakeholders are involved.
Effectively, the involvement of stakeholders gives input to essential cutover plans:
High-level milestone planning defines the milestones that the project must achieve in order to be ready for the cutover. The cutover responsibility is to continuously carry out assessments of the cutover readiness. The readiness assessment should address each workstream and cover both product readiness in terms of test outcome and defects and the organisational readiness for working with the system post-go-live.
Furthermore, specific activities related to cutover readiness should be addressed, such as readiness of cutover plan, readiness to conduct data migration actives and readiness for managing the hypercare period.
The project concerned a replacement of Player Account Management System. It involved major data migration and 120+ integrations. Across client and vendors, a total of 170 people were involved in the project.
As part of the project, a two-day workshop was facilitated to prepare first draft of the cutover activity plan. The result was a plan for the cutover consisting of 16 tracks and 60 people who were assigned actions during cutover. The plan was matured and updated during three rehearsals, where the cutover was simulated in production-like environments.
Despite the value of high-level milestone planning to report the overall progress and readiness for entering cutover phases, it cannot serve as a tool to guide you through the process of an actual cutover. For that, you need a script or a playbook. During cutover planning, you facilitate a workshop in which you establish scope, sequence, dependencies, duration and responsibilities of individual cutover activities. Secondly, you compose the elements in an overall planning document with a highlighted critical path that can be validated, rehearsed and utilised as a coordination tool in the actual cutover.
You should never enter a businesscritical cutover without a detailed cutover activity plan that has been tested and qualified in rehearsals prior to the actual cutover. Rehearsals ensure that individual activities and their interdependencies are validated. You also use the detailed cutover activity planning workshops to identify points of return (fallback points ).
As previously mentioned, a cutover always goes hand in hand with risks. You should not enter the cutover phase without having thoroughly considered undesired scenarios that could happen. Having a fallback plan and escalation procedure for the dominant risks helps you to respond quickly to undesired situations by allocating resources, facilitating decisions and executing fallback.
The cutover planning phase is active all the way to the point of cutover and works in parallel with the pre-cutover phase.
The project concerned an end-to-end replacement of an ERP system and major rollout. In the scope were HQ and 25+ subsidiaries across seven time zones, involving the migration of 150+ million records and 700,000+ documents.
The characteristics of the subsidiaries in scope were that operations could not run during cutover. The project prepared interim processes, but system freeze had to be limited to an absolute minimum. This required frontloading as many activities as possible in the pre-cutover phase and executing the actual cutover with immense time constraints. Included in the critical path during cutover were helicopter transport of disks to offshore locations, internet stability considerations etc.
Once the pre-cutover readiness assessment is carried out and approved, you can start the pre-cutover activities. These are any activities that you can start prior to the actual cutover, which often requires freeze systems having significant negative effects on the existing operational environments – both technical and organisational. Examples of pre-cutover activities could be migration of master data, setting configuration parameters and environments that have no or very limited impact on ongoing operational processes.
In theory, the pre-cutover phase may sound as being limited in content. But in practice, the pre-cutover phase helps you to focus on frontloading and executing cutover activities without the risk of carrying these out in the critical cutover phase.
Throughout the planning and pre-cutover phases, you typically report the cutover readiness to both steering committee and management in the organisation. At the end of the pre-cutover phase, a final go/no-go decision will be facilitated to get formal decision to start cutover.
During the cutover phase, you will execute the detailed cutover activity plan, including all the updates and learnings gathered during rehearsals. All stakeholders know what to do and when. All cutover activities are orchestrated and coordinated by the cutover manager. Having a central single point of control ensures that the critical path of cutover is followed. Delays in one activity will typically have a collateral effect, which in the end can postpone the planned go-live time. This becomes even more critical if the go-live time has constraints attached, which is often the case due to a limited change window allowance. To support cutover management and have a detailed understanding of progress, it is important that all involved stakeholders follow the agreed lines of communication.
There are no two cutovers that are alike. Whether it is an ERP system implementation, implementation of self-developed IT solution or something else, the required cutover activities vary depending on size, complexity and criticality.
That said, a cutover typically includes:
You should keep your cutover phases as short in time as possible. Go/ no-go meetings with management involvement are often used prior to the controlled stop of business operations and system freeze. Once technically live, a controlled go-live can be executed to complete functional validations in the new system. All playbooks and data required for the production validations are prepared and rehearsed in advance as a natural part of cutover.
When validations are complete, cutover management prepares a final go/no-go decision report as foundation for the final go/no-go decision to be taken by steering committee or management.
Due to the ongoing progress tracking and transparency from the readiness assessment, the final go/no-go decision is typically considered a formality.
Communication activities are often the final part of the cutover activity plan. Hereafter, the cutover is considered over, and responsibility is transitioned to operations and hypercare support.
Although some organisations have reached a level of IT architectural maturity that allows slicing and dicing the stack as well as infrastructure as a service and release on demand, it is far from ubiquitous across the broad spectrum of IT projects.
There is always that critical transactional system where hardware is still provisioned and in limited supply and/or where the vendor is not contractually obliged to support infrastructure as a service. However, as the agility in software interface changes increases and the speed of environment creation escalates, the cutover will carry less risk, and the process will run smoother. Paradoxically though, as some things are eased, the complexity of IT landscapes has not slowed down. This calls for even more control of the full picture of components in the cutover process.
The ability to release on demand enabled by feature toggles or the like reduces the risks in the cutover; however, in truly transformative projects, the changes are often of a scale and complexity where release on demand architecture may not be considered.
The project concerned an IT solution developed in house to support new EU cross-border VAT legislation. It involved a Large Solution SAFe setup with 10+ fully stacked agile development teams delivering required features.
The project organisation and ways of working were designed according to SAFe knowledge base of proven integrated principles and practices. The ambition was a continuous delivery pipeline enabled by DevOps and a System Team doing all they could to support by developing and maintaining the toolchain. At the end of the day, the solution developed had a size and complexity that did not allow ongoing releases and feature toggles.
Almost all functionalities had to be available in one go at a certain date specified by the EU.
To secure a low-risk smooth transition after go-live, it was decided to use dedicated cutover management to have a single point of control and coordination of the entire release process not only covering the technical side of planning, readiness assessments and execution but also the business and operations side.
Furthermore, one-time executions of large and complex transformation tasks are very common. In a case going from one ERP system to another, data migration is rarely a programmed and autonomous activity, hence it requires collaboration and coordination to be carried out at the right time and sequence of its dependent cutover activities.
Changing business processes require a coordinated approach, in which stop of legacy business processes and start of new business processes do not jeopardise open transactions across the value chain. Hence keeping track of the business part of a significant cutover (including rehearsals, readiness assessments and execution) will typically call for a cutover management focus. Cutover management is a governance discipline – not a technically contingent and standard process.
So, even if perception is that there is an ability to deploy and go live with a highly limited risk profile due to your mature and agile architecture and governance, do consider cutover management as described if you are on your way with a significant business or IT transformation enabled by one or more technical go-lives.
The need for dedicated cutover management varies depending on the project risk, business criticality and complexity. The amount of effort to put into the initiatives within cutover management also varies. However, it should be clear to all in the organisation where the responsibility for cutover is placed.
With the variation of project characteristics and required cutover management effort in mind, do consider the following points as inspiration to ensure that you cover significant cutover frontloading activities.
If you can confirm that you have planned the points listed above, or they have already been achieved as part of your business-critical IT implementation, then you have most likely had a dedicated and early focus on cutover management. It indicates that you have the prerequisites for a successful go-live in place.
If not, it is time to get started! You need to make sure that the preparations and execution of the most vital phase in your IT implementation becomes a success.
1 Nageldinger, G. (2015). A framework for cutover management. PeerJ Computer Science 1:e29. DOI 10.7717/peerj-cs; Wingate, G. (2016), Case Study 13: Enterprise Resource Planning Systems. In Pharmaceutical Computer Systems Validation: Quality Assurance, Risk Management and Regulatory Compliance (2nd ed., pp. 596-614). Boca Rato, FL: CRC Press.
What is the most efficient starting point?
(Spoiler: It’s not “influencers”).
Implement Consulting Group