Cutover – The supreme discipline of system launches

IT system landscapes are constantly becoming more complex, which makes replacing or launching systems much more difficult. Moreover, if a central system is involved, the sheer complexity seems to end the project before it has begun. To ensure that even such projects are manageable and successfully completed, there are cutover projects.

• introduction
• process model
• planning phase
• cutover plan
• execution phase
• tools
• success factors
• summary

Introduction

The term cutover is still not very familiar or unknown to many project leaders and managers. Therefore, the introduction starts with a short definition. Based on this, related terms are explained and ambiguities are cleared up. The introduction is rounded off with use cases to sharpen the view and necessity of cutover projects.

Definition

Cutover is the overall consideration (planning, execution and monitoring) of the migration from a previous to a new system or from an old to a new process world. The core element of the cutover is a large number of small, interdependent and differentiated tasks that must be performed/processed in a coordinated manner by a larger group of people.

Another more colloquial definition is: "Cutover means a very complex go live."

Related terms and ambiguities

In the following, the ambiguity of the term cutover is discussed and the differences are elaborated. In addition, the two related terms cutover management and cutover plan are explained.

In linguistic usage, the term cutover is used in parallel as a point in time of migration, as a process model (not a formal model) and as a short form for cutover project. Consequently, the context is crucial in order to clearly understand the context. Furthermore, many compound terms exist which already contain cutover in their name. Examples are cutover management and cutover plan, which are explained below.

When cutover is used as the time of migration, it primarily refers to the day or weekend of system launch. The preceding and subsequent tasks, which do not lie in the period of the migration, are hidden here. Nevertheless, all tasks must be successfully completed at the end for the overall project to be successful. In practice, the terms live cutover and go live, among others, have also become established and accepted.

Due to the complexity of large system launches, the term cutover is also used to describe a process model that significantly increases the success of such IT projects while at the same time reducing the risk as much as possible. Part of the process model is, among other things, a phase model for the overall consideration of a cutover and best practices, such as dress rehearsals and fallback scenarios. Perhaps one or the other has already heard the statement: "This year, we still have a cutover ahead of us!" Ultimately, what is meant by this is that another cutover project is due this year and that this is to be approached according to the proven process model.

Cutover management refers to all supporting topics for the successful planning, control, execution and monitoring of a system launch (IT project). These measures are supported or carried out by external IT consultants (IT consulting) as well as professional tools. Accordingly, cutover management is often found as a key term on websites that offer a service in this area.

The portfolio of consulting services covers the holistic cutover consideration and is optimally supported by professional tools in the best case. Examples from the portfolio for the planning phase are:

• Support of the business department in determining the cutover tasks to be performed
  • Analysis of the business process and identification of the individual steps for system launch
  • Compile individual steps into meaningful tasks that are not too big and not too small in scale
  • Determine responsibilities and interdependencies between tasks
• Check the tasks for fallback suitability

In addition, the portfolio also includes project management activities, such as risk management, resource and schedule coordination, which must be performed early and continuously in the cutover project. The portfolio is usually rounded off with a colorful bouquet of services for controlling the correct execution of tasks.

In conclusion to the definition of the term, the term cutover plan should be discussed. This is the so-called heart of every cutover. It is interesting to note that this statement applies both to the time of the system launch and to the overall process. The plan itself contains all the tasks/milestones, relationships/dependencies, responsible parties, etc. Again, other terms have become established in practice. The most commonly encountered are master plan and screenplay.

The term master plan has therefore become established in practice to explicitly express that there is only one "single source of truth" and thus only ONE plan exists that contains all information. It is similar with the screenplay (there cannot be several screenplays for the same scene), but here the focus is on task control. This is to be processed stringently according to the screenplay.

What characterizes a cutover project?

Probably the biggest and decisive difference to classic project planning is the meticulous planning in 24x7 mode. This means that a cutover plan contains many small tasks, from a few minutes to single-digit hours. The focus is on planning the live cutover, where on average about 70-90% of all tasks are performed. The rest are preparatory and follow-up tasks, around the live cutover. In contrast, traditional project planning involves planning the tasks, including resources, over the overall life of the project, where typically the duration of a task is more in the range of weeks. Typically, cutover projects have an average duration of 6 to 24 months.

The cutover plan is built up successively in the individual teams. This results in plans with sometimes several hundred to thousands of tasks. These in turn have many interdependencies, i.e. at a certain level of maturity of the individual plans, they must be brought together in a master plan and maintained there. Over time, not only a detailed, but also a high-quality plan is created, which is tested via dress rehearsals. By using professional tools, the team can also carry out the initial planning, the merging of the individual plans, and the ongoing changes to the task details in a decentralized and parallel manner.

