Data Conversion: Dos and Don’ts

As technology continues to evolve at a rapid rate, it is inevitable that you will be faced with at least one data conversion project during the course of your career. There are many reasons why your organization might face a data conversion project. Your current system may be outdated. Perhaps you are in need of enhanced capabilities that are not supported in your current system. For example, a previous box management system utilized by our office did not support a consistent format for data entry and did not require key information. As a result, retention calculation was not possible. Maybe a change has been mandated. Our office experienced this; we were informed that our antiquated records management system would no longer be supported and were given one year to find a new product. After recovering from the initial shock, we realized that we had been presented with an exciting opportunity to pursue an updated system, designed to meet current and projected operational needs! 

Things to Consider

There are numerous issues to consider when contemplating data conversion. Examples include:

  • Setting your budget. What are you willing to spend, and where is the money coming from?
  • Know your current system requirements and infrastructure. What equipment will be needed, and is that equipment compatible with existing hardware and software? 
  • Is the proposed solution able to accommodate future system enhancements?
  • Is customer support and training available post-conversion, and for how long?
  • Can the proposed solution be implemented within an acceptable time frame? 

Where to Start 

The key to any successful project is selecting an awesome team. Include someone from your IT department who understands your existing equipment and system configuration. Include your manager, supervisors, account representative, and training specialist. Consider including some of your power users, both internal and external, in the process. They can provide valuable insight regarding what your staff users and customers are looking for.  

Document how the current system works. It may be helpful to provide a system demonstration for the team. Clearly define your system needs, including anticipated future needs, in writing. Describe what functionality must be retained, and what improvements are needed. This will serve as your specifications document. Solicit input from all team members. Keep an open mind, and listen to all suggestions. Not all ideas can be implemented but everyone has something to contribute.

Establish your meeting format. Be sure to include a timeline. Develop a responsibilities matrix, which clearly states who is accountable for each project task, such as updating timelines and project specifications. 

What’s Next?

Your specifications are established, and preliminary meetings have concluded. Now it’s time to research available products and alternatives. Invite vendors to give demonstrations and arrange visits to other agencies to learn about their systems and processes. Select a product that meets your business needs. Keep in mind that some changes to your current business processes will likely be necessary. Exercise caution when determining where change is warranted. Remain open to altering your business processes when it is expedient to do so; avoid altering a process simply to fit a product. Ensure the selected product can be implemented within your timeline.      

The Process

A good working relationship with your entire project team is crucial. Communicate regularly, and be specific. It is imperative to ensure that your programmer and account representatives have a copy of your timeline and specifications document at their disposal and that they understand your system functionality needs to the fullest extent possible. Review the system demonstration and specifications, if needed, taking care to provide ample time for questions and answers. Plan sufficient time to develop clear and detailed test plans. 

Test Plans

