Data Quality Is the Number One ERP Project Risk — Here's How to Put It on the Risk Register
When your ERP steering committee last reviewed the project risk register, was data quality on it — with a named owner, an evidenced score and a funded mitigation plan? Or was it a bullet point in someone's slide notes, filed under "things the migration team will sort out"? For most IT leaders, honesty compels the second answer. And that gap between how much data quality threatens an ERP programme and how formally it is managed explains a remarkable share of the delays, budget blowouts and post-go-live firefighting that follow.
The problem is rarely awareness. Every experienced IT leader knows dirty data hurts migrations. The problem is translation: data quality gets discussed in technical language ("the material master needs cleansing") when steering committees make decisions in risk language (probability, impact, owner, mitigation, cost of inaction). Close that translation gap, and data quality finally gets the attention — and the budget — it has always deserved.
A Deadline-Driven Migration Wave Is Exposing an Old Weakness
The context makes this newly urgent. With SAP's end of mainstream maintenance for ECC approaching in 2027, thousands of organisations — including a large share of the asset-intensive companies across Australia and Southeast Asia — are somewhere in the middle of an S/4HANA migration or a broader move to cloud ERP. Analysts have been warning for several years that the migration wave is compressing: the closer the deadline gets, the more projects run in parallel, the scarcer skilled implementation resources become, and the less slack any single programme has to absorb surprises.
Against that backdrop, one pattern from two decades of ERP history matters more than ever: industry post-mortems have consistently placed data issues among the leading causes of ERP delays and budget overruns — often ahead of software defects and integration problems. The pattern is stable across vendors and industries, which tells you it is structural, not incidental. Migrations do not stumble because the new system cannot hold the data; they stumble because the old data cannot survive the trip. Duplicate material records, incomplete descriptions and inconsistent classifications that a twenty-year-old ECC instance tolerated quietly become blocking defects the moment a migration programme tries to map, validate and load them.
Read as news analysis, the implication for IT leaders is direct: in a compressed migration market, the risks you can retire early are worth disproportionately more. And no risk is more retireable — earlier and more cheaply — than data quality.
Why Data Quality Earns the Top Slot on the Register
A risk earns its position on the register through the arithmetic of probability times impact, and material master data quality scores brutally on both.
Start with probability. Unlike most project risks, this one is not a question of whether something might go wrong — the defect already exists, today, in your production system. Assessments of material masters in mining, oil and gas, power generation and manufacturing routinely find duplication rates of 10–20 per cent, description completeness well below what migration validation rules require, and classification coverage that is patchy at best. If your organisation has never formally assessed its material master, the probability that it contains migration-blocking defects is not "possible". It is close to certain.
Impact is where the numbers turn serious. Data defects discovered during migration testing force rework cycles that consume the scarcest resource an ERP programme has: the window of availability of functional experts and implementation consultants. Each failed data load pushes cutover rehearsals back; each pushed rehearsal threatens the go-live date; and in a deadline-driven migration, a slipped go-live can mean renegotiating contracts and extending licences for the legacy environment. Worse, defects that slip through arrive in the new system on day one — duplicate records fragmenting demand history, unfindable items driving free-text purchasing — quietly guaranteeing that the expensive new ERP performs no better than the old one. High probability, high impact, long tail: that is the profile of a top-of-register risk.
Writing the Risk Statement: Entries You Can Adapt Today
Steering committees act on well-formed risk statements, not on general anxiety. The strongest format links condition, cause and consequence in a single sentence, which makes both the score and the mitigation obvious. Three entries cover the material master territory for most ERP programmes; adapt the numbers to your own assessment findings.
Risk entry one — migration delay from duplicate and non-standard records. "If the material master contains significant duplication and non-standard item descriptions (estimated 10–20 per cent of ~[N] records, unverified), caused by years of uncontrolled item creation across sites, then data mapping and load cycles will fail validation and require repeated rework, resulting in schedule slippage of one to three months and extended consumption of functional and consultant resources." Suggested initial scoring: probability high, impact high — which in most matrices places it in the red zone and mandates active mitigation rather than acceptance.
Risk entry two — cutover defects from incomplete item data. "If item records lack the mandatory attributes, units of measure and classifications the target system requires, caused by legacy fields never being governed, then records will be rejected or loaded with defects at cutover, resulting in procurement and maintenance transactions failing in the first weeks of operation." This is the risk that turns go-live week into a war room. Probability is directly measurable from a sample assessment; impact reaches beyond IT into operations, which is exactly why the entry belongs on the programme register rather than a technical sub-plan.
Risk entry three — post-go-live degradation from absent data governance. "If no quality gate governs item creation in the new system, caused by governance being scoped out of the migration, then cleansed data will degrade at its historical rate, resulting in the business case benefits of the ERP investment eroding within 12–24 months." Programmes love to close this one out as "operational business-as-usual". Resist that. A migration that delivers clean data into an ungoverned process has merely scheduled its own relapse.
Scoring Probability and Impact Without Guesswork
A register entry scored on gut feel invites the steering committee to discount it. The credible alternative costs surprisingly little: evidence the score with a sample-based data assessment before the register is finalised. Measure the actual duplication rate on a statistically meaningful sample; measure description completeness against the target system's mandatory fields; measure classification coverage against the standard you intend to use, whether UNSPSC or NATO codification. Each measurement converts an argument into a number, and numbers survive steering committee scrutiny far better than adjectives.
The same assessment sharpens the impact side. Once you know the defect rate, you can model load-failure volumes, estimate rework effort in consultant-days, and translate schedule risk into dollars using the programme's own daily run rate. An IT leader who tables a risk entry reading "probability 85 per cent, evidenced by a 4,000-record sample assessment; impact $[X] per month of delay at current burn rate" is no longer asking the committee to trust an opinion. They are presenting a decision that prices itself.
Tiered Mitigation and the Question of Ownership
With the risk scored, the register demands a mitigation plan and an owner — and both deserve more thought than they usually get.
Mitigation works best in tiers matched to defect severity and time available. The first tier is assessment: quantify the problem early enough that every later decision is informed. The second tier is remediation: cleanse, standardise and classify the records that will actually migrate — which usually means prioritising active items and high-value categories rather than boiling the entire ocean. This is specialised work; it is precisely what a professional cataloguing engagement delivers, with experienced cataloguers resolving duplicates through specification analysis, rewriting names and descriptions to a consistent convention, and classifying items to the agreed standard — supported by purpose-built tooling such as SCS for the cleansing, naming, describing and classification work, always under the cataloguers' judgement rather than in place of it. The third tier is prevention: a governed item-creation workflow in the target system, so the risk entry can eventually be closed rather than perpetually re-opened.
Ownership is the subtler question. The instinct is to assign the risk to IT, since data lives in systems. That instinct is wrong, and experienced programme directors know it: the causes (uncontrolled item creation, unagreed standards) and the consequences (procurement failures, maintenance delays, working capital) both sit in the business. The entry works best with a business owner — typically the supply chain or asset management executive — accountable for the risk, with IT accountable for the technical mitigation actions beneath it. That single ownership decision changes the conversation from "an IT data problem" to "a business risk with a funded plan", which is the entire point of putting it on the register.
Conclusion
The ERP migration wave now cresting toward 2027 will sort organisations into two groups: those that treated material master data quality as a technicality to be handled during the project, and those that treated it as the programme's number one risk — registered, scored on evidence, owned by the business and mitigated in tiers before the migration needed the data. History is unambiguous about which group finishes on time.
The good news for IT leaders is that the tool for making this happen already exists and already has the committee's respect: the risk register itself. Write the entry, evidence the score, name the owner. A risk formally registered is a risk the organisation has agreed to manage — and that agreement, more than any technology decision, is what separates migrations that land from migrations that limp.
Put the Evidence Behind the Entry
Before your next steering committee, there is one question worth settling: can you evidence the data quality risk entry — or only assert it?
Because an unevidenced entry is easy to discount. And while it sits discounted, the consequences accumulate quietly: mapping cycles fail, rework consumes consultant-days, cutover dates wobble, and after go-live, duplicate records and unfindable items keep procurement slow and working capital stranded on shelves.
In most organisations, the obstacle is not the ERP platform, and it is not the project team. It is the quality, governance and searchability of the material master data underneath — inconsistent descriptions, missing attributes and classifications no validation rule will forgive.
That is why at Panemu, we help organisations establish the true condition of their material master data through a free consultation and data assessment — quantifying duplication and completeness on a real sample, sizing the migration risk in numbers a steering committee can act on, and recommending a practical, prioritised path to remediation for a stronger procurement, maintenance and supply chain foundation.
Because a risk you can measure is a risk you can retire.
Curious what your material master would score if it were assessed this week?
Send us a sample of your material master data for a free assessment, or book a consultation with our cataloguing team at https://panemu.com/cataloguing-service — and walk into your next steering committee with the evidence in hand.