As a rule, many people involved in a cutover have to be coordinated. As a result, not only do the people responsible for the tasks within the company have to be coordinated, but coordination also has to be carried out with the partner and external companies involved. The number of people involved can quickly reach triple digits.

Use cases

In general, any use case that wants to take advantage of a cutover project is suitable. Namely, the controllable small-scale planning, control and monitoring of hundreds of tasks with countless dependencies and many people in a short time window (day or weekend). This tends to apply most often to IT projects in the context of IT transformation or digitization in the enterprise. Examples include:

• Replacement of IT systems (e.g. core banking system)
• Launch of IT systems (e.g. ERP or DMS)
• IT systems upgrade (e.g. to SAP^® S/4HANA)
• Data center relocation (e.g. re-hosting in the cloud)

In addition, the takeover/spin-off (carve-out) of companies can lead to IT projects with the aim of standardizing or separating the IT system landscape. Furthermore, the planning and control of periodic releases in companies also represents a use case. More extensive system/release launches can thus be carried out in a coordinated and controlled manner. By using professional tools, a large part of the tasks could also be automated via a machine-to-machine (M2M) interface as dark processing and thus not tie up personnel resources.

Process model

Cutover projects are specialized in coordinating hundreds of tasks with various dependencies and many responsible parties across the finish line in a short time window. To ensure that these projects are successful while minimizing risk as much as possible, various methods and best practices have become established in practice. These are summarized under the keyword process model. In other words, it is a written mindset of experienced cutover managers. All components of the process model are to be understood as a blueprint and should/can be used project-specifically and adapted to the individual project conditions. Nevertheless, individual components should only be avoided very cautiously and well argued in the sense of minimizing the risk of the overall project.

The following list shows the components of the process model, which are described in more detail below (no claim to completeness):

Planning phase

Successive development of the cutover plan in the teams

• Elicitation of team-specific tasks with team-internal dependencies
• Merging of the team plans into a master plan with cross-team dependencies
• Go/No-Go decision: Latest point in time at which a termination and a reset to the "old world" is still feasible
• Fallback scenario: Procedure in the event of a cutover cancellation (reset to the "old world")
• Resource planning: Resource deployment times, working time overruns and HR/works council notifications
• Data quality and consistency check: Continuous check of the plan
• Downtimes: Preparation and follow-up tasks are not scheduled in 24x7 mode; tasks are not started or allowed to end during downtimes

Execution phase

Correct execution of all tasks

• Control center: Coordinates and monitors execution
• Dress rehearsal: Quality check of the cutover plan and the planned processes/workflows and feedback of findings into the master plan
• Task status: Workflow of tasks

Cutover team

Roles and descriptions

Reports

Traceability and documentation of changes to the plan

Cutover phases

A cutover consists of the two phases: Planning and execution.

The planning phase begins directly with the start of the project and ends only with the start of the live cutover. From the first dress rehearsal, the execution phase starts in parallel, which also includes the live cutover.

As the name suggests, the planning phase is primarily concerned with the creation of the plan. This should take place iteratively, decentralized and collaborative in the relevant team. For ideal support, there are professional tools that should be used as early as possible. Nevertheless, it is also possible to switch to other tools at a later point in time, when the number of tasks reaches triple digits.

In the execution phase, all activities that are necessary for the correct processing of the tasks are carried out under real conditions. In principle, there is no distinction here between a dress rehearsal and the live cutover.

In reality, the planning phase overlaps with the execution phase, as findings from the dress rehearsals are integrated back into the master plan on an ad hoc basis to continuously improve the quality of the master plan. Examples of new findings include:

• Correction of dependencies between tasks
• Adjustment of the duration of a task
• More detailed descriptions of a task

Cutover team

All persons involved, including partners and external companies, who have a relation to the cutover are implicitly part of the cutover relevant team. This quickly results in a three-digit group of people that must be managed. Each participant has his or her individual project requirements and goals, which must be taken into account. In order to organize the project in the best possible way in the individual phases, the following roles should be present or explicitly occupied in the team:

Cutover manager

Main person responsible for the cutover project; thus carries the overall responsibility – deputy necessary (the role exists only once in the team)

Manager

Support and supervise the project on management level

Planners

Support involved persons/departments in planning and capturing their tasks – often filled by consultants from outside companies

Control center manager

Responsible for the execution/control of the cutover – deputy is necessary (role exists only once in the team)

Control center staff

Supports the control center manager to enable 24x7 execution/control – often 3-5 people and staffed by contractor consultants

Task receiver

