Most underestimated part of an ERP deployment
ERP implementations are tough. There are hundreds if not thousands of activities that need to all come together for the project to succeed. Project teams comfortably track the most obvious tasks such as configurations, customizations, integrations, etc. Yet, they are often caught by surprise with one of the most underestimated tasks - data migration. It is very common to see this key activity to be left towards the end of the project as an afterthought. Yet, without migrating the data, the solution cannot go live.
We need to change this paradigm. Data migration should be considered at the beginning of the project. While the key design decisions are being made, the corresponding data migration challenges need to be taken into account right away. If data structures, especially master data structures such as product, customer, vendor, etc., go through significant changes with the new solution, the data migrations challenges get bigger accordingly.
It is also common to see project teams struggle with the data migration method - which can be either over or under-engineered. Finding the right method to move the data is key for successful data migration. For example, if Bill of Materials data is complex (multi-tiered, lots of components, etc.), smaller in volume, and bigger in structural change, it may be better to manually enter the data rather than spending a lot of time and effort in writing complex one-time use migration scripts. On the other hand, large volume transaction-centric data migrations (like open sales orders, open purchase orders, etc.) tend to require automated scripts with complex mapping and logic. The key point is that one migration method does not fit all. It is OK to go sometimes manual, sometimes Microsoft Excel, and other times complicated automated scripts.
Another important area to consider for smooth data migration is data cleanliness. As we all know, junk in - junk out. Cleaning up the data, especially in the source system, prior to migration is a critical task and should not be taken lightly.
And as a final step, the migrated data needs to be validated prior to going live. For example, after cleaning and moving thousands of open sales order lines from the legacy system to the new solution, how do we really know that all the data migrated just fine? Is running the migration script without any errors satisfactory? This is where aggregation and comparison come to play. For this example, checking the total open sales order line count, quantity, and amount before and after the migration across both source and target systems would do the job.
If you are interested to learn more, please connect with me on LinkedIn, follow me on Twitter, or watch me on YouTube.
My name is Cem and this has been another gem.
