After watching roughly 50 ERP migrations, I have learned that the software is rarely the hardest part.
The difficult part is getting the business to agree on how it should operate, preparing the data nobody wants to own, holding vendors accountable, and changing the daily behaviour of thousands of employees.
Nobody tells you this at the start.
The business case focuses on efficiency. The vendor focuses on functionality. The board focuses on the go-live date.
Then reality arrives.
The programme is six months late. The data is unreliable. Process owners disagree. Users create workarounds. The implementation partner asks for another change request.
Here are three things I wish every CIO, CFO and ERP sponsor knew before signing the first contract.
1. An ERP transformation is an operating model decision
Most organizations describe ERP as a technology programme.
That is the first mistake.
An ERP system forces decisions about how the organization sells, buys, pays, reports, manages inventory, serves customers and controls risk. It exposes inconsistent processes that were previously hidden behind spreadsheets, manual approvals and local workarounds.
The software does not remove those disagreements.
It makes them impossible to ignore.
Process ownership is not optional
You need named business owners for every critical end-to-end process before configuration begins.
Not department heads who attend monthly steering meetings.
Actual process owners with the authority to make decisions.
Examples include:
- Order to cash
- Procure to pay
- Record to report
- Hire to retire
- Plan to produce
- Forecast to fulfil
- Case initiation to resolution
If nobody owns the process, the implementation team will make the decision by default. Usually through a configuration choice made under time pressure.
That decision then becomes the new operating model.
This is how organizations end up reproducing legacy inefficiencies inside a modern ERP platform.
The uncomfortable question is not, “Can the system support this process?”
The better question is, “Should the business still operate this way?”
Design the process before configuring the platform
Do not begin with a list of legacy requirements and ask the vendor to recreate them.
That approach turns ERP into an expensive photocopier.
Start with the outcomes the business needs. Faster month-end close. Better inventory accuracy. Stronger financial controls. Fewer manual reconciliations. Clearer customer visibility.
Then design the future-state process around those outcomes.
Research published by Prosci on ERP implementation failure makes the same point from another angle: human and organizational factors matter significantly more than technical factors in realizing ERP benefits.
The technology is only the mechanism.
The operating model is the transformation.
2. Your data will decide whether users trust the ERP
ERP programmes often treat data migration as a technical workstream.
That is too narrow.
Data is a business asset. Data quality is a business responsibility. Data ownership must sit with the people who understand how the information is used.
A technically successful migration can still produce an operational failure if the business cannot trust the results.
Master data problems do not disappear during migration
They become more visible.
Duplicate suppliers. Conflicting customer records. Inconsistent product codes. Missing tax classifications. Outdated bank details. Different definitions of “active customer” across business units.
These issues are often tolerated in legacy environments because employees know the workarounds.
The new ERP removes those informal workarounds. If the data is wrong, the process stops.
That is why master data readiness needs its own plan, budget, governance and stage gates.
Before go-live, you should be able to answer:
- Who owns each critical data domain?
- What is the approved definition of each master data object?
- Which records will be migrated, archived or removed?
- What quality thresholds must be met?
- Has the migration been rehearsed using production-like data?
- Can business users validate the migrated records?
- What happens when data quality falls below the go-live threshold?
If the answer to these questions is “the vendor is managing it,” you have a governance problem.
The vendor can provide tools and methods. The business must decide what the data means.
Data quality must be tested in business scenarios
A migration is not complete because records loaded successfully.
The real test is whether users can complete critical business transactions with confidence.
Can finance close the books?
Can procurement raise and approve a purchase order?
Can operations plan using reliable inventory data?
Can sales invoice the right customer with the right tax treatment?
Can executives trust the management report?
That is the standard.
Do not approve data readiness based on technical load percentages. Approve it based on business usability.
3. Adoption must begin before the first configuration workshop
Many ERP programmes treat adoption as a training activity near the end of the project.
That is not adoption planning.
Training people on a process they did not help design is not transformation. It is late-stage damage control.
Prosci reports that organizations allocate approximately 92% of ERP implementation budgets to technology activities, even though leaders identify the people side as one of the areas they would handle differently. That imbalance explains why many systems go live but fail to deliver the expected business value.
Users do not resist technology. They resist uncertainty.
Employees want to know:
- What is changing?
- Why is it changing?
- What will happen to my role?
- Will I still be able to do my job?
- Who will support me when the system fails?
- Will leadership follow the new process?
- What happens to people who continue using spreadsheets?
These questions cannot be answered by a generic training deck.
They require visible sponsorship, role-based impact analysis, practical demonstrations and early user involvement.
Your strongest users should be involved in design, testing and validation. Not because every preference should become a requirement, but because they understand how work actually happens.
They will identify gaps that no process document will reveal.
Measure adoption as behaviour, not attendance
Training completion is not adoption.
A user can complete training and still avoid the new process.
Track measures such as:
- Percentage of transactions completed in the new ERP
- Use of legacy systems after go-live
- Manual workarounds by process
- Error and rework rates
- Time required to complete critical tasks
- Adoption by role, location and business unit
- User confidence and support demand
- Benefits achieved against the original business case
Go-live is not the finish line.
It is the point at which the business starts paying for the consequences of its preparation.
Vendors do not own your transformation outcome
Your implementation partner may be accountable for its deliverables.
That does not mean it owns your business outcome.
This distinction matters.
A vendor can complete configuration, submit test evidence and meet contractual milestones while the organization remains unable to operate effectively.
The contract may be technically satisfied. The transformation may still be failing.
Manage vendors through evidence
Do not accept progress reports based on activity.
“Design sessions completed” is not the same as “future-state design approved.”
“Testing started” is not the same as “critical business scenarios passed.”
“Data loaded” is not the same as “users trust the data.”
“Training delivered” is not the same as “employees can perform their roles.”
Your governance model should demand evidence:
- Working end-to-end demonstrations
- Completed business scenarios
- Defect trends and resolution rates
- Data quality results
- Integration test outcomes
- User acceptance evidence
- Benefits tracking
- Decisions requiring executive action
A green status report without working evidence is not good news.
It is a risk signal.
The 7-Vendor Death Spiral is also real. Every additional supplier creates another boundary where accountability can disappear.
If you use multiple partners, appoint a clear integrator. Define ownership of the grey spaces between contracts. Standardize reporting, tooling, decision rights and escalation paths.
You cannot outsource accountability.
The real cost of delay is larger than the revised budget
ERP delays are usually presented as a financial problem.
They are bigger than that.
A delayed ERP programme consumes leadership attention, internal capacity and organizational confidence. It postpones benefits. It extends legacy technology costs. It creates change fatigue. It ties up subject-matter experts who still need to run the business.
The most expensive delay is not the one that appears on the budget.
It is the delay that allows a weak plan to continue for another six months because nobody wants to declare the truth.
That is how a programme becomes “too far gone to stop” but “not healthy enough to finish.”
CIOs should establish independent evidence-based health checks before major funding releases. Do not wait until the dashboard turns red. By then, recovery options are narrower and more expensive.
The real cost of false green is that it steals your ability to act early.
What I would do before approving an ERP programme
Before signing off the implementation plan, I would require five things:
- Named process owners with authority to make cross-functional decisions.
- A funded master data programme with business-owned quality thresholds.
- An adoption plan covering roles, behaviours, training, sponsorship and post-go-live reinforcement.
- A vendor accountability model based on business evidence, not activity reports.
- Independent delivery assurance before each major stage gate.
I would also ask one uncomfortable question:
If the programme slips by six months, what will it cost the business beyond the additional implementation fees?
If nobody can answer, the business case is incomplete.
ERP success is not strategy followed by software installation.
It is:
Strategy → Technology → Execution → Adoption → Business Outcome
Most failed programmes over-invest in the first two stages and under-invest in the last three.
That is where the execution gap opens.
If you are preparing for an ERP transformation, or if the business case is strong but the delivery plan feels fragile, start with the truth. A Delivery Diagnostic can identify the ownership, data, governance, vendor and readiness gaps before they become expensive programme failures.
FAQ
What is the biggest risk before starting an ERP transformation?
The biggest risk is treating ERP as a software implementation rather than an operating model change. If process ownership, data readiness and adoption are not addressed early, the technology will not deliver the expected outcome.
Who should own master data in an ERP programme?
Business data owners should own the meaning, quality and lifecycle of master data. The technology team and implementation partner can provide tools and migration support, but they should not decide whether the business data is fit for use.
When should ERP change management begin?
Change management should begin during the business case and design phase. Waiting until training starts is too late because adoption risks are created by process, role and decision-making choices made much earlier.
How should CIOs manage ERP implementation partners?
Manage partners through evidence and measurable outcomes. Require working demonstrations, tested business scenarios, data-quality results, defect trends, adoption measures and clear ownership of cross-vendor dependencies.
Should an ERP programme be delayed if data is not ready?
Usually, yes. A short delay to resolve critical data issues is less expensive than going live with unreliable records, broken controls and users who immediately lose trust in the system. Go-live decisions should be based on business readiness, not calendar pressure.
SEO publishing details
- SEO title: ERP Transformation: What Every CIO Should Know
- Meta description: Before starting an ERP transformation, CIOs must address process ownership, master data, adoption, vendors and the real cost of delay.
- Suggested URL slug:
/things-every-cio-should-know-before-erp-transformation - Focus keyword: ERP transformation
- Secondary keywords: ERP implementation risks, ERP master data readiness, ERP adoption, ERP programme governance, ERP implementation partner
- Image alt text: Senior CIO, CFO and operations leaders reviewing an ERP transformation roadmap in an enterprise war room
- Internal links: Dark Consultancy services, The 7-Vendor Death Spiral, The Real Cost of False Green
- External authoritative sources: Prosci: Why Do ERP Implementations Fail?, Gartner: Enterprise Resource Planning
- Recommended schema: Article Schema and FAQPage Schema
About the Author
Kunal Patel : CEO & Founder, Dark Consultancy
Kunal Patel founded Dark Consultancy after two decades leading technology and transformation programmes across the public sector, financial services, defence, and energy industries. He has directly managed programme recovery engagements for government agencies, development finance institutions, and regulated enterprises across the US, Middle East, South Asia, and Southeast Asia ; ranging from $5M platform migrations to $200M+ enterprise transformation portfolios. Kunal is a recognised practitioner in delivery governance for regulated environments and holds PMP and PRINCE2 Practitioner certifications. He leads every new client engagement personally and remains accountable throughout the programme lifecycle. Connect with Kunal on LinkedIn