What is Data Migration Testing

by Yulia Lomanova | August 11, 2021 7:32 am

Data migration is the process of moving data from one location to another, one format to another, or one application to another. Generally, this is the result of introducing a new system or location for the data. The business driver is usually an application migration or consolidation in which legacy systems are replaced or augmented by new applications that will share the same dataset. 

The migrations are often started as companies move from on-premises infrastructure and applications to cloud-based storage[1] and applications to optimize or transform their business. Hence, adequate testing is a high-priority effort to ensure data migration is successful. In this article, we are going to cover the particularities of quality engineering in the data migration process. 

How to plan data migration testing?

In terms of arrangements, data migration involves 3 basic steps: Extract data; Transform data; Load data. The migration itself outlines a 7-phase process:

• Premigration planning. Evaluate the data being moved for stability;
• Project initiation. Identify and brief key decision-makers;
• Landscape analysis. Establish a robust data quality rules management process and brief the business on the goals of the project, including shutting down legacy systems;
• Solution design. Determine what data to be moved, and the quality of that data before and after the relocation.
• Build & test. Code the migration logic and test the migration with a mirror of the production environment.
• Execute & validate. Demonstrate that the migration has complied with requirements and that the data moved is viable for business use.
• Decommission & monitor. Shut down and dispose of old systems.

This may appear to be an overwhelming amount of work, but not all these steps are needed for every migration. Each situation is unique, and each company approaches the task differently.

How to Design a Data Migration Test Strategy?

Given this complexity, precise testing should start well in advance of the actual data being migrated so that it gets the right level of awareness and resources. To ensure that the project gets the attention it needs, focus on the most provocative element of the migration – the fact that the legacy system will be turned off. A solid test strategy design[2] is a must! 

Therefore, testing strategy phases of the Migration test to be carried out at the QATestLab[3] can be classified as Pre-Migration Testing; Migration Testing; Post Migration Testing. 

[4]

Pre-Migration testing

This test phase is ignored or not considered in simpler applications. But when complex applications are to be migrated, the Pre-Migration activities are to be performed. These are the actions that are taken up during this phase:

• Set a clear scope of the data – what data has to be included, what data has to be excluded, which data needs transformations/conversions etc;
• Perform data mapping between legacy and the new application – for each type of data in the legacy application compare its relevant type in the new application and then map them – Higher level mapping;
• Study the new application’s data schema – field names, types, minimum and maximum values, length, mandatory fields, field-level validations, etc;
• Study the interfaces in the new application and their connections. Data flowing in the interface should be highly secured and adjusted;
• Prepare test cases, test scenarios, and use ones for new conditions in the new applications;
• Execute a set of test cases, with a set of users and keep the results, logs stored. The same needs to be verified after Migration happened to ensure that legacy data and functionality are intact;
• The count of the data and records should be noted down clearly, it needs to be verified after Migration to prove that no data has been lost.

Migration testing

Ideally, the migration activity begins with the data backed up on the tape, so that, at any time, the legacy system can be restored. All the scripts and steps must be documented correctly without any ambiguity. 

To note down the actual time taken for migration from the point of start of migration till successful restoration of the system is one of the test cases to be executed and hence the ‘Time taken to migrate the system’ needs to be recorded in the final test report which will be delivered as part of Migration test results and this information will be useful during the production launch. The downtime recorded in the test environment is extrapolated to calculate the approximate downtime in the live system. It is on the legacy system where the Migration activity will be carried out. 

During this testing, all the components of the environment will usually be brought down and removed from the network to carry out the Migration activities. Hence it is necessary to note the ‘Downtime’ required for the Migration test. Ideally, it will be the same as that of the Migration time. Generally, Migration activity defined in the ‘Migration Guide’ document includes:

• Actual Migration of the application;
• Firewalls, port, hosts, hardware, software configurations are all modified as per the new system on which the legacy is being migrated;
• Data leaks, security checks are performed;
• Connectivity between all the components of the application is checked;

It is advisable for the testers to verify the above in the backend of the system or by conducting white box testing. Once the Migration activity is completed, all the servers are brought up and basic tests related to verification of successful migration will be done, which ensures that all the end to end systems are appropriately connected and all the components are talking to each other, DB is up and running, the front end is communicating with the back end successfully. These tests need to be identified earlier and recorded in the Migration Test Specification document. There are possibilities that the software supports multiple different platforms. In such a case, Migration needs to be verified on each of these platforms separately. Verification of Migration scripts will be a part of the Migration test. 

Sometimes an individual migration script is also verified using ‘White box testing’ in a standalone testing environment. Hence, Migration testing will be a combination of both white box and Black box testing. Once this migration-related verification is done and corresponding tests are passed, the team can proceed further with the activity of Post-Migration testing.

Post-Migration testing

