ERP Data Conversions 101

When it's time to find a new software vendor, one of the biggest decisions you will need to make is what to do with your current data. Conversions are consistently a Quadrant II Risk on projects as they are both critical to the success of the project and have a high likelihood of manifesting from risks into issues.

When I started my career in the Community Development domain there were still a lot of municipalities running their departments solely on paper. In these cases, many of them performed some basic imports of parcels, addresses, and owner names, but started from scratch for everything else. There was just no data to convert. Some of these customers back-entered data from the current year (or further) to allow them to manage existing projects within their new software. In other cases, municipalities had an existing system but either did not want to budget a conversion of the data or they deemed their existing data as being too poor of quality to bring forward.

As time went on, data conversions became increasingly common requirements on RFP's.

Once you select a vendor, their conversion process will typically be defined to some extent in their Statement of Work. Some vendors may instead provide a separate document such as a Conversion Plan which outlines their process or they may even describe the process verbally. I've found that having the process documented in some manner is always a best practice. This makes it clear to all stakeholders what will be converted, how it will be done, and what the roles and responsibilities of the process are.

First, let's define the two main types of conversions you may see:

Standard vs Custom