Responsible for the execution/control of a task – can also be persons from partner and external companies

Reports

Projects of this size and scope require clean traceability and documentation of all core activities right from the start. This is the only way to ensure the necessary auditing reliability. This includes, above all, the question: "Who entered or changed what in the cutover plan when? Accordingly, all changes to task (meta information and details) should be historized. This applies to both the planning phase and the execution phase. The second involves recording how and when a task (status model) was processed.

When selecting suitable tools, the existence of an adequate reporting system should be included in the criteria catalog. A nice side effect is that a report on all planning activities or execution activities can help with troubleshooting. A typical scenario for troubleshooting is the question on which plan change the unwanted major time shift of a milestone or even the time of the go/no-go decision is based?

Planning phase

The planning phase starts with the project beginning and ends only with the start of the live cutover. During this time, a meticulous and finely tuned cutover plan is developed collaboratively within the team. This plan is then finally executed in the live cutover. Until then, however, it is a "long" way, with many collections, questions and coordination.

Centralized vs. decentralized planning

The answer to the question of centralized vs. decentralized planning should be answered as early as possible in the project. This decision also has a direct impact on the tools used and the recording of tasks from the individual subprojects, IT and the specialist departments. The following table compares the two approaches.

From our experience, decentralized planning should be preferred whenever possible. This supports the cooperative team approach in the best possible way.

Cutover plan

The cutover plan is the heart of every cutover. On the one hand, it represents a flat list of tasks and, on the other hand, a finely structured sequence of all tasks with the meta-knowledge required for them (dependencies, groupings, etc.). The requirements for the plan are therefore as follows:

• Tasks must be able to be collected, planned and managed in detail within the team
  • Define the duration of a task
  • Managing dependencies
  • Managing responsible users and/or groups
  • Grouping of tasks
  • Documenting/historizing task details
• Handling hundreds of tasks
• Generating management information from the current plan
  • Milestones and phase plan
  • Resource requirements

The management information is needed for the presentation of the first overall plan to the management after its creation. In the execution phase, management can thus independently obtain information on the status of task execution at the level of detail that is of interest to them (phases, milestones, tasks). The phase plan and the milestones represent a higher abstraction of the cutover and are therefore better suited for communication with (top-level) management.

Tasks

A task is the smallest controllable entity in the plan and is defined by its attributes. All necessary information must be described for a task in order to enable the respective employee(s) to execute the task correctly. The following list shows the attributes/information of a task most frequently encountered in practice:

• Milestone (yes/no) – a milestone has no duration
• Name
• Description
• Duration – in minutes/hours/days
• Start type
  • Relative to other tasks (predecessor and successor)
  • Fixed timestamp
  • Combination of both criteria
• Grouping criteria – labels or tags (locations, IT systems, business units, etc.)
• Responsible user(s) or group(s)
• Informed user or group(s) – i.e. CC mail recipients

For tasks without a fixed start timestamp, the planned start and end times can be calculated based on the duration and predecessors, so these cannot be maintained as independent attributes.

Go/No-Go decision

The go/no-go decision is the latest point in time (point-of-no-return) at which an abort of the live cutover (rollback) is still feasible. After that, the cutover time window is no longer sufficient for the required duration of the rollback to the "old world". When rolling back all previous tasks/activities, the fallback scenario (independent plan) comes into play.

In practice, the time of the decision is often shown as a monitored milestone in the plan, which also represents the critical path. The decision itself is usually made in a management meeting. For this purpose, all teams involved in the cutover provide the current status of their cutover progress to date. In addition, the control center provides a cutover status. Taking into account all available information and, if necessary, considering whether existing deviations can be corrected in the follow-up, a decision is made. This decision is irrevocable.

In the case of a go decision, the cutover continues as planned. In contrast, the fallback scenario occurs in the case of a no-go decision, which should be available as a plan and should also have already been tested at least once.

Fallback scenario

The fallback scenario comes into effect when the live cutover is aborted. It is often the consequence of the no-go decision. The scenario itself is a plan that returns the system to the state BEFORE the cutover. This includes technical tasks, such as restoring backups, as well as business issues, such as customer communications.

The fallback plan can be maintained as a separate flow in the cutover plan or managed in a standalone plan. This is an individual decision due to the complexity and the number of fallback tasks. At this point, it is strongly recommended to also test this case in a dress rehearsal. A good backup strategy is an essential part of efficient risk management.

Resource planning

Every person involved in the live cutover or dress rehearsals needs to know about their duty times. For this purpose, a chart with hourly scaling of all resources is useful. On this data set all working time overruns (in Germany not longer than 10h allowed) or the non-observance of rest periods can be calculated mathematically. Furthermore, the overview serves as a template for HR/works council notifications in order to obtain special approvals for extended working hours or weekend work. Accordingly, the template must provide the following information:

