The transformation to the cloud is taking everything – and everyone — by storm. In spite of the earlier security issues and ever-present power-on power-off, surprises, the economies-to-scale are so low that it is almost guaranteed to be around for quite a while.
The transformation to the cloud is taking everything – and everyone — by storm. In spite of the earlier security issues and ever-present power-on power-off, surprises, the economies-to-scale are so low that it is almost guaranteed to be around for quite a while.
The Cloud has an Achilles Heel
Some believe there are still some bastions that are holding onto the past, mostly due to their inherent characteristics. But if it is their inherent characteristic, then they are not holding onto the past and the same characteristics have been transferred into the present. An ERP system, whether cloud, in-house, or on-premise is still a relational database. There are some that promising changes happening with unstructured data, such as OpenText, but for now however, the majority of systems are still using relational databases. Remember, what has been changed is only the system. You have only performed a system transformation to the cloud — data management is not part of this transformation.
Once a Database, Always a Database
Unless the end-users have been thoroughly educated to the details of how data is stored, updated, deleted, as well as how to perform regular audits in relational databases then there are going to be problems. Most likely, whatever data challenges were experienced with the old database had little to do with how the system operated but more with how it was entered. Hopefully, you had someone very knowledgeable with not only data management but had been familiar with your business and business processes also.
Such a trained eye would pick up more problems than someone who knows the system very well and has absolutely no idea if some of your data is sitting in the wrong field in either your legacy system and/or on the data maps to be used for the implementation. In the end, all you are doing is transferring the problem from one system to another — and probably blaming both systems as well.
Rebuilding Your Data Integrity
With the advent of everything becoming easier, and faster, it escalates the need to be sure your data is being entered and maintained correctly. So what do you need to do?
Before the data mapping even starts, print or capture every report – including the ad hoc reports generated within the past year (most of us save these things). Distribute these to the supervisors and/or department managers to note errors such as information that is missing, in the wrong place, or calculated incorrectly. And be sure to require a sign-off on these reports!
Needless to say, you will need to move the data from the old field to the correct field. Run the reports again, visually ascertain that everything has been corrected – then distribute the reports again, and again with a signature. Once the old system has had the database ‘cleansed’ then you can be sure that if there are any problems in the implementation, you can isolate it to the data mapping and not consider if the data integrity is questionable.
What has been your experience in data migration from the legacy system to the Cloud? In 10 words or less, please let us know what data management needs required your attention or what you discovered was a problem with your data integrity AFTER the data had been migrated.
-330x220.jpg)
