Every ERP migration eventually collides with the same wall: the data. Duplicates accumulated over decades. Records inherited from systems two generations old. Customers in the master file who haven’t transacted in years. The new ERP vendor will validate formats — but they will not clean your data. That’s on you, and how you approach it determines whether your migration lands on time.
The mistake: cleansing inside the source ERP
The instinctive approach is to fix data where it lives. It’s also the riskiest. Running integrity-validation scripts and mass updates against a production ERP database can degrade performance for the entire operation — a system your business depends on every day until cutover. And source-side cleansing locks you into the old system’s structures, when what actually matters is the target system’s requirements.
The better architecture: a cloud staging layer
The recommended pattern is to extract data from the source ERP into a cloud data platform — BigQuery on Google Cloud is a strong choice — and perform all cleansing, transformation, and template-building there.
If your organization already streams ERP data to the cloud for analytics, you’re further ahead than you think. Pipelines built for BI and AI use cases (for example, Airflow jobs feeding BigQuery, connected to dashboards) can be repurposed directly for migration. The extraction layer, networking, and security are already solved. What remains is the transformation work.
How the process works
1. Obtain the target templates early. The new ERP defines exactly which fields it needs — customer codes, names, addresses, item masters, open balances. Request these templates as soon as possible, even before the to-be design is final, so the team is ready on day one.
2. Build templates as views. Each migration template becomes a SQL view in the warehouse, mapping source tables to target fields. Views are repeatable: refresh them and the latest data flows through the same logic.
3. Run exploratory data analysis. Before fixing anything, measure the problem. How many duplicate customers? Which records have invalid characters or missing mandatory fields? How many accounts have been inactive for three or more years — and should they migrate at all? EDA turns data cleansing from guesswork into a scoped, estimable project.
4. Cleanse with SQL, decide with the business. Deduplication and format fixes are technical work. Deciding whether a dormant account migrates is a business decision. The staging layer gives both sides one shared place to look at the evidence.
5. Materialize and export. Once views are clean, materialize them and export load-ready files. The migration team loads them into the new system; your production ERP is never touched.
Start with a discovery, not a guess
Data quality problems are invisible until you measure them. A short discovery phase — roughly two weeks of scoping tables, profiling quality, and estimating effort — produces a realistic plan and budget before full commitment. It’s the difference between a migration estimate and a migration surprise.
The compounding value of data infrastructure
The deeper lesson: data infrastructure compounds. Pipelines built to power dashboards and AI assistants become the foundation for the next migration, the next integration, the next initiative. Companies that invest in a modern data layer don’t just get better analytics — they get optionality.
Sisifo helps companies build cloud data platforms, AI tools, and migration-ready data pipelines on Google Cloud. If an ERP migration is on your roadmap, let’s talk about getting your data ready first.
