What is Data Migration?

Migration Testing is a verification process of migration of the legacy system to the new system with minimal disruption/downtime. Ensure the data integrity, no loss of data, all the functional and non-functional aspects of the application are met post-migration.

Why Data Migration?

Below are the 3 main reasons where we go for Data Migration

• System consolidation: Whenever there is reorganization process or memory consolidation process is required to have more permanent form of storage, we need Data Migration.
• Obsolete technology: Whenever system hardware, software, technology, services, or practices that are no longer used, even if they are in working condition becomes outdated, we need Data Migration.
• Optimization: Whenever clients interested in the optimization of the business meaning action of making the best or most effective use of a latest trend of technology in their business, we need Data Migration.

Testing Cycles Involved

During Data Migration, Testing Team should perform testing before and after the migration. Below are the phases of testing during data migration process:

1. Pre-Migration Testing
2. Migration Testing
3. Post Migration Testing
4. Backward Compatibility
5. Rollback Testing

It is essential to do a thorough study of the old and the new system for test team and then accordingly plan, design the test scenarios and test cases which needs to be covered as part of above the phases of testing.

When we say ‘thorough study’ means it is essential for any tester to clearly understand the below points.

1. The changes happening as a part of the new system (server, front end, DB, data flow, functionality etc.,)
2. How the migration happens, step by step changes happening in the backend of the system and the scripts responsible for these changes.

Testing Strategy for Data Migration

To minimize the errors and risks that occur as a result of migration and to perform the migration testing effectively, we need to design the test strategy for migration. This Strategy includes a set of activities and are as follows:

• 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, possible errors analysis: Current business should not get clog after migration and hence we need to carry out ‘Business Risk Analysis’ meetings involving the right stakeholders.
• Migration scope analysis and identification: Analyze the clear scope of the migration test as when and what needs to be tested.
• Identify the appropriate Tool for Migration: 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.
• Migration Test Specification Document and review: Prepare Migration Test Specification document which clearly describes the test approach, areas of testing, testing methods (automated, manual), testing methodology (black box, white box), Number of cycles of testing, schedule of testing, approach of creating data etc.
• Production launch of the migrated system: Analyze and document the checklist [to-do list] for production migration and publish it well in advance to avoid the unnecessary impediments.

Phases of Migration

Pre-Migration Testing

Below is the list of actions that are taken up during this phase:

• Set a clear scope of the data – what data must be included, what data must 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.
• Lower-level mapping – If the new application has the field that is mandatory in it, and but it is not the case in legacy, and then ensure that the legacy does not have that field as null.
• Study the new application’s data E2E clearly – field names, types, minimum and maximum values, length, mandatory fields, field level validations etc.,
• Several lists [in case of SharePoint application/tables [in case of web applications] in the legacy system are to be noted down and if any lists/tables are removed and added post migration needs to be verified.
• Study the Data flow, Data rendering and it should be highly secured and should not broke.
• Prepare test scenarios and test cases for 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 to ensure no loss of data.

Migration Testing

Generally, Migration activity phase includes:

• Actual Migration of the application
• Hardware, software configurations, servers are all modified as per the new system on which the legacy is being migrated
• Data leaks, security checks are performed strictly.
• Connectivity between all the components of application is checked
• Backend testing by conducting white box testing.
• Once the Migration activity 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, front end is communicating with the back end successfully.
• There are possibilities that the software supports multiple different platforms. In such case, Migration needs to be verified on each of these platforms separately. Nothing but Cross browser testing need to be done.
• 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

Below is the list of actions that are taken up during this phase:

• Check whether all the data in the legacy is migrated to the new application within the downtime that was planned.
• Data migrated from the legacy to 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’s database.
• Test the migrated data against the new application. Here cover a maximum number of possible cases. To ensure 100% coverage with respect to data migration verification, use the automated testing tool.
• Check for database security. 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 on the legacy
• Updating legacy application’s data through the new application should be supported. Once updated in the new application, it should not reflect 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 group, users from different region etc.,)
• Performance testing is important to ensure that migration to new system/software has not degraded the performance of the 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 functional test cases and other possible test cases so that the testing time can be reduced, and the results would be available quickly.

Backward Compatibility Testing:

• Whether the new system supports the functionality supported in earlier 2 versions along with the new one.
• The system can be migrated successfully from the earlier 2 versions without any hassles.

Rollback Testing                                                

• In case of any issues while carrying out the migration or if there is a migration failure at any point of time during migration, then it should be possible for the system to roll back to the legacy system and resume its function quickly without impacting the users and the functionality supported earlier.

Challenges in Data Migration Testing

• Data Quality: Factors like assumptions, data conversions after migrations, poor data analysis, etc. lead to poor data quality. In such cases, data quality must be improved to meet business standards.
• Data Mismatch: Data migrated from the legacy to the new application may be found mismatching due to the change in data type, format of data stored, etc., which results in huge efforts to modify or redefine, hence, better to take necessary steps to avoid data mismatch.
• Data Loss: Data might be lost while migrating from the legacy to the new/upgraded application. This will result in huge data loss and should have to be retrieved either from the backup database or audit logs if captured correctly.
• Data Volume: Huge Data that requires a lot of time to migrate within the downtime window of the migration activity. Hence teams need to study the data in the live system very carefully and should come up with the typical analysis and sampling of the data. Automation is the solution for huge data migration.

Disadvantages of Data Migration

• Cost: Each level of the migration process directly affects the cost it could be due to wrong planning, data analysis, or poor business strategies which results in high operational costs and deviation from the purpose of business. Hence, it’s important to keep the process execution perfect.
• Time: Time plays a great significance in data migration because each level of migration has its own impact on time such as Total time for Migration, Downtime of the applications, Time spent to migrate the records, and Time spent for rollback.

Importance of Delta Migration before production go-live

When migrating data, some of our customers continue using their source platform until all the data is available in the new platform. In this case, the respective support team continues receiving and resolving issues in the source platform. However, new, and updated data don’t get automatically moved to the target platform if the migration is already running. Obviously, our customers need these newest updates on the target platform. That’s why we offer such a thing as Delta migration.

Focus on Business Goals with Data Migration

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. So, plan the migration project according to your business objectives. It’s exciting to pick out new software and start learning a new system, but if the software doesn’t support business objectives and the migration doesn’t move forward with a minimal process disruption, the results can be disastrous. Overall, I can say it carry the exponential growth.