Once the application is migrated successfully, Post-Migration testing comes into the picture. Here end-to-end system testing is performed in the testing environment. Testers execute identified test cases, test scenarios, use cases with legacy data as well as a new set of data. In addition to these, there are specific items to be verified in the migrated environments which are listed below:

• Check whether all the data in the legacy is migrated to the new application within the downtime that was planned. To ensure this, compare the number of records between legacy and the new application for each table and views in the database;
• Check whether all the schema changes (fields and tables added or removed) as per the new system are updated;
• Data migrated from the legacy to the new application should retain its value and format unless it is not specified to do so. To ensure this, compare data values between legacy and new application databases;
• Test the migrated data against the new application. Cover here a maximum number of possible causes. To ensure 100% coverage with respect to data migration verification, use the automated testing[5] tool;
• Check for database security;
• Check for data integrity for all possible sample records;
• Check and ensure that the earlier supported functionality in the legacy system works as expected in the new system;
• Check the data flow within the application which covers most of the components;
• The interface between the components should be extensively tested, as the data should not be modified, lost, and corrupted when it is going through components. Integration test cases can be used to verify this;
• Check for legacy data’s redundancy. No legacy data should be duplicated itself during migration;
• Check for data mismatch cases like data type changed, storing format is changed, etc;
• All the field level checks in the legacy application should be covered in the new application as well;
• Any data addition in the new application should not reflect back on the legacy;
• Updating the legacy application’s data through the new application should be supported. Once updated in the new application, it should not reflect back on the legacy;
• Deleting the legacy application’s data in the new application should be supported. Once deleted in the new application, it should not delete data in legacy as well;
• Verify that the changes made to the legacy system support the new functionality delivered as a part of the new system;
• Verify the users from the legacy system can continue to use both the old functionality and new functionality, especially the ones where the changes are involved. Execute the test cases and the test results stored during the Pre-migration testing;
• Create new users on the system and carry out tests to ensure that functionality from the legacy as well as the new application, supports the newly created users and it works fine;
• Carry out functionality related tests with a variety of data samples (different age groups, users from different regions, etc.,);
• It is also required to verify if ‘Feature Flags’ are enabled for the new features and switching it on/off enables the features to turn on and off;
• Performance testing is important to ensure that migration to new systems/software has not degraded the performance of the system;
• It is also required to carry out Load and stress tests to ensure system stability;
• Verify that the software upgrade has not opened up any security vulnerabilities and hence carry out security testing, especially in the area where changes have been made to the system during migration;
• Usability is another aspect that is to be verified, wherein if GUI layout/front-end system has changed or any functionality has changed, what is the Ease of Use that the end-user is feeling as compared to the legacy system;

Since the scope of Post-Migration testing becomes very huge, it is ideal to segregate the important tests that need to be done first to qualify that Migration is successful and then to carry out the remaining later.

It is also advisable to automate the end-to-end[6] functional test cases and other possible test cases so that the testing time can be reduced and the results would be available quickly.

Post-Migration test cases writing tips

When the application is migrated, it does not mean that the test cases have to be written for the wholly new application. Test cases already designed for the legacy should still hold good for the new application. So, as far as possible use the old test cases and convert the legacy test cases to a new application’s cases wherever required.

If there is any feature change in the new application, then test cases related to the feature should be modified. With adding any new features to the new application, new test cases are to be designed for that particular feature.

When there is any feature drop in the new application, related legacy application’s test cases should not be considered for post-migration execution, and they should be marked as not valid and kept apart.

Test cases designed should always be reliable and consistent in terms of usage. Verification of Critical data should be covered in test cases so that it is not missed while executing.

When the design of the new application is different from that of the legacy (UI), then the UI-related test cases should be modified to adapt to the new design. The decision to either update or write new ones, in this case, can be taken by the tester based on the volume of change that happened.

Conclusion

Hence considering the complexity involved in carrying out data Migration Testing, keeping in mind that a small miss in any aspect of verification during testing will lead to the risk of failure of migration at the production, it is very important to carry out careful and thorough study & analysis of the system before and after migration. 

Plan and design the effective migration strategy with robust tools along with skilled and trained testers. As we know that Migration has a huge impact on the quality of the application, a fair amount of effort must be invested by the entire team[7] to verify the entire system in all aspects like functionality, performance, security, usability, availability, reliability, compatibility, etc., which in turn will ensure successful ‘Migration Testing’.

Related Posts:

• Software Development (Doesn’t) Need Independent QA[8]
• Is Your E-commerce Ready for Black Friday & Cyber Monday? Let’s Check![9]
• Quality Assurance for Renewable Energy Software: How to Do It Right?[10]

Source URL: https://blog.qatestlab.com/2021/08/11/what-is-data-migration-testing/

---