Project Delivery Process D830

D830 - Approach to System Cutover

DEFINITION

Define, plan, agree, prepare and conduct cutover and handover tasks to move live processing onto the new system.

SUMMARY

An analysis should be made of the logistical requirements for changing over to the new systems.  Note that this does not include support and organisational issues - these are covered in processes D860 and D870.

Detailed tasks and their timings must be considered and agreed.  It is normally necessary to allow for:

• freezing the live data,
• converting old data to new,
• loading new information,
• running validation reports
• validating and signing off the starting data and
• re-opening the system.

With integrated applications, timings can become more critical as different systems have different cycles and cut off requirements.  The plans should include responsibilities and effort.

It may be appropriate to consider phased approaches or the use of an initial pilot.  Plans should include an evaluation of the fallback options should the new system unexpectedly fail.

The approach should be defined and agreed.  It will normally be documented in an Implementation Paper (or Brief Implementation Paper) - System Handover Plan.  The agreed approach and detailed tasks will subsequently be prepared and conducted

PATH PLANNING GUIDANCE

Normal Practice

DEPENDENCIES

Prerequisites (Finish-Start):

• Design of overall technical architecture
• Data Conversion design

Prerequisites (Finish-Finish):

• System Testing

Dependent procedures (Finish-Start):

• data load and live running

RECEIVABLES

• Data Conversion IP

DELIVERABLES

• Implementation Paper - System Handover Plan IP

TOOLS

• Examples: Processing Schedule
• Examples: System Change Letter

DETAILED DESCRIPTION OF TASKS

The System Handover Plan Implementation Paper:

The overall approach to cutover and handover tasks is considered in an environmental implementation paper - the system handover plan IP.  In a similar fashion to other implementation papers, it will review the requirements and options relating to cutover tasks, then state and justify a recommended approach.

Requirements

A system cutover is generally complex and usually requires a significant amount of work to be accomplished in a short period of time.  Additionally, although much of what will occur during the cutover can be planned for, it is impossible to anticipate all of the problems that will be encountered.  Project team members and users should be forewarned that long hours will probably be required, including evenings and weekends,  during the cutover and during initial support activities.  Because of these probable time requirements, it should be made clear to team members not schedule any other obligations during that time.

Requirements will relate to all aspects of the change over of the systems.  This implementation paper will address both the major needs and the detailed requirements.

Some aspects that may be relevant include:

• staffing / organisational change - can the cutover be performed in one go or should it be phased?
• timing - when is a good time to make the change, eg 1st January seems a convenient date for management reporting purposes but might mean that Christmas is canceled for the project team and end users.
• transfer of tested development system into live operational system - see processes D662, D664, D666 and D668
• starting up live support (user and technical) - see processes D850 and D870
• final runs on the old system (eg need to perform month end processes)
• timing requirements of other systems, particularly where they are interfaced to the old and/or new systems
• data extraction and conversion routines - processes, programs, timing, sequencing, staffing
• data load on the new system - processes, programs, timing, sequencing, staffing
• production of validation reports on new and old systems
• reconciliation of the starting data - techniques, timing, staffing
• cut off and close down dates and times (per business transaction type), ie when does each function on the old system become frozen or discontinued
• first scheduled runs on new system (per business transaction type)
• minimum business service levels during cutover (eg for how long can customer enquiries or cheque payments be unavailable)
• retention of access to old system for finalising work in progress, eg it may be easier to finish off current business on the old system rather than convert transactions half way through
• retention of old system for enquiries and reporting - it may useful and relatively simple to keep the old system turned on to assist with queries concerning business transacted before the changeover, or queries relating to the conversion process.
• contingency requirements to fall back to old system in the event of major difficulties
• final decommissioning of old systems - when is it safe to remove the system

Options

The various options available should be considered.  These will depend upon the details of the business solution and the technicalities of the system.  Major considerations should normally have been defined already in the Delivery Approach Definition (DAD) before the commencement of the Delivery Segment.  It is unlikely that there is enough flexibility to change the sequence of development once the implementation strategy has been put into action.  It may, nevertheless, be possible to change the rollout strategy provided that it does not impact upon completed design, development or testing work.

Some major choices might be as follow:

