Organizations spend millions implementing new enterprise systems. They spend weeks on data migration. They spend almost nothing on data governance — and then spend years recovering from the consequences.
Data governance is the least glamorous discipline in enterprise transformation and the one most responsible for go-live failures, post-launch performance problems, and the slow erosion of confidence in new systems that should have delivered transformational value.
Here is what actually happens, why it happens, and what the organizations that get it right do differently.
The Pattern
A major ERP implementation is six months from go-live. The technical team is behind. The integration work is complex. The steering committee is focused on timeline recovery.
Someone raises data migration. The project manager confirms that data migration is "in progress." The steering committee moves on.
What "in progress" actually means: a team of analysts is extracting data from legacy systems, cleaning obvious errors, and building migration scripts. What nobody has addressed: which version of the customer master record is authoritative when three source systems disagree. Who owns the product hierarchy that evolved organically over 15 years across four business units. What "complete" means for supplier data when 30% of records are missing required fields.
Go-live arrives. The migration runs successfully. The new system is populated with data that is technically present and structurally correct. Users open the system and immediately begin reporting problems. Customer records are duplicated. Product codes are inconsistent. Financial reports do not match legacy system outputs.
The system works perfectly. The data does not.
Why This Keeps Happening
Data governance requires business decisions, not technical ones. Who owns the master data? What is the golden record when sources conflict? Who has authority to resolve data quality disputes between business units?
These are organizational questions disguised as technical problems. Technology teams cannot answer them. Business teams do not want to own them. The result is a gap that persists until go-live makes it impossible to ignore.
What the 35% Do Differently
Successful transformation programs treat data governance as a business discipline established before the technical workstream begins. Specifically:
They appoint data stewards — named individuals in the business who own specific data domains and have authority to make quality decisions. Not data administrators. Decision-makers.
They define the golden record policy — when sources conflict, which system is authoritative, and under what conditions that hierarchy can change.
They establish go-live data quality thresholds — specific, measurable criteria that must be met before cutover proceeds. "Good enough" is not a threshold. "95% of customer records complete with no critical field missing" is a threshold.
They fund data governance as a separate workstream — not as a subset of the technical migration. Data governance requires business time, business decisions, and business ownership. It cannot be delegated to the implementation team.
The investment is significant. The alternative is more expensive.