Data Migration Testing Checklists: Before, During, & After

Testing a migration before, during, and after you’ve moved the data is important to safeguard your project’s success. Most of the time, data testing relies on sampling. Sampling pulls a random subset of the data to test, debug, and retest until it meets the necessary requirements. This familiar approach is effective, but it assumes the repeatability of the testing and an acceptable level of error. So, what other testing approaches are there for data migration projects? What should be tested before, during, and after the migration to ensure data is meeting the requirements?

Pre-Migration Testing Checklist

For simple migrations, pre-migration testing may seem unnecessary, but most businesses customize and adapt their software solutions to their needs, so the migration process is rarely as simple as plugging one system’s core objects into another. Migrating complex applications requires some prep work, which includes the following:

• Compliance evaluation: A migration can significantly change the way the data is stored. Depending on the industry (medical/financial etc.), an evaluation of compliance rules is necessary to ensure no legal issues are caused by the migration process.
• Identify current bottlenecks/data management issues: It is quite common to have issues with the way the current data is stored, which might be a result of legacy technology that couldn’t handle certain scenarios. There can be a tendency to just bring forward the old data formats because that’s how the data always worked, but it’s a short-term band-aid that can stifle your progress in the new system. Plus, it’s also quite possible that some of the data migration steps can be eliminated as a result of a better data structure in the new system.
• Setting the scope: Make sure the team understands the scope of the data you’re trying to migrate. How much data will be included? How much will be excluded? Which data will need transformations/conversions to fit the parameters of the new system?
• Mapping from source to destination: Once scope is established, you must perform higher level data mapping between the source (aka legacy) application and your new application, considering the types of data migrating and the format of that data.
• Studying the schemas and interfaces: How does the new application name fields? Which fields are mandatory? What kind of field level validations are in place? How will the data render in the interface and what do you need to set up to secure it?
• Preparing test cases: Prepare your test cases and scenarios and then execute them with a defined set of users. Keep the results in a log so you can go back after migrating and verify the data that transferred is still accurate.
• Keeping a count: Keep notes on the data and its records before you start migrating so you can check against that information after the migration and ensure no data was lost in the transfer.
• MOST IMPORTANTLY! Clean the data: Plan a data cleaning strategy and execute it! No amount of testing is a substitute for having clean, verified data. Every system inevitably gets junked up with some outdated, invalid, or incomplete data over time. Without understanding the potential error types, interrogating the system to find those errors, and fixing the data consistently across the system, your data migration project will essentially be rendered useless. Moving dirty data from one system to another won’t improve your analytics or help you build smarter business strategies. Initiate data cleaning before migrating and then continue to check record counts and seek out errors as you migrate.

Migration Testing Checklist

Migration testing is a combination of white box and black box testing procedures. White box testing is a structural test of the software in which the software developers already know the internal structure, design, and implementation of what’s being tested. It tests the logic of the software. Although it’s time consuming, it’s necessary, and it requires knowledge of the implementation and the programming for the migration.

Black box testing is a functional test usually performed by software testers. It is the behavior testing of the software. In this instance, the internal structure, design, and implementation of what’s being tested are not known to the testers. Black box testing is less time consuming than white box and does not require knowledge of the implementation or programming. As you undertake migration testing, be sure to check all the necessary aspects, which include:

• Conducting a formal design review: As you begin configuring the migration tool, review the specifications of the migration with your user community, IT team, and management. Are the data sets and queries accurately defined? Are mappings complete? Have you documented the number of source records? Were pre-migration data cleansing requirements met? What performance and testing requirements should be kept in mind moving forward? If there are any open issues resulting from this formal review, the team must define how they plan to close each issue so everything stays in sync with the specifications of the migration.
• Conducting a pilot group review: It may be worth processing a couple of smaller batches of data to provide a preview to key business users of how it will look in the new system. This can help catch issues earlier and can save a lot of time during the final import. This also helps build credibility with end users as their early feedback and involvement will improve their trust in the process and reduce friction, especially in the final stages of migration.
• Backing up the data: It’s best practices to create a complete backup of the source system data with all scripts and steps documented in case the legacy system must be restored.
• Test & document the time it takes to migrate: How long does it take from the start of the migration to the time the dataset is successfully restored? That information must be documented so it can be included in the final test report. Why? Because the downtime in the test environment will be used to approximate the downtime in a live system.
• Document the downtime: Ideally, the migration time and downtime are the same. Data migrated from the legacy system, firewalls/ports/software and hardware configurations modified to fit the new system, data security checks, and the connectivity of components are all part of the bigger migration process and should be verified with white box testing. All results of that white box testing should also be documented.
• Verify migration scripts: Once migration scripts are verified and their corresponding tests are passed, it’s time to move on to post-migration testing.

Post-Migration Testing Checklist

You migrated! You’re done! Just kidding…After the physical data migration is complete, more testing remains to be done:

• Black box test known data flows: Test use cases and user stories against the subset of data you defined in the pre-migration testing phase to make sure they line up. Build test scripts that list the precise details of data usage on data sheets or via the text of the test.
• Do Negative testing: Perform tests that attempt to violate the validation rules you set up in the migration. Try to bypass the mandatory data or drag-and-drop data where it’s not supposed to be to find potential defects.
• Security testing: Check to make sure the access to the data is restricted according to your specifications.
• Performance testing: How stable, scalable, quick, and responsive is the system under the given workload? Is it meeting the demands that you expected?
• Data usability testing: Are users able to utilize the data in the ways they need, or do they have to input the same data multiple times?

Follow these checklist items before, during, and after to produce a successful migration project that will add value to your business. Or skip the headache altogether with a professional migration from StarfishETL! Reach out to us at sales@starfishetl.com to start the conversation.