10 ERP modernization mistakes to avoid

The ERP modernization mistakes that hurt most are strategic, not technical: treating go-live as the finish line, copying legacy processes into the new system, starting data and change work too late, building everything into the ERP, and signing licences without a five-year model. They rarely show up in real time. They surface after go-live, when the promised efficiencies don't appear and the workarounds come back.

This is for CIOs, CFOs and programme directors planning or rescuing an S/4HANA or other ERP modernization. Each mistake below comes with what it looks like in practice and the fix, followed by a one-page early-warning checklist and what the 2026 SAP changes mean.

I have watched well-funded projects with experienced teams and a full bench of advisers still fall short. The cause is rarely the system. It is gaps in ownership, integration planning and communication between teams making decisions that depend on each other.

1. Treating go-live as the finish line

Once the system is live, many teams assume the heavy lifting is done. That is when the real pressure starts: daily operations, shifting requirements and real user behaviour push against the design.

I have seen projects where the steering committee disbands immediately after go-live. Six months later adoption is flat and nobody owns the backlog.

The fix: fund a 6 to 12 month post-go-live governance period. Extend the steering committee's mandate. Monitor process adoption, not just uptime. Set post-go-live quality gates with named owners.

2. Migrating legacy processes without rethinking them

I have seen entire approval chains rebuilt exactly as they were, even when half the people involved had nothing to do with the current process. Nobody had asked whether the steps were still needed. The result was a modern ERP running old workflows: a more expensive version of what they already had.

The S/4HANA version of this: custom batch jobs moved as-is from ECC, built on table structures that no longer exist. The migration is technically clean. The business logic is broken.

The fix: redesign processes before the build. Walk operations, finance and delivery teams through each workflow together and challenge every step.

Legacy area	What often goes wrong	What to do instead
Custom code from ECC	Unused custom code moved to S/4HANA	Run usage analysis and SAP's custom code checks; retire unused code
Old workflows	Approval flows rebuilt when automation is now possible	Revisit with business owners; use standard Fiori apps or SAP Build Process Automation
Non-standard master data	Flexible legacy setups fail S/4HANA validation	Cleanse and harmonise before migration, with SAP MDG where it fits
Reports on legacy tables	Direct table access doesn't match S/4HANA's data model	Rebuild on CDS views
Hidden manual workarounds	Side processes reappear after go-live	Use process mining before migration and digitise the gaps

3. Starting data migration too late

Moving bad data into a new ERP is like moving house without throwing anything away. The clutter comes with you, and it is harder to clear once it's inside a structured system.

I once saw a go-live fail because nobody caught that a core dataset had entries from five different business units, each with its own coding logic. The technical migration was correct. The data wasn't usable. Reports broke, users lost trust, and cleanup under a live system took months.

The fix: make data a workstream with business accountability. Assign process owners, not just technical consultants. Decide what to bring over, archive or rebuild before migration starts. Run at least two full mock loads, with a dependency map for load sequence and a defined rollback for each load. My piece on why SAP data migration fails goes deeper.

4. Treating change management as a side task

The usual version: change management is "already handled", which means a few slides, a demo and one training session before go-live.

People don't push back because they dislike change. They push back when nobody explains why things are changing or how it helps them. They follow the system just enough to pass the checklist, then go back to spreadsheets.

The usual trigger is schedule pressure: training gets compressed to recover time, users are overwhelmed at go-live, and the extra hypercare costs more than the training that was cut.

The fix: give change management its own budget, timeline and senior owner from the start. Map roles early, find local champions, and track adoption KPIs alongside technical milestones. My change management plan guide sets out the structure.

5. Planning around vendor roadmaps

I have seen teams base their integration strategy on a vendor's future release, only to see it pushed out by 12 months. In the meantime they were stuck building temporary workarounds, and the workarounds became permanent.

Vendors build roadmaps for broad customer groups. Your business is rarely the centre of that design.

The fix: treat the roadmap as one input. Design around what is generally available today, test new features in a sandbox before planning on them, and count roadmap benefits as upside, not as budget.

6. No decommissioning plan for legacy systems

I once saw a company paying six figures a year to keep an old system running for six users who needed to pull reports twice a year. Nobody had built a decommissioning plan.

The fix: put decommissioning in the project charter from day one, with legal, compliance and data governance involved, not just IT. Agree retention periods and an archive approach before go-live, map and disconnect every interface to the old system, and give one team the job of switching it off.

7. Underestimating integration complexity

When integration fails, the business notices before IT does, because workflows stop mid-process in production, not in a test system.

The common pattern: IT and the business each assume the other has defined the integration requirements. Neither has. By the time the gaps show up in testing, there is no time to redesign.

The fix: start integration design in blueprinting. Define each scenario, the middleware, the mapping and the message volumes, and clarify real-time versus batch per interface with the business. Name an interface owner with an SLA before go-live. For new SAP programmes the middleware is SAP Integration Suite; SAP PI/PO leaves mainstream maintenance at the end of 2027.

8. Assuming the ERP can handle everything

I have worked on projects where teams forced complex service workflows (IT tickets, asset requests, escalation routing) into the ERP because they didn't want to involve external systems like ServiceNow. The result was custom fields everywhere, manual workarounds and users stuck in a process that never fit.

ERP is good at structured, transactional, financially anchored processes. Dedicated platforms do IT service requests, workflow orchestration and knowledge management better.