• Who works when and for how long (accumulation of overtime)
• Working on Saturdays or Sundays and at night
• Who exceeds the permitted working hours

Data quality and consistency check

One of the essential activities in the planning phase is the continuous checking of the cutover plan, which helps to continuously maintain the necessary data quality. Since manual checks cause high manual efforts and due to this would most likely fall asleep over time, the tools used should provide the necessary support at the push of a button. Examples of checks are:

• Task without duration
• Task without responsible
• Task with a relative start without a predecessor
• Duplicate detection
• Dependency cycle
• Responsible user in parallel tasks

As can be seen from the examples, some checks are very simple to perform. Nevertheless, they are just as important. On the other hand, the checks like the "Dependency cycle" and "Responsible user in parallel tasks" are practically impossible to perform manually. Especially the second check is very crucial, because corresponding misplanning can have a direct impact on resource planning and dependencies of tasks among each other (parallel vs. sequential).

Downtimes

As can be seen from the definition, a cutover is planned in 24x7 mode, i.e. within a certain time period around the clock. Nevertheless, there are always preparation and follow-up tasks in the days or weeks before or after the cutover, which are to be executed during normal working hours. Nevertheless, these tasks have various dependencies on predecessors, which must first be completed before their own processing is allowed.

Consequently, downtimes are available, which block any time window (from hours to days) from the 24x7 mode and thus shift the tasks to desired working times in a planned manner. During the downtimes, tasks are not started and tasks are not allowed to end during the downtimes. If this happens, the start times will be shifted to the next working times (not downtimes).

Execution phase

In the execution phase, the tasks are executed according to their planning. It does not matter whether it is a dress rehearsal or the live cutover. The cutover process is always controlled from the control center. This initiates the start of a task, monitors and documents its status. Furthermore, the ability to provide information must be ensured at all times during execution. This means that the current execution status by comparing the target and actual times must be visible in "real time". In addition, statistics and visualizations (Gantt chart) should support the ability to provide information.

Control center

The responsibility for the correct execution of all tasks lies with the people from the cutover team who form the control center. Ultimately, the control center manages and monitors the execution of each task. In other words, they work off the screenplay. In doing so, they always keep track of the overall plan and must be available (mail & phone) 24x7 for all stakeholders as well as management.

To ensure that the process is carried out correctly, they are responsible for initiating an individual task. This means that a task may only be processed by the responsible user after it has been released (e.g. notification by e-mail) by the control center. Furthermore, the user must report his processing status so that the control center can react immediately in case of any deviations or problems. Even a positive deviation, i.e. an early task completion, requires a reaction in the control center. Those responsible for the next tasks must be notified - if possible with a certain lead time - e.g. that their task is to be started an hour earlier.

In order to ensure smooth processing of the cutover plan, the control center is the primary contact for all incidents and always. The spectrum of possible incidents is huge and can lead to any number of problems in task processing. Professional cutover planning also includes the definition of escalation levels and the designation of appropriate contacts in order to be able to act in an organized and professional manner in the event of a crisis and to develop prudent solutions. In addition, however, technical or organizational issues can also disrupt execution. Examples of this are:

• Access card expired
• User locked (account)

The control center team must also be able to provide information at all times. It reports directly to management at defined times or milestones (execution status), but must also always be able to pass on the status of the cutover process in the event of ad hoc inquiries from management or stakeholders. It also brings together all the information for the go/no-go decision and invites to status meetings.

Dress rehearsal

The dress rehearsal is a trial of the current cutover plan held under conditions that are as real as possible. The aim here is to practice/internalize the processes of the responsible employees and the control center team, thus leading to a certain routine. In addition, gaps and grievances in the plan are to be identified and corrected on an ad hoc basis. Typical re-tweaks include the duration of a task or its relationships to other tasks, i.e., adjusting predecessor relationships. Since the dress rehearsals take place before the live cutover and thus on a different day or weekend, the challenges listed below arise with the corresponding measures:

Vacation planning of employees

Easily implement a substitute arrangement without having to adjust the cutover plan

During the week while working hours

Deposit of downtimes in the plan (night planning)

Adjust fixed start times

Dynamic adjustment of fixed start times of tasks by the changed start time of the overall plan

Knowledge transfer or feedback to the cutover plan

• Only ONE master plan may exist
• Synchronization ONLY from the master plan to the execution plan