Option	Definition	Comments
“Big Bang” implementation	Existing systems are shut down and new systems opened up on a specific date.  All staff and all business operations change immediately to the new system.	Often the easiest to design and the hardest to do.  It is particularly strenuous if the timing coincides with a fiscal year end or calendar year end. Testing needs to be more extensive at each test stage, with special emphasis on the integration between the modules and aspects of control. Multiple workstations need to be identified and incorporated into the planning for the test script creation and subsequent testing activity. Not recommended for multi-site roll-out - logistically it would cause problems unless expertise is available in all locations to steer activities and guide users
Phased implementation	Parts of the user population or types of business transactions are converted at different times.	This can reduce the peak effort required and allow more time to be given to the users when they change over.  It does require more elapsed time and can complicate the conversion process and controls.  Consider how to handle work which involves both old and new systems. In some implementations, the sequence of implementation is typically finance driven, and therefore the accounting infrastructure modules (G/L, A/P, A/R, CO-CCA, AM) are the first to be targeted. Finance First: The business benefits may not be realised early - accounting groups could operate for longer terms without impacting/degrading profit margins The migration path to implement ‘front-end’ modules becomes easier to plan and achieve, since the accounting infrastructure is already defined and in place to allow the activation of the modules to simply slot into the framework. The downside is that if the financial infrastructure has not been designed properly, the design may need to be reworked to accommodate any elements of the front-end module which have not been catered for and which prove to be show-stoppers for the business continuity. Once the financial modules are established, the front-end modules may also be phased in according to business needs. Where multiple legacy feeder systems are being interfaced and bridged during implementation, tight controls need to be designed and incorporated into the plan. Depending on the number and type of these interfaces, the setting up and removal of the bridges can be very complex Testing becomes iterative, and will need to involve progressively more workstations and scripts to reflect the additional functionality being implemented. It is marginally easier to implement modules in the reverse order sequence of the business processes.
Business Segment / Section	If this method is selected, then the benefits of the big-bang approach can be combined with a smaller volume of data for large / complex business organisations	Problems may arise when new segments of the business are added to the installation if the new segment carries a greater complexity in processing than those already in operation. It is better in these circumstances to select the most complicated to be implemented first, on the assumption that the system will accommodate the less complex segments without change. However, it is important to bear all segment requirements in mind when designing the first. There are potentially more interfaces required when adopting this approach due to the fact that there will be combinations of data in multiple applications.  This can be difficult to reconcile, and makes the process of restart/recovery very complex. A clear picture of the entire business processes and their inter-relationships is needed before the design phase can begin.  Without this, there will invariably be problems.
Pilot Implementation	A small part of the overall organisation or business solution is implemented ahead of the main implementation.	This can allow time consuming problems to be identified and solved with a relatively small user base.  Effort can be concentrated on these users who will be more likely to make a success of the system and spread positive messages throughout the organisation.
Year end cutover	Transfer the systems at the organisation’s year end thus avoiding the need to convert yearly figures from old codification and definitions to new ones.  This is particularly common with accounting systems.	This makes sense logically, but usually means abnormally high effort from the staff at the time when they would already have been at their busiest.  For a real recipe for stress, try this when the organisation’s year end is 31st December.  Also note the heightened need for contingency plans - if the plan relies upon achieving the cutover on a specific day in the year, then any slippage could mean that an entire period or year might be lost!
Mid-period changeover	Changeover in the middle of accounting periods or reporting cycles.	This allows the team to choose the most convenient time and allows flexibility in the case of slippage.  Conversely it can make the conversion and cutover more complicated.
Convert historic data	Most systems require historic data for enquiries or management information.  It may be possible to convert this from the old system.	It may be difficult to convert the data, and there may be issues such as quality, comparability.  It will certainly require greater effort.
Parallel run cutover	A complete 100% parallel run of the old and new systems.  At some point the official system becomes the new system, but the old is still run for some time as a contingency and to build confidence.	This leads to a smooth changeover and removes pressure in the decision to go live.  At any time the change can be aborted and the old system could take over.  This is only possible where there is a possibility to operate both systems together with 100% of the workload.  Consider carefully the technical feasibility and the staffing requirements - particularly if it co‑incides with a busy period.

In addition to these major choices, there will be many technical and procedural options to consider.  These will depend largely upon the precise nature of the application, the business and the organisation.

Recommended approach

The requirements and options should be considered with the key user management, particularly those whose staff will be instrumental in the success of the cutover.  An approach should be agreed and documented.

Any impact on the design or development work should be considered and plans or details revised if required.  For example, a move towards a phased transition may require a different approach in the conversion programs.

Detail of approach - System Handover Plan

The detail of the approach may be laid out as a System Handover Plan.  This would show a detailed schedule of work to be performed and individual responsibilities.  It may be necessary to agree abnormal working patterns for staff involved.  For example, if there is an overnight conversion the control totals might be ready for checking at 4am!

It is normally necessary to build flexibility and contingency planning into the handover plan.  Where a complicated set of tasks must be conducted in a short period it is almost inevitable that some problems will occur.

The final details of the plan must be agreed and publicised.  All staff involved should be well aware of their responsibilities.

Carrying out the System Cutover

In accordance with the agreed plan the various cutover tasks will be carried out.  The project manager and key user managers will need to work closely together to ensure the smooth transition.

Preparatory tasks may start weeks before the cutover.  Typically, tasks will span the actual live date by a period of a few weeks.  For example, master data may be prepared before the changeover, but historic information might not be loaded until after the new system is live.  In some cases, the final converted data might not be available for months, for example where the definitive historic or brought forward information is not finalised until the annual accounts have been finalised and audited.

The changeover period can be a major logistical exercise.  Arrangements may need to be made for overtime working or the use of temporary staff to cope with the workload.

All relevant parts of the organisation need to understand the plans and the effects of the change.  Remember that changes can be felt away from the immediate end-users of the system.  For example, a change in the accounts codings could affect everyone drawing petty cash or claiming expenses.  Changes may also need to be communicated to outside bodies such as customers or the auditors (see Examples: System Change Letter).

At key moments, senior managers will need to approve the work.  For example, to agree the starting data, to approve the cutover and to approve the discontinuation of the old system.

The high-level diagram below shows an example of the way in which cutover tasks may be sequenced.