The fix: decide deliberately what not to build in the ERP. Use side-by-side extensions on SAP BTP for exceptions, and ServiceNow or similar for orchestration outside the transactional core. My article on ERP modernization with SAP and ServiceNow covers that split.

9. Underestimating long-term licensing cost

I know one team that doubled its licensing spend in year two because it needed a single feature behind a higher-tier licence. The business case had modelled go-live cost only.

ERP licences charge for users, modules, transactions and API usage, and cost scales with the business whether you planned for it or not. On SAP, the Digital Access model means documents created by third-party systems can carry licence cost that wasn't in the original commercial model. Under RISE and SAP GROW, Full User Equivalent (FUE) counts grow with adoption.

The fix: build a three-to-five-year licence model before signing. Map roles to licence types, model FUE growth on a realistic adoption curve, understand indirect access before connecting external systems, and audit inactive users after go-live.

10. Treating ERP as an IT project

The most common and most damaging pattern. Planning starts in IT, is led by IT and solves IT problems.

I have seen teams hit every milestone on paper while the business still asks why nothing feels better. That usually means the ERP was built for yesterday's processes, without operations, finance or commercial leaders in the design.

The fix: put commercial, finance and operations leaders on the steering committee from the start. Write strategic alignment into the charter, not just technical scope. Test the programme's goals against board-level outcomes before design begins.

Use this at each steering committee. If a warning sign is present, the named owner reports on it until it's gone.

1. CharterOwnership and costNo operations or finance lead, no five-year licence model, no retirement date
2. BlueprintProcess and integration designToday's process copied, interfaces still undesigned
3. First mock loadDataNo data quality report yet
4. Go-liveWhat happens nextNo funded governance for the 12 months after

Mistake	Early warning sign	Owner
1. Go-live as finish line	No funded governance plan for the 12 months after go-live	Sponsor
2. Copied legacy processes	Design workshops start from "how we do it today" screens	Process owners
3. Late data work	No data quality report before the first mock load	Data migration lead
4. Change as a side task	Change plan is a training calendar	Change lead
5. Roadmap dependency	A design decision waits on a feature that isn't released	Solution architect
6. No decommissioning	No retirement date for any legacy system in the charter	PMO
7. Integration underestimated	Interfaces not designed by end of blueprint	Integration lead
8. ERP for everything	Custom objects for non-transactional workflows	Enterprise architect
9. Licensing	No five-year licence model in the business case	CFO
10. IT-only programme	Steering committee has no operations or finance lead	Sponsor

Deployment. For new SAP programmes the default is RISE with SAP on SAP Cloud ERP Private, or SAP GROW on the public edition (SAP Cloud ERP) for mid-sized companies. New on-premise deployments are rare. ECC customers face mainstream maintenance ending on 31 December 2027, which shortens the time available to fix mistakes 2, 3 and 7.

Clean core. SAP now grades extensions on four clean core levels, from A (released APIs only, side by side on BTP or in-system with ABAP Cloud) to D (not clean). The public edition only allows level A, which forces the conversation behind mistake 2. The private edition still allows classic extensions, so the discipline has to come from governance. Classic custom code is what makes every upgrade a project. My clean core strategy piece goes further.

AI in the delivery tooling. Joule now sits in SAP Cloud ALM and the SAP Activate Roadmap Viewer, and SAP Build Code uses Joule for extension development. Ask partners how AI tooling is reflected in their rate card. If it isn't, either the price is high or the saving is going to their margin.

Lifecycle tooling. SAP Cloud ALM is the lifecycle management tool for cloud programmes. Solution Manager 7.2 leaves mainstream maintenance at the end of 2027, so landscapes running both need a plan for the move.

The ten mistakes didn't change. The cost of getting them wrong did. On a RISE programme, the clean core decision, the deployment model and the FUE model are all set in the first weeks of mobilisation. The window to influence them is short.

Why do ERP modernization efforts fall short after go-live?

Most teams plan to go-live and stop. Nobody owns enhancements, feedback, process corrections or the backlog. The steering committee disbanding at go-live is the most reliable sign of trouble. Fund 6 to 12 months of post-go-live governance from day one.

What is the risk of copying legacy processes into a new ERP?

The new system inherits the old inefficiencies at higher cost. In S/4HANA migrations specifically, custom code and batch jobs built for ECC tables often don't work, so the migration can be technically clean while the business logic is broken.

How does poor data quality damage an ERP modernization?

Duplicate vendors, inconsistent master data, legacy codes and incomplete records all carry into the new system unless someone cleans them first. Reports break, users stop trusting the numbers, and cleanup under a live system takes months.

Why is change management so often underestimated in ERP projects?

Because it isn't visible on a project plan the way configuration is. Executives assume a few training sessions are enough. Change management is preparing people for what will actually change in their daily work, before go-live. Digital adoption tools such as WalkMe, now owned by SAP, help with in-app guidance, but they don't replace the explanation of why.

Why do legacy systems keep running years after ERP go-live?

Because nobody planned to shut them down. Everyone is focused on getting the new ERP live, and the old systems stay on for compliance, reference or comfort. Decommissioning has to be in scope from day one, with legal and compliance involved.

How do RISE with SAP and clean core change these mistakes?

On the public edition, clean core rules make deep customisation impossible, which forces the process conversation behind mistake 2. On the private edition, classic extensions are still allowed, so clean core depends on governance. Integration moves to SAP Integration Suite as PI/PO maintenance ends. Licensing becomes an FUE growth question. Decommissioning becomes more urgent because running legacy systems in parallel adds cost on top of a multi-year subscription.