The vacation planning of employees is probably the biggest challenge during the dress rehearsals. Practically, it is impossible to impose a vacation block for the entire cutover team during dress rehearsals and the live cutover. Therefore, it is advisable to be very accommodating to the employees and their vacation plans during the dress rehearsals and to think about other measures, such as a vacation block, only during the live cutover. For this reason, there should be an overarching and transparent substitute rule that makes it possible to store a substitute without having to adjust the cutover plan. This means that the responsible user of a task is not replaced in the cutover plan, but is transparently and dynamically replaced by his substitute in the background during the execution of the task. At this point, cutover tools should offer an adequate solution.

The measures for "knowledge transfer or feedback into the cutover plan" are based on the single-source-of-truth approach. This means that the execution plan should be a complete copy of the master plan so that all knowledge can be immediately maintained in the master plan during execution. Via a synchronization mechanism, changes in the master plan that have been released via the control center can then be transferred ad hoc to the execution plan if necessary. Here, too, good tool support is an absolute prerequisite.

Task status

In the execution phase, all tasks have a processing status. The status model describes the permitted status transitions and thus regulates the correct processing. For the model itself, a pragmatic approach should be taken that strikes a good balance between micromanagement (many status values) and too coarse status values. In our experience, 5 status values is a good measure. This is a practical way to map the problems we know and frequently encounter in the control center. The status values are as follows:

OPEN

The OPEN status is the initial value of each task and states that this task is not yet in the focus of the control center. Reasons for this can be that the preconditions are not fulfilled, such as the fixed time of the start has not yet been reached or the predecessor tasks have not yet been completed (in the status DONE).

INITIATED

The status transition from OPEN to INITIATED is triggered via the control center. This indicates that the responsible user of the task may/should start processing.

STARTED

The status transition from INITIATED to STARTED is triggered by the person responsible for the task. This lets the colleagues in the control center know that the request to start has been received and that the user has started processing. If this feedback from the person responsible to the control center is not received (> 5min), the person responsible should be contacted as quickly as possible via the control center using a different communication channel as for initiation.

DONE

The status transition from STARTED to DONE is triggered by the person responsible for the task. This lets the colleagues in the control center know that the task has been completely processed. If the processing time is longer than the planned duration of a task, the control center must act proactively and consult with the responsible person immediately after the planned end time.

POSTPONED

Since problems are always to be expected, especially with hundreds of tasks, a status must also be available for this. The POSTPONED status indicates that the task cannot be processed as planned. The control center will work out a solution in consultation with all those responsible and reschedule (start time) this task. It must also be agreed whether successor tasks may still be initiated or whether the entire dependency chain is suspended.

Tools

The question of a suitable tool that provides the best possible support for the cutover project should be addressed and answered early in the project phase. Nevertheless, a decision in favor of a tool can still be changed at a later stage if, for example, additional requirements arise due to a three-digit number of tasks being exceeded.

The tools still most commonly found in practice are Microsoft Excel and Microsoft Project. These are usually enhanced with numerous macros to better meet the requirements of a cutover planning and control. In addition, there are professional cutover tools on the market that specialize in the requirements of a cutover. This includes our tool from LEXMAIR Solutions with the name CutoverManager.

Generally speaking, the selected tool should provide optimum support during cutover and integrate as well as possible into the infrastructure. Consequently, the project-specific requirements should be determined in detail and suitable tools evaluated. Subsequently, the best tool should be selected for its individual requirements.

Success factors

There are various challenges and problems that ideally, you do not have to have experienced yourself. From our experience, we can list the following success factors that contribute significantly to a successful cutover:

• Decentralized cutover planning and information provision
• Early ...
  • Elicitation and consolidation of all tasks, with their durations and dependencies
  • Presentation of a high-level phase plan to (top-level) management
  • Communication with HR and works councils
  • Planning and coordination of dress rehearsals
• Creation of transparency
  • Cutover plan can be viewed by all project participants at any time
  • Ongoing communication and coordination with management
• Change tracking
  • Revision security
  • Analysis of planning problems/errors
• Execution of at least 2 dress rehearsals
• Use of a professional cutover tool

Summary

The sheer complexity of a cutover is impressive in itself. Nevertheless, these projects are manageable due to the process model described for cutover projects and thus definitely have their right to exist. As a conclusion, therefore, it can be said that a cutover represents the supreme discipline of IT projects. Finally, I would like to encourage everyone who is about to start a cutover project to accept the challenge. The feeling of having successfully completed the cutover after many months of planning is overwhelming and remains unforgettable.

Recommended content

• Cutover Management
• Cutover: Successful planning and controlling with the CutoverManager
• The Loser at the End: Cutover software as success factor