Data conversion is one of the most critical factors in the successful implementation of an enterprise system and is often a key contributor to project delays and budget over-runs. We’ve even seen large projects fail completely because of data conversion struggles and resultant client dissatisfaction. Having great software is one thing, and is usually what gets you the sale, but, when you’re implementing enterprise systems, project success or failure is often all about the data. Clients can learn to live with a new process approach they may not like, but they can’t get their job done without their data in a usable state.

A common mistake in data conversion projects is underestimating the challenges you will face in moving client data from the legacy application to the new system. It is never just a simple “A to B” on these large scale projects. Often you are dealing with large, complex, unstructured legacy data and a new system that requires this data to be cleaned and transformed to be workable.
Another common mistake, and the focus of this article, is assigning all of the conversion work to one developer and relying solely on that developer for updates on the conversion status. Enterprise system conversions are complex business undertakings, not just technical engagements. Successfully getting the data from A to B within your project timeline more often takes a village, than a lone wolf. Even the best SQL programmer can struggle with an enterprise system conversion if they are trying to fly solo.

Delivering a successful conversion on time and on budget typically requires some level of involvement from the following resources:

  • Conversion Programmer: Obviously, you need someone to write the SQL for the conversion routines and execute the loads. Ideally, this person has a strong programming background and can leverage programming techniques outside of SQL when needed for some of the more complex areas of the load.
  • Technical Business Analyst (BA)/Subject Matter Expert (SME): This is the power partner for the Conversion Programmer. This dynamic duo can do amazing things in a relatively short amount of time, compared to what a conversion programmer can achieve on their own. The technical BA/SME has a strong understanding of both the new system’s data structures (conversion target tables) and how the end users will work with the system. This is who should be mapping the data from source to target and testing the output of the data conversion routines with each load iteration to provide quantitative data conversion status updates. They know the system functionality best and they know how legacy data needs to be transformed to work well in the new system.
  • System Developer: The conversion programmer and technical BA/SME will sometimes encounter conversion issues that require a greater technical understanding of the system than they possess, so they need access to a system developer to help them run these issues to ground and grow their organizational knowledge in the process.
  • Quality Assurance Analyst: The conversion programmer and technical BA/SME will sometimes require assistance from the QA team to investigate issues to determine if they are truly load issues or system functionality issues.
  • Project Manager: This role is critical for ensuring that everyone in the “data conversion village” knows that this is a team effort and what role they play.
  • Client: The client should not be regarded as a passive recipient of the converted data. They are a key participant and play a critical role in ensuring the success of the data conversion effort. They know the data structures of the legacy system (conversion source tables) and they know how they’ve used that system over the years (particularly, how they’ve entered their data and just how clean or not clean it is). The input of the client is instrumental in mapping the data correctly as well as testing the conversion routine output with each load iteration to flush out issues early on and ensure a smooth transition into UAT and, ultimately, Go Live.

We know what you’re thinking: how can I justify that resource spend for my conversion project? Our answer: how can you afford not to? And, don’t forget, just because you don’t plan resource capacity from all these areas in your project budget, doesn’t mean you won’t end up spending it. Worse yet, you are likely going to end up spending the extra after the client is disgruntled and the project is in trouble. Plan for the right mix of resources on your conversion project from the beginning and you’ll actually spend less, not more. Not to mention, your project is more likely to have a happy ending.

Not all resources in the “data conversion village” need to be fully dedicated to the conversion effort. For some of the resources outlined above, it will be a very small percentage of their time that goes to supporting the success of the conversion, but it’s an incredibly important percentage. The two busiest people in the “data conversion village” are the Technical BA/SME and the conversion programmer. They will need to be near full time dedicated, but that doesn’t mean your cost of the conversion is doubled. By coupling these two resources together, you are shortening the data conversion routine development cycle and likely reducing your overall cost. Engaging the village greatly improves your odds for a successful system implementation and a happy customer.
When your conversion team has players with all the right combination of skills and vested interest, enterprise system data conversions can be a beautiful thing!