Test plans define your project, state the objective and anticipated completion date, specify transactions to be tested, and provide a standardized format for performing the tests. A sample transaction test format is displayed below:

  • Transaction: State the function to be tested (Box Retrieval)
  • Test Case: Describe how the test should be performed (Enter a retrieval request for box #123)
  • Expected output: Describe the desired system response
  • Actual output: Describe the actual system response

The testing process ensures that desired transactions are accurately completed (positive transactions), and that illegal transactions are disallowed (negative transactions). A test plan should also include sections for testing reports, documenting problems that must be resolved before conversion, and a signature page for authorized representatives to sign, signaling their acceptance of the completed test plan. Plans for testing system security and barcode functionality also need to be developed. 

System modules should be tested separately; each module needs its own unique test plan. In a past conversion, our agency tested seven modules in addition to barcode and security components.  A sample process outline follows:

  • Perform test transactions
  • Document errors encountered where indicated in the test plan
  • Re-test the entire module until error-free
  • Obtain required signatures where indicated in the test plan to certify acceptance of the completed module
  • Repeat the process for all subsequent modules

Often, a previously tested module will exhibit problems after a subsequent module is brought into the mix. Accordingly, when testing a new module be sure to test all previously approved sections to ensure that all modules work correctly. Document issues within the current test plan. Do not sign off on the current module until all issues with previous modules have been corrected. 

While data conversion is certainly a collaborative endeavor, your department must take ownership of test plan development and system testing. 

After all, you are the experts regarding your core business processes and how your new system should function in accordance with those processes. You are ultimately responsible for ensuring the new system is accurate and adequate for business purposes. During a past conversion, our programmer stated that I did not need to re-test a module that had been sent back for correction because he completed the testing process and determined that the module was working accurately. I may have been born and raised in Southeastern Pennsylvania, but, when it comes to one of my test plans, I’m from Missouri! Don’t tell me it works, show me that it works. I ran through the test plan myself, and did, indeed, find an issue. The module was sent back to the programmer for another correction.       

Maintain a clear assignment schedule and update it regularly so the testing team knows the status of the project, as well as their own assignments, at all times. Make sure your testing protocol contains a clearly defined process for reporting issues and documenting required fixes.   

Finally, complete testing of barcode functionality and system security must be performed. This can be tested with each module or as a separate process after all modules have been completed. In our case, barcode functionality and security testing were completed for the entire system as our final step in the testing process.   

Test Plan Caveats

A test plan is an effective tool, but only if followed consistently by all users. During a past conversion process, I noticed that one particular function was not working, even though I had documented the problem on the test plan. As I investigated further, it became apparent that the programmer and I were interpreting the test plan in different ways.  In other words, I was speaking “apple” and the programmer was speaking “orange”. Once the disconnect was identified, we were able to work together to get the project back on track.

It is helpful to keep in mind that stress is normal during the testing process. In my opinion, if you have no stress during testing you are obviously overlooking something! Days are long, the work is intense, and the seemingly endless cycle of reprogramming and re-testing can be, quite frankly, demoralizing. Consider implementing a rotational job assignment schedule in order to provide some relief for your team. For example, if a team member is assigned to work on a test plan in the morning, rotate that person to a completely different, non-conversion-related assignment during the afternoon.


Parallel testing must be completed prior to go-live. Parallel testing is the process of working the old system (production) and the new system (test) simultaneously in order to verify that the results are the same in both systems.  Two teams of parallel testers are needed—one to enter transactions in test and one to enter transactions in production. Develop one set of transactions, designed to touch each area of system functionality. The same transactions must be entered in both the production system and the test system. You may want to invite power users from customer agencies to participate. Make sure participants are fully trained on the new system prior to parallel testing.


Ideally, all users should be fully trained prior to go-live. Remember, the old system will no longer be available after go-live, so users really need to know how to operate the brand new records management system from the first day.  Discuss and finalize your training plan. Will your format be in-person or virtual training? Advance arrangements for meeting rooms and adequate equipment will be needed if you are planning in-person, hands-on training.  Some product vendors may provide initial training for system users. If this is the case, you will need to work out the details with your vendor.  Determine who is responsible for creating training materials.  Your product vendor may have training materials available to your users. If not, you will need to create your own. Finally, discuss and finalize a plan for managing your ongoing training needs. Maintain and publish an updated training schedule regularly.  We are fortunate to have a department trainer, who is responsible for our ongoing training initiatives. We provide regularly-scheduled virtual training sessions. Documentation is online and can be viewed via our intranet site. 

Pre-Conversion Reports

Pre-conversion reports consist of a sample of all system reports. The reports are run at go-live, just prior to shutting down the old system. Work with your programmer to coordinate timing for your pre-conversion report generation. 

Post-Conversion Reports

Post-conversion reports consist of a sample of all system reports. They are the same reports run during pre-conversion. Post-conversion reports are run at go-live, just after bringing up the new system. Work with your programmer to coordinate timing for your post-conversion report generation. Assign teams to compare pre and post-conversion reports. The results should be identical.


This is the magical moment when you see all of your hard work coming together! Everything has been tested and should be working seamlessly. However, a thorough review of the process and reports must still be performed. Make sure the old system will be available after go-live in case a roll-back is necessary.

The Grand Finale

You’re almost finished! Verify that review and comparison has been completed for all pre-conversion and post-conversion reports. Document any problems and report them to your programmer immediately. Documentation should include a responsibilities matrix, detailing who is responsible for addressing each post-conversion issue reported, along with the timeline for resolution.   


Document how your new system works. Check with your vendor to see if they provide user training manuals. Ideally, manuals should include screenshots and step-by-step instructions. Include a table of contents to enable users to easily locate information. Be sure to include a contacts page so users know who to call or email for assistance. Provide screenshots and explanations for each report. 


Take time to congratulate yourself and your team members on a job well done! Everyone has worked very hard, and team recognition is certainly in order. We hosted a luncheon and handed out certificates of appreciation to our team members. The possibilities are endless. The important thing is to provide an opportunity for your team to come together to celebrate their outstanding accomplishment.   


(Visited 1,040 times, 1 visits today)

Sandra Tuller

Sandra has been a Pinellas County employee since June of 1999, and currently serves as Senior Manager of the Pinellas County Clerk of Court Records Management Department since June 2014. A native of southeastern Pennsylvania, Sandra earned her Bachelor of Science in Education from Northern Illinois University, DeKalb, Illinois. In addition, she holds a Records & Information Management Specialist Certificate from Chippewa Valley Technical College, Eau Claire, Wisconsin, and a Paralegal Studies Certificate from Rollins College, Winter Park, Florida. Sandra became a CRM (Certified Records Manager) in October 2013 and graduated from the Florida Certified Public Manager (CPM) program in 2009. Sandra’s other professional credentials include Certified Paralegal (CP), Florida Registered Paralegal (FRP), and Florida Certified Records Manager (FCRM). She lives with her husband in Palm Harbor, Florida.