Data migration, watch out!

Usually, nor sales responsibles neither consultants give data migration task the importance they should during the sales process, but they consume a really hugh amount of not planned time.

Migration tasks include: extracting, transformating and loading which are also known as ETL tasks.

As we all agree, the effort required to migrate the data of a small enterprise who manages all their activity using spreadsheets is not the same as a large company with a previous ERP system that wants to keep all its historical activity.

Therefore, I would like to enumerate few points to be taken into consideration,  before delivering a proposal, for a correct effort evaluation:

• Master data & historical data: Master data or reference data(business partners, products, accounting plan, assets, banks, taxes, production plans, etc.)  is what really makes sense to migrate instead of typing them manually. Historical data (orders, receipts, shipments, invoices, bank statements, amortizations, accounting entries, etc.) can be usually reviewed on the old system, so probably we could convince the customer it is not really necessary. Somehow, it is important to realize a historical data migration always requires a master data migration, and also note a historical data migration can take 4 times the master data migration. (20% & 80%).
• Accounting data & management data: There is also also difference between migrating just the accounting data or having to migrate all the invoices, bank statements, daily cashes, etc. in order to create the accounting data by the new application. Accounting data migration may take 20% of time than management data will.
• Period of time: Although the period won’t change the scope of the migration task, for sure, more defects and inconsistencies will be found as larger is the period. If we ask to the customer about the migration period, they will always say: “all existing information”.
• Extraction and transformation tasks included & excluded: Too often, when talking about migration we forget extraction and transformation tasks. Sometimes it is clear we do not know about the old system or the customer does not want to give us access to it, so it is clear we can’t deal with the extraction and transformation, but anyway, it is important to make it clear who is responsibe for data extraction and transformation. Not extracting data correctly when we have invested time on it can be a big issue. I’ll always try to ask for extracted and transformed data, ready to be loaded.
• Extracted data consistency and validation: If we can’t avoid extraction and transformation tasks, make sure the customer validates what you are going to migrate. It is useful to deliver lists or spreadsheets containing the final migration result before we finally load it so the customer can validate it.

As I tried to explained, migration offering needs to be detailed as possible in order to avoid future issues or project deviations from proposal.