What is Migration Testing?
Migration Testing is a verification process of migration of the legacy system to the new system with minimal disruption/downtime, with data integrity and no loss of data, while ensuring that all the specified functional and non-functional aspects of the application are met post-migration.
Migration Testing verifies the process of migrating the data from the legacy, or current system, to the new target system. It does so with limited downtime and no loss of data or issues with data integrity. In addition, it does so while making sure functional and non-functional requirements / expectations of the application, are met post-migration.
Why Migration Test?
As we know, the application migration to a new system could be for various reasons, system consolidation, obsolete technology, optimisation, or any other reasons.
Hence while the System in Use needs to be migrated to a new system, it is essential to ensure the below points:
Any kind of disruption/inconvenience caused to the user due to migration needs to be avoided or minimised like downtime, loss of data.
Need to ensure if the user can continue to use all the features of the application.
To ensure compatibility of the new/upgraded application with the hardware and software that the legacy application supports.
To ensure the existing functionalities works as in the legacy application seamlessly.
Critical Defects related to the data and data type need to be identified & fixed during testing.
To ensure no performance degradation post migration.
To ensure if the connection between servers, hardware, software and therefore the Data flow between different components remains intact.
Hence in order to ensure a smooth migration by eliminating the above defects, it is essential to carry out in-depth Migration Testing.
Importance of Data Migration Testing
There are some challenges that could arise during data migration testing, which is precisely why the testing itself is so crucial. Some of these challenges include:
Testing the mapping or path of data.
Unintended data modifications in the legacy system and in the data structures mapping.
By uncovering and resolving these issues during the testing phase can be priceless and a success.
Test Phases in Migration Testing
The different phases of Migration test need to be considered:
1. Pre-Migration Testing
2. Data Cleansing
3. Post Migration Testing
Phase 1 : Pre-Migration testing
Before any migration has taken place, the following testing actions should take place:
Ensure that the scope of the data is clearly understood what data has to be included, what data has to be excluded, which data needs.
Ensure that the destination as well as the load process is understood.
Perform data mapping between legacy and the new application.
Ensure that the data scheme is known including mandatory fields, field names, field types, data types etc. for both the original data source and the destination system.
Understand the data cleansing requirements.
Understand any interfacing with other systems or secondary suppliers of data into the system.
Tables in the legacy system are to be noted down and if any tables are dropped and added post migration needs to be verified.
Records in each table, views should be noted in the legacy application.
Prepare test cases, test scenarios, and use cases for new conditions in the new applications.
Execute a set of test cases, scenarios with a set of users and keep the results, logs stored. The same needs to be verified after Migration to ensure that legacy data and functionality are intact.
Count of the data and records should be noted down clearly, it needs to be verified after Migration for no loss of data.
Ensure the mapping to user interface is correct.
Ensure the mapping to business process is correct.
Test tool configuration and script generation using field details.
Identify data subset (sampling) details for testing.
Ensure all business cases, user stories, or use cases are understood.
Phase 2 : Data Cleansing
It is vitally important that data cleansing is performed on a system that houses and maintains data. The following data cleansing tasks should be planned:
Understand the error types: these may include blank fields, too-long data lengths, or bad characters.
Identify method of checking the data: either interrogation through database using SQL commands or the use of data migration tools.
Understand the data dependencies i.e. if changing the data in one table impacts the data in another linked table.
Fix the data issues.
Verify the count of the data.
Phase 3 : Post-Migration Testing
Following the migration of the application is migrated successfully, Post-Migration testing comes into the picture.
In addition to testing the known business flows, the testers should carry out the following testing, including negative testing approaches, which primarily ensure that data cleansing is being carried out at run time within the system:
Check whether all the data in the legacy is migrated to the new application within the downtime that was planned. Example compare the number of records between legacy and the new application.
Check whether all the schema changes as per the new system are updated.
Data migrated from the legacy to new application should retain its value and format.
Test the migrated data type including business data types and technical data types.
Check the data flow within the application
Check and verify the earlier supported functionality
Check for legacy data’s redundancy. No legacy data should be duplicated itself during migration
Input bad data: attempt to violate the validation rules including the use of boundary value analysis, equivalence partitioning and error guessing.
Bypass mandatory data – attempt to proceed further without filin the mandatory data fields.
Checking data locks: Where data is being written, it should not be possible for multiple users to access the same new record within the database.
Check for database security and data integrity.
Create new users on the system and carry out tests to ensure that functionality is accessible to the newly created user.
Data segregation – Deleting the data in the new application, should not delete data in legacy as well. Similarly, any data addition in the new application should not reflect back on the legacy system.
Performance Testing: To ensure that migration has not degraded the performance of the system and Data is accessible in accordance to the required performance.
Security Testing: Access to the data should be restricted appropriately.
Usability: Verify the ease of Use of the functionalities migrated for the end user
Backward Compatibility Testing: Migration of the system also calls for the testers to verify the ‘Backward Compatibility’, wherein the new system introduced is compatible with the old system.
Rollback Testing – Migration failure test scenarios need to be designed as part of negative testing and rollback mechanism needs to be tested in case of any issues while carrying out the migration or if there is a migration failure at any point of time during migration.
Data Migration Testing Strategy
Designing the test strategy for migration include a set of activities to be performed and few aspects to be considered. This is to minimise the errors and risks that occur as a result of migration and to perform the migration testing effectively.
Activities in this Testing:
Specialized team formation: Form the testing team with the members having the required knowledge & experience and provide training related to the system that is being migrated.
Business risk analysis: Current business should not be hampered after migration and hence carry out ‘Business Risk Analysis’ meetings involving the right stakeholders and identify the risks and the implementable mitigation. The testing should include scenarios to uncover those risks and verify if proper mitigation have been implemented.
Possible errors analysis: Conduct ‘Possible Error Analysis’ using appropriate ‘Error Guessing Approaches’ and then design tests around these errors to unearth them during testing.
Migration scope analysis and identification: Analyse the clear scope of the migration test as when and what needs to be tested.
Identify the appropriate Tool for Migration: While defining the strategy of this testing, automated or manual, identify the tools that are going to be used. e.g. Automated tool to compare source and destination data.
Identify the appropriate Test Environment for Migration: Identify separate environments for Pre and Post Migration environments to carry out any verification that is required as part of testing. Understand and document the technical aspects of the Legacy and New system of Migration, to ensure that the test environment is set up as per that.
Migration Test Specification Document and review: Prepare Migration Test Specification document which clearly describes the test approach, areas of testing, testing methods i.e. automated, manual, testing methodology Number of cycles of testing, schedule of testing, approach of creating data and using live data , test environment specification, testers qualification etc. and run a review session with the stakeholders.
Production launch of the migrated system: Analyse and document the to-do list for production migration and publish it well in advance.
Challenges in Data Migration Testing
Challenges faced in this testing are mainly with data. Below are few in the list:
Data Quality: We may find that the data used in the legacy application is of poor quality in the upgraded application. In such cases, data quality has to be improved to meet business standards. Some of the ways to resolve this may be execute some mock migrations and pilot migrations before the final migration. It may give some errors which we never expected during any of the previous phases.
Truncation and precision of data: In this case, the data to be migrated is partially moved to the target system. It can be challenging because of the additional padded spaces or a smaller number of bytes in the source data.
Data type and Data Mismatch: Data and Data type migrated from the legacy to the upgraded application may mismatch in the new one. This may be due to the change in data type, format of data storage, the purpose for which the data is being used may be redefined. SO The data types must be mapped correctly.
Data Loss: Data might be lost while migrating from the legacy to the upgraded application. This may be with mandatory fields or non-mandatory fields. If the data lost is for non-mandatory fields, that is less risky as it can be updated again but if the mandatory field’s data is lost, then the record itself becomes void and it cannot be retracted. This might result in data loss and should have to be retrieved.
Null data translation: Null data should be translated to the Target as null itself and not as spaces or default values. The application can have some checks for null validation.
Data Volume: Huge Data that requires a lot of time to migrate within the downtime window of the migration activity.
Extra records:Duplicate records can come from different data sources. So, before loading the data to the target system, a filtering and transformation of the data needs to be done
Simulation of a real-time environment: Simulation of a real-time environment in the testing lab is another real challenge, as testers get into different kind of issues when they test the application / system with the the real data and the real system. So, data sampling, replication of real environment, identification of volume of data involved in migration is quite important while carrying out data Migration Testing.
Unclear / Missing requirements: There are instances where some requirements are missed due to various reasons including lack of communication with end users or subject matter experts. If it’s not addressed properly, it affects the data migration project hugely.
Extraneous / Duplicate records:Duplicate records can come from different data sources. So, before loading the data to the target system, a filtering and transformation of the data needs to be done in order to remove the duplicate records.