What should you fix in SAP ECC before migrating?

Before migrating from SAP ECC to S/4HANA, you should fix data quality issues, deactivate or remediate custom code that is incompatible with S/4HANA, and resolve open transactional items that will block migration. Not everything needs to be perfect before you go live, but certain categories of problems will cause your migration to fail or create serious operational disruption if left unaddressed. The sections below walk through the most important areas to assess and act on.

Which SAP ECC issues cause the most problems during migration?

The SAP ECC issues that cause the most problems during migration are incompatible custom code, poor data quality, and open transactional objects such as purchase orders, sales orders, and production orders that were never closed. These three categories account for the vast majority of delays, failed cutovers, and post-go-live incidents in SAP S/4HANA migrations.

Custom code is a particularly common issue because SAP ECC systems accumulate years of bespoke developments, many of which rely on tables, function modules, or APIs that no longer exist in S/4HANA. If this code is not identified and remediated before migration, it will either block the technical upgrade or break business processes after go-live.

Data quality problems compound quickly in the new system. S/4HANA has stricter data validation rules than ECC, and records that passed silently in the old environment will fail on import. Open transactional items are a similar problem. Unclosed purchase orders or incomplete deliveries from years ago create inconsistencies in the migrated data set and can cause reporting errors or process failures from day one.

How do you assess the current state of your SAP ECC system?

You assess the current state of your SAP ECC system by running a structured readiness analysis that covers custom code, data quality, open items, and business process coverage. SAP provides tools such as the Readiness Check and the Custom Code Migration Worklist that automate parts of this analysis, but a meaningful assessment also requires human interpretation of the results.

A proper ERP readiness assessment looks at four dimensions:

Technical landscape: Which add-ons, interfaces, and integrations exist, and how many are incompatible with S/4HANA?
Custom code volume: How many custom objects are in use, and what proportion will need remediation?
Data quality: What is the completeness and accuracy of master data and transactional data across key business objects?
Process coverage: Which business processes are currently supported in ECC, and are they aligned with the target S/4HANA configuration?

This is the kind of baseline work we at Optinus always recommend doing before any roadmap or budget is committed. A maturity assessment gives you a concrete picture of where you actually stand, so you are not discovering critical blockers halfway through a migration programme. Going in without this clarity is one of the most common and costly mistakes organisations make.

What data should be cleaned up before an SAP migration?

Before an SAP migration, you should clean up master data (materials, vendors, customers, cost centres), open transactional data (unfinished orders, open deliveries, incomplete invoices), and duplicate or obsolete records that have accumulated over years of system use. These categories have the highest impact on migration success and post-go-live data integrity.

Master data is the foundation of every business process in S/4HANA. If your material master records contain inconsistent units of measure, missing classifications, or outdated pricing conditions, those errors will propagate through every transaction after go-live. The same applies to vendor and customer master data, which feeds procurement, accounts payable, order management, and accounts receivable.

Open transactional items are worth special attention. Many SAP ECC systems carry purchase orders, production orders, or maintenance notifications that were created years ago and never formally closed. These objects need to be either completed, cancelled, or migrated with a clear decision about their status in the new system. Leaving them unresolved creates noise in the migrated data and can trigger process errors in S/4HANA workflows.

Duplicate records are another area where ECC systems tend to accumulate technical debt. Vendor duplicates, material duplicates, and customer duplicates create reconciliation problems after migration and undermine the accuracy of reporting in the new system.

When we manage data migration for clients, we use a rigorous As-Is/To-Be analysis to map exactly which data objects are in scope, what their current quality looks like, and what remediation is needed before the first load. This prevents data loss and avoids the situation where teams discover quality problems only during migration testing.

How much custom code in SAP ECC needs to be fixed before migrating?

Not all custom code in SAP ECC needs to be fixed before migrating, but any code that touches deprecated objects, removed tables, or changed APIs in S/4HANA must be remediated. In practice, organisations with mature ECC systems often find that between 20 and 40 percent of their custom code requires some form of change, though the actual proportion depends heavily on how the system was built and maintained.

SAP’s Custom Code Migration Worklist and the Simplification Item Check identify which custom objects are affected by S/4HANA simplifications. The output of these tools gives you a prioritised list: objects that will cause hard errors, objects that need functional adjustments, and objects that can be retired entirely because the standard S/4HANA functionality now covers the same need.

Retiring custom code where possible is always preferable to remediating it. Every piece of custom code you carry forward into S/4HANA is a maintenance cost and a future upgrade risk. A migration is a good moment to challenge whether a custom development still serves a real business need or whether it was built to work around a limitation that no longer exists.

The remediation work itself ranges from simple syntax corrections to significant functional redesign. Objects that interact with financial accounting, controlling, or materials management tend to require the most attention because these are the areas where S/4HANA made the deepest structural changes compared to ECC.

Should you fix everything in SAP ECC or migrate first and clean up later?

You should fix the issues that will block migration or cause operational failures, and defer lower-priority cleanup to after go-live. Trying to fix everything before migrating is rarely practical and often delays the programme unnecessarily. The goal is to migrate with a system that is stable and fit for purpose, not perfect.

A useful way to think about this is to divide issues into three categories:

Must fix before migration: Incompatible custom code, critical data quality gaps, and open items that will cause hard errors during the migration load or break core business processes after go-live.
Should fix before migration if time allows: Duplicate records, obsolete master data, and minor process inconsistencies that will create friction but not system failures.
Can fix after go-live: Reporting refinements, non-critical custom code that still works in S/4HANA with minor issues, and data enrichment that improves quality but is not blocking.

The risk of the “migrate first, clean up later” approach is that post-go-live capacity is usually consumed by stabilisation, hypercare, and user support. Cleanup items that seemed manageable before go-live have a habit of staying on the backlog indefinitely. Be honest about what your team will realistically have the bandwidth to address once the system is live.

Explore our full range of services to understand how each phase of an ERP migration can be supported with the right expertise.

How Optinus helps you prepare your SAP ECC system for migration

We support organisations at every stage of SAP ECC migration preparation, from the initial readiness assessment through to data migration execution and go-live. Here is what that looks like in practice:

Maturity and readiness assessment to give you a clear baseline before any budget or timeline is committed
As-Is/To-Be data analysis to identify exactly which data objects need remediation and what the migration scope looks like
Custom code review support to help you prioritise what to fix, retire, or carry forward
Data migration management with rigorous testing procedures to prevent data loss and errors during the actual migration load
Cutover planning and execution including hypercare and aftercare, so operational continuity is protected at go-live
On-site and remote delivery across the Netherlands, Belgium, and internationally

Our consultants have worked on real SAP migrations at leading multinationals, so the advice you get is grounded in hands-on experience, not just methodology. If you want to talk through where your organisation stands, get in touch with our team or learn more about what we do.

home|

blog|