A company spent 15 years building a customer base of over a million people.Every interaction logged. Every transaction recorded. Every preference, every complaint, every renewal, every referral.A full commercial history of who their customers were and how they had behaved over time.They moved to a new system. A better one. Modern architecture, stronger reporting, cleaner structure.The migration was declared complete.Then someone asked for a demographic breakdown of customers who had purchased a specific product across the full 15-year history.The report came back.Five percent of the data was usable.Not five percent missing. Five percent present.The other 95% had either failed to load, loaded incorrectly, or loaded into fields the new system could not read — because the old records did not meet the new system's rules.The new system had clean, well-defined masters. Correct validation logic. Proper structure.The old data had none of those things.And nobody had checked whether the old data was ready to enter the new system before the migration happened.A million customers reduced to noise. Fifteen years of commercial history that existed in full in the old system and arrived as fragments in the new one.What followed was two years of reports that could not be run. Customers that could not be recognised. Loyalty that could not be rewarded. Decisions that could not be made.Then another year to fix what should have been fixed before anyone pressed go.Three years of business impact. One question nobody asked:Is our data actually ready to enter the new system?

The new system was not the problem. The new system's rules were correct and well-designed. The problem was that fifteen years of operational data had been collected without those rules — in formats the new system could not accept, with fields the new system did not recognise, and without the master data structure the new system required.A data migration is not a copy-and-paste exercise. It is a translation exercise. And if the data has not been prepared for the language of the new system, the translation fails — silently, at scale, and with consequences that only become visible months later.

1. Before any migration, run an ETL readiness assessment — understand what transformation the data needs before it can be accepted by the new system's rules2. Define the new system's master data standards before the migration and clean the historical data against those standards in the source system first3. Build an ETL process that transforms, cleanses, and validates historical data before loading — not after4. Run the ETL process on a sample dataset and validate the output against the new system's reports before committing to a full migration5. Treat the data preparation phase as a project milestone with its own timeline — it should never be compressed into the migration weekend

Assess the scale of the problem first — what percentage of historical data loaded correctly and what percentage did not. If the old system is still accessible, the ETL work that should have happened before migration can be performed now on the historical data. If not, assess backup options. Then build the ETL process, perform the data preparation, and reload the historical data into the new system. The business impact clock stops when the data is usable, not when the system goes live.