What is Cut-Over?

Cutover is the time period between the end of the old system and the beginning of the new system. It typically includes data conversion, testing, and training. During this time, the new system is put into place and is ready for use.

What is a Cut-Over in Software Development?

The cutover typically involves the following:

• Submission of change control requests for maintenance window approval
• Remediation: Removal of old multi-path software and installation of new multi-path software
• Installation of vendor-recommended host-based software and/or tools
• Re-cabling of servers (if migrating to new SAN)
• SAN zoning to new storage
• Post cutover verification of storage and application viability
• Re-establishment of replication
• Optional shredding of old data

What is Cut-Over Testing?

Business Continuity is the focus area when businesses are planning to go for a transformation of their existing software applications. They need to plan for a smooth transitioning from their legacy systems to the new ones. During this transition, there should not be any break in their Business As Usual operations. It may require some of the Work In Progress (WIP) items to be carried forward and resumed from the same state in the new system. Specific workflows to be migrated in "As is" form wherever possible. Some complex workflows may require to be closed with all the WIP items before data migration.

In a data migration, data fields from the databases in the legacy systems need to be mapped to the new databases in the target systems before the Extract, Transform and Load (ETL) phases. Usually there will be separate testing for data migration completeness & data integrity between source and target systems.

After successful completion of data migration testing & data integrity testing, a functional testing will be performed to validate that the system behaves in the expected manner. Usually functional testing with migrated data performed after the majority of system functions became stable after a few rounds of testing with simulated test data.

While we plan for a functional testing with migrated data, we tend to miss the intricacies related to Cut-Over, broadly indicating the continuity of business between the time periods for transition from one system to another. So adding a few test scenarios related to these WIP transactions is essential. This testing will help us to get ready for the big day of Go-Live and identify the gaps in preparation to Go-Live. 

These scenarios may vary based on the scope of migration as well. For example in a Core Banking Transformation, it can be decided that only Customers and accounts will be moved with related transactions for a limited period. Or only specific customers & accounts related to specific products are moved to the new system if the bank decides to go live in a phased manner. In most of the cases, legacy systems and new systems will run in parallel for a certain period, to eliminate all the initial issues. So the scope of data migration will be the basis for the specific test scenarios.

Again to explain this concept with some precise example, we will look in to the following scenarios in a Core Banking Transformation 

1. What will happen to Debit Card / Credit Card POS (Point of Sale) transactions done during the migration period?

2. If the migration is happening between the months, how the monthly account statements will be generated using the transaction details from old system & new system? 

3. If the ATM transactions are allowed during the migration period, how will they be processed in the new system?

4. Cheque clearance for those lodged for collection in the legacy system

5. Continuing the life cycles of things like cheque book requests, credit card / loan /account opening applications which are in various stages of the workflow.

6. How to handle Teller Till balances on the day before the migration?

7. Interest accrual & payment based on the daily balance or average balance at end of month or quarter based on the details from both the systems.

8. GL balancing after freezing transactions at the legacy system and GL balancing in the new system before the start of business in the new system.

9. Stop Payment of cheques set up in the legacy system to be validated in the new system. Standing Instructions set up in the legacy system to be validated in the new system. Particularly for those set up for the first day.

10. Documents / Files / Signatures related to Customers / Loans are to be validated in the new system.

11. Validating the routines and calculations involved in Beginning of Day (BOD) and End of Day (EOD) batch jobs between the legacy & new systems. Any mismatch or omissions in these might cause financial impact.

 12. Various transactions done through different channels / surround systems during the migration cut off to be validated in the new system.

Many of these scenarios may or may not be covered in your regular test pack. When we closely look at the data migration strategy, we will come up with many questions on how to handle these business continuity without a bumpy ride. The missing scenarios to be added to the test pack before testing with migrated data.

A detailed understanding on system framework, General Ledger structure, Batch Job routines in both Legacy & new systems is key to handle this Cut-off period effectively. Multiple sessions of brainstorming between various stakeholders including business, technology, development & testing teams is required to come up with the preparatory work to handle this big day of transformation. All the examples given above are from Banking, but readers can get a fair amount of insights related to their domains by comparing these examples. Nomenclature for this activity may be different at different domains and geographies. 

It would be great to see any feedback, comments & first-hand experience related to Cut-Off testing from readers of this post.

Sources:

• What is Cut-Over Testing?
• Data Migration – The Cut-Over