What needs to be tested during CMS Migration Project? How and Why?
Card Management System (CMS) Migration:
The Card Management system migration projects is one of the critical projects for any institutions or bank processors; as it involves the data which is extremely critical to banks and data migration is challenging in nature. Data migration is a prominent data-movement technique that is usually combined with other techniques.
The CMS migration includes the migration from legacy system to newer system, which includes data and other internal & external systems like Cards, Collections, Dispute, Statements, Embossing, PIN Mailer, HSM & keys, Payment Scheme and Authorizations etc.
What is CMS Migration Testing?
The CMS Migration Testing is a verification process of migration of the legacy CMS to the new CMS with minimal disruption/downtime, with data integrity and no loss of data (Data correctness), while ensuring that all the specified functional and non-functional aspects of the CMS are met post-migration.
CMS Migration testing includes
- Functional testing
- Functional regression
The regression testing is to perform testing with old data, new data or combination of the both, old features (unchanged features of CMS), and the new features of CMS, if any. The functional regression testing is to perform testing with newer data as per test cases defined by the testing team.
- Data Migration testing
- Dress rehearsal
The mock testing is to perform testing with migrated data to perform data validation, data sampling and data reconciliation. The dress rehearsal testing is critical activity for CMS migration projects. This includes the migration from legacy to newer CMS along with data migration, HSM & key migration, other internal & external systems.
- Non-Functional testing
- Performance testing
The Certification testing is to perform and validate the payment scheme (VISA & MasterCard) set of pre-defined test cases. The Performance testing is to determine how a system performs in terms of responsiveness and stability.
Designing the test strategy for migration include a set of activities to be performed and few aspects to be considered. This is to minimize the errors and risks that occur because of migration and to perform the migration testing effectively.
- Data sampling
- Data validation
- Data reconciliation
Critical Points for CMS migration:
Below are the critical points for CMS migration:
- Identify the functionality from legacy system to new system
- Prepare the network diagram
- Identify the list of new functionalities for newer system
- Approach for data migration
- Data mapping
- Data validation
- Data reconciliation
- Payment scheme, if any changes
- Embosser , if any changes
- Statement vendor, if any changes
- Interfaces (ESB / EAI API’s), if any changes
- Card Plastic, if any changes
- CMS end points (ICA)
Why CMS Migration Testing?
The CMS migration to a new system could be for various reasons, system consolidation, obsolete technology, optimization or any other reasons.
While the existing legacy system in use needs to be migrated to a new CMS, it is essential to ensure the below points:
- Any kind of disruption/inconvenience caused to the cardholders due to migration needs to be avoided/minimized.
Example: downtime, loss of data, transactions declines etc.
- Need to ensure if the cardholders can continue to use all the CMS features by causing minimal impact during migration.
Example: change in the functionality, removal of a particular functionality
In order to ensure a smooth migration of the CMS, it is essential to carry out Migration Testing.
Technically, it is also required to be executed for the below purposes:
- To ensure compatibility of the new/upgraded application with all possible hardware and software that the legacy application supports. In addition, new compatibility should be tested for new hardware, software platform as well.
- To ensure all the existing functionalities works as in the legacy application. There should be no change in the way how the application works when compared to the legacy one.
- The possibility of a large number of defects due to migration is very high. Many of the defects will usually be related to data and hence these defects need to be identified & fixed during testing.
- To ensure whether the System response time of the new/upgraded application is the same or less than what it takes to the legacy application.
- To ensure if the connection between servers, hardware, software etc., are all intact and do not break while testing. Data flow between different components should not break under any condition.
Migration testing life cycle
- Pre-Migration phase
Before migrating the data, set of testing activities are performed as a part of Pre-Migration test phase. The important activity is to create “migration strategy” document along with identified set of test scenarios, test plans and test cases.
- Migration Phase
Migration Strategy needs to be strictly followed to carry out the migration activity. Ideally, the migration activity begins with the data back up and conversion, so that, any time the legacy system can be restored.
This activity is extremely important and need to perform Mock runs for data sampling, data validation and data reconciliation with both legacy and newer CMS.
In addition, EOD validation need to be check with legacy and newer system to validate the accuracy of transaction amounts and statements.
Migration Test Summary Report
The test summary report should be produced after completing the migration testing and should cover the report on the summary of the various tests/scenarios carried out as part of various phases of migration with the result status (pass/fail) and the test logs.
Following activities need to be recorded during migration:
- Total time for CMS Migration
- Downtime of the applications
- Time spent to CMS migrate
- Time spent for rollback
In addition to the above information, any observations /recommendations can also be reported.
- Post-Migration Phase
During Post migration testing, perform out the functional testing with older and newer records in the CMS. In addition, data reconciliation and CMS end points with ESB middleware, Collections, Payment scheme’s and other internal system need to be checked. As this might have customer impact.