All too often in an enterprise system implementation, we see companies get to client User Acceptance Testing (UAT) thinking everything is great and project sign off will be swift and painless…only to realize they have additional days, weeks or even months of work left to complete the project because of the state of the data. And, likely there is little or no budget left for data load revisions and the supporting client services that are needed at this stage in the project. So, why does this happen?

It is easy to blame the client for changing their mind or failing to provide interim feedback, the conversion programmer for failing to understand what was needed, the business analyst for failing to communicate clearly with the conversion programmer, or the project manager for failing to allocate enough time and money for the UAT re-work cycle. When these situations arise, there is always more than enough blame to go around! Some of this blame may be justified, but, more often than not, the real culprit is data conversion QA…or lack thereof.

Detect problems with your conversion early when they are the least cost to correct

Detect problems with your conversion early when they are the least costly to correct

The Value of a Comprehensive Data Conversion QA Plan

Many of those “surprise” data load revisions that so often surface during UAT can actually be found well before UAT begins. Further, the costly rework that ensues can be avoided if there is a quality assurance plan for the data conversion from the start of the project. We all know that the software needs testing in an enterprise system implementation project and have resources dedicated for that. However, when it comes to the data conversion, we tend to focus our QA efforts on record counts and other simple metrics. While record counts are extremely important, they are not nearly enough to feel confident in the client’s ability to successfully use their legacy data in the new application. This is why so many data conversion problems always seem to surface during UAT – this is often the first time the client is exercising a full range of system processes using their own data.

Timing is Everything

Just like your software QA plan, your data conversion QA plan should be established during the planning phase of the project. It should have defined test cases and load validation reports that need to be executed with each data load iteration. These test cases should not be limited to SQL queries and reports. These also need to include use of select system processes with loaded client data as that is when the real problems become easy to see and fix. We really need to change our mindset to view data conversion QA as not just the confirmation that “x records moved from A to B”, but that the new system can successfully function using the loaded data.


As with software QA, you get maximum value from your development cycle capacity and QA plan if you follow the “early and often” principle. You want to start the conversion QA early and perform it often. This means you’ll want to break the conversion load work into components or subsets to allow for iterative testing and client feedback cycles. A conversion bug found while the developer still has the code for that area of the load fresh in their head takes so much less effort to correct than one found weeks or months later. No one wants to incur the inevitable time hit of the conversion developer needing to “get their head back into the code”.


While you’re following the early and often principle for your internal data load QA, don’t forget to engage your client in the same mindset. The sooner they start trying to work with their data in the new system and get used to providing regular feedback, the more issues you will flush out early when they are the least costly to correct.

Establish a data conversion QA plan upfront and set yourself up for a smooth sail through UAT!