Most people can’t even think about it, much less "say it". The horror of it is just too much to endure. The chaos, the confusion, the panic and the disappointment are all distressing. If you have ever gone through it, you hope that you never ever have to go through the anguish of it all again. And then it happens. You need a new computer system and that unspeakable word creeps back into your vocabulary. Unwillingly, you ask the prospective vendor, "Can you convert my data?"

What is it that makes conversions so dreadful? Are they always bad? You know you need to do it, but it seems like it is more trouble than it’s worth. It’s such a mysterious process that it appears like a bunch of black magic is used to get the data over. When it comes over it’s all in the wrong places and pieces are missing. Is there anything that can be done to prevent this from happening? Is there such a thing as a smooth conversion?

There are many questions when it comes to converting data. The most important question is, "what format is the data in?" Everything that happens next depends on this answer. Many business owners can’t answer this question because it is a relatively technical and complicated question. Especially if the system is older, the database structure and type is often unknown. On older systems, this information often was not disclosed because there really was no reason for a user to know. In the past, data was housed in a file system and only the software vendor had access and/or tools to work with the raw database. Data storage was proprietary to the hardware that was being used. If you used Data General, you used RDOS & AOS and Business Basic or Cobol. If you used DEC equipment, it was likely that you used PICK & PICK/BASIC. You get the idea. Bottom-line, if your system is very old, it may be difficult to get at the data.

Once the format is determined, it’s usually up to the new software vendor to figure out if they can work with it. More than likely, your current vendor will offer very little help if any. That being said, in order for your new vendor to determine if the data can be converted, you need to be able to provide a copy of the data. There are many ways to do this and usually you will need some type of technical help in order to provide the data in some readable format. Once the new vendor receives the data and is able to work with it (read the data off of the media you provided), then the data must be analyzed.

Files come in different formats. You have something called "flat files", which are basically strings of data stored on disk. You also have what is called a "database". Some common databases are ACCESS, SQL Server, FoxPro, dBase, etc. Databases contain many tables (kind of a big filing cabinet with many different files). Databases differ from flat files because flat files are individual files acting independently. A database houses many different files all in one cabinet so to speak. The more popular older files and databases can be read with special tools and/or imported into newer databases that are easier to work with. Your new software vendor more than likely would use such a tool in order to: 1) determine what kind of database you have and 2) to read & convert the data into a more workable format. If you have a newer database, the vendor will probably just analyze it in its native format. This is only the beginning.

Once the data can be seen, the hope is that titles transferred with the data. Without titles, it is a guessing game to determine what the data represents. Some items are simple to determine such as name, address, etc. However, when it comes to codes or free-form fields, it is difficult to tell what the data is or where is should go. Even when titles are transferred with the data, the titles may be obscure enough so that it is impossible to tell what the data represents. For example, one might run across the title of "Flag" with data that says "Y". One would think that the "Y" represents "yes" but what does a "yes" flag mean? Yet, when one runs across a title of "MON" with data that says "Y" on an applicant, one might "guess" that this represents they are available to work or interview on a Monday. But there is no full-proof way of knowing if this is correct. The titles that the client sees on the screen usually do not match the actual titles in the database.

The conversion expert must go through every bit of data matching titles (if there are titles) to data and mapping the data to its new home. For example, the applicant file may have 100 fields of data. Each of those fields must be analyzed and it must be determined what the field represents. Then it must be decided where that data will go in the new database. Sometimes fields exist in the old system but do not exist in the new system. More common are free-form fields in the old database that are coded fields in the new. To solve this issue, the client can provide a spreadsheet which maps the old information to the new code. If fields are too free-form that they can’t be mapped, the only option is to throw the data into notes. This in itself can cause an issue if you do a lot of this because the notes will look messy and be difficult to read. Sometimes that’s a choice that is made because the data is valuable and the client doesn’t want to lose it. This whole process is very tedious, requires some help from the client and does not always fit into a neat package. The good news is that if data can be read, it can be converted.

A data conversion document should be created by the vendor that depicts every file and every field of data that will be converted, and where that data will be converted to. The client should read the document thoroughly so that there is a firm understanding of what will convert and where it will go. Never assume that something is going to be converted and that you will see it exactly where you thought it would go. That is why a document is extremely helpful. Vendors will not be able to tell by looking at the data what data is most important to you. Certain things are assumed, but often clients use fields in different ways or in a special way that is unique to their organization. This is why it is important that the client and the vendor partner in order to solve any data conversion issues that are brought to the surface before the actual conversion. Most conversion dissatisfaction occurs because the client expectation did not match with the vendor’s expectation. When everything is outlined clearly on paper, the nebulous factor which contributes to so many conversion disasters is eliminated.

A data conversion does not have to be a nightmare. I had many clients tell me that they thought it was going to be terrible, but were pleasantly surprised and relieved. It’s owed to the diligence of the client and the vendor. The vendor must take the time to analyze the data, ask questions and write up the document. The customer must take the time to read the data conversion document, recommend any changes needed and then approve the final data conversion document that will be put into production. It’s important to get it right before the conversion. After massive data is converted, small corrections can be made, but modifying huge portions of the data conversion will cause the stress and disappointment that people often associate with data conversions. It the homework is done, the happiness derived from a smooth data conversion can be realized by all.