Subscribe to RSS Blog

---

Data migration - the hidden cost

Obtaining an accurate cost of a EAM/CMMS package is relatively easy. Ascertaining the cost of implementation is often not that difficult either. Want a real challenge? Try and discover the cost to migrate the data from your existing system to the new package.

Why is this such an issue for CMMS vendors?

There are a number of reasons why this step in the process is so fraught with difficulties, but they all reduce to the same root cause.

One thing we consistently see when examining a new client's legacy system is corrupt data. This is not surprising. Legacy data, by definition, means the system is overdue for replacement, and that almost invariably means that users have tried to fit the software to their changing needs.

What does this mean?

This means that fields may have data within them that does not conform to original or even expected business rules. For example, the legacy system may not have included a field for email address, so users entered this information into the unused second address field.

It may mean that the technical attributes of the data are not consistent. For example, commas may have been sprinkled throughout addresses or used to separate two phone numbers in a single phone number field. Depending on the format used to export the data (CSV and Excel being the two most common) the resulting data file may be very difficult to import consistently into the new application. The most common problem this produces is that data after the comma is considered to belong to the next field. Ensuring the meta-data is correct can be a time-consuming, and often, pointless task.

Consideration must be given to the accuracy and currency of the data itself. It is accurate? Are there duplicates? If so, which one is correct? What should be done if the first half of one record and the last half of its duplicate contain the current information?

There are may ways to reduce and simplify the issues I have raised here. Suffice to say that we have not come across any tool that handles them all fully. We even went to the effort to develop our own import/massage/de-dupe tool, and while its pretty good, it still does not cut the mustard when an aging system has been used way passed its use-by date.

There are ways to minimise the pain. 

Do you really need to migrate all the data from old to new? While tombstone data (that is, data that is static or non-transactional in nature) should be migrated; everything else can be ignored. In our experience. there is little point in migrating transactional records. Your accounting/tax/legal requirements will insist on you keeping them for whatever statutory time limits apply. (We had a client who simply printed every transactional register in its entirety and packaged them up and placed them in storage. As it happens, they have not yet been called upon to use those printouts, and each year those records that fall outside the statute of limitations are simply shredded).

You may also reconsider entering some static data like status codes. Implementing a new EAM/CMMS is a good  time to review the codes you are using and consider their relevance to your new goals and work methods.