4 reasons your ERP data migration failed
According to Wikipedia, “Data migration is the process of transferring data between storage types, formats, or computer systems…;” pretty simple, right? However, while the paper definition appears to be about as benign as it is straightforward; as a practical matter, ERP data migration glitches can create a cascade of issues that cause an ERP project to crash in the blink of an eye.
1. Expectation management issues
The ultimate business value of an ERP data migration is largely based on the receiving system’s empirical accuracy and stability after conversion. However, before one can pull the trigger on a migration decision, issues of “expectation management” should come to the fore. If the upgrade to a new ERP is not well-understood, all the digital ingenuity in the world won’t deliver a solid outcome.
For example, many enterprises fall prey to sales hype just because an ERP system has become balky or difficult to deal with over time. However, in many cases, inefficiencies like these are not caused by obsolescent technology but rather by poorly managed operational policies or process irregularities. In more direct terms, blaming bad results on bad tools when the craftsmen are actually at fault.
These kinds of expectation errors filter up and down an enterprise, and can ultimately create all kinds of misunderstandings about the efficacy of data and consequent information. These misunderstandings can accumulate to create judgments that are inaccurate, leading to erroneous results.
2. Data compliance mis-matches
Successful ERP data migrations are highly-complex processes involving the translation of every bit of data from one platform to another. As a result, there is ample opportunity to get it wrong, particularly since the export/import continuum is largely unmanned until all data elements are delivered to their desired positions within the receiving system.
ERP data migration glitches can create a cascade of issues that cause an ERP project to crash in the blink of an eye.
However, if an enterprise is lax about migration planning, or doesn’t take proper care when mapping and ensuring that every record is compliant with the receiving system, things tend to go south in a heartbeat, creating lost money, time, or worse. For example, consider an element as simple as a field length; if system A contains 15 characters, and system B will only accept 12 characters, consequent translated values will be skewed at best, and completely unusable at worse. An automated migration routine often doesn’t care one way or the other.
3. Unexpected ‘under the cover’ gotchas
This issue plays nicely with both of the previous areas of focus, however, in this case what I am specifically referring to are very low-level ERP elements typically categorized as being ‘miscellaneous.’ For example, some systems allow for non-filtered non-alpha ASCII characters within a constellation of data records, where other systems will not.
Consequently, while the export side of an automated ERP data migration routine may ‘want’ to deliver that spurious semi-colon, the import side might not and subsequently cause the process to fail. The important lesson to learn is that you must create a thorough plan for data and format mapping between the old system and the new.
4. Synchronization failures
ERP platforms typically deliver information by leveraging hosts of databases in parallel. Each data mass produces some level of active dependency, or relative awareness if you will, in order to maintain record stability.
However, if an ERP data migration routine disrupts or alters this set of dependencies, or suddenly loses synchronous awareness from database to database, the entire system falls off the road.