ECC to S/4HANA Migration
An ECC to S/4HANA migration converts an existing SAP ECC system in place, keeping configuration and transactional history while the underlying data model, custom code and finance structures are brought onto S/4HANA. It is a technical project with business consequences rather than a redesign of how the company works.
Converting the system you already run
A system conversion takes a live SAP ECC system and moves it onto S/4HANA in place. Configuration stays. Transactional history stays. What changes is the database and data model beneath it, the finance structures, the custom code that touched the old tables, and the interface the business sees.
Because the business process is largely unchanged on day one, a conversion is often described as the low-risk route. That is true of process disruption and misleading about effort. The work moves into custom code remediation, finance model changes and repeated technical conversion runs, and those are measurable well before a date is committed.
OMAV runs conversions on evidence: a full inventory of custom objects and add-ons, a sizing and simplification assessment, then conversion cycles in non-production until the runbook is timed and predictable.
What a conversion covers
Six workstreams, run in sequence for the assessment and in parallel thereafter.
Readiness and simplification
System analysis against SAP simplification items, add-on and business function compatibility, sizing for the target database, and a decision list for each finding rather than a report left on a shelf.
Custom code remediation
Inventory of every custom object, usage analysis to identify what can simply be retired, then remediation of what survives against the simplified data model, followed by re-testing.
Finance data model
Migration to the universal journal, reconciliation of ledgers, and validation by the finance team that balances, reporting and period close behave as they did before.
Conversion cycles
Repeated technical conversions in development and quality systems, each timed and logged, until the duration is known and the failure list is empty.
Interface and integration checks
Verification that every inbound and outbound interface still works against changed structures, with owners named on both sides of each one.
Cutover and hypercare
A rehearsed production conversion inside an agreed downtime window, followed by staffed support while month end and period close run for the first time.
How a conversion runs
Assess
Readiness check, custom code inventory, add-on compatibility and sizing. The output is a scoped remediation list with effort attached to each item.
Remediate
Retire unused objects, fix what remains, and resolve add-on and business function blockers before the first conversion is attempted.
Convert and repeat
Run the conversion in non-production, measure the runtime, fix what failed, and run it again until the result is dull and repeatable.
Validate
Business testing against the source system, with particular attention to finance reconciliation, period close and the interfaces that carry money or stock.
Cut over
Production conversion inside the agreed window against a timed runbook, then hypercare through the first close.
Conversion next to a new implementation
Choosing between a system conversion and a new implementation.
| Dimension | System conversion | New implementation |
|---|---|---|
| Configuration | Preserved | Rebuilt to standard |
| History | Carried forward in full | Opening balances and selected history |
| Process change | Deferred to a later phase | Part of the project |
| Dominant effort | Custom code and technical cycles | Design workshops and data migration |
| Business time required | Testing and validation | Design, cleansing and testing |
| Typical duration | 6 to 10 months | 9 to 14 months |
| Main risk | Carrying existing problems forward | Adoption of new process |
What a conversion will not do
A conversion does not improve a process. If purchase requisition approval is slow today because the approval matrix is wrong, it will be slow afterwards. The technical move creates the platform for improvement and nothing more, which is why deferred improvements should be scheduled rather than assumed.
It also does not reduce custom code by itself. Code that is remediated survives, and remediated code is still code that has to be maintained, tested at every upgrade and understood by whoever comes next. The conversion is the best opportunity to retire it, and that opportunity is easier to take before the remediation effort has been spent.
- A conversion preserves configuration, which is an advantage only if the configuration is still right.
- Custom code remediation is the workstream that most often sets the timeline.
- The finance data model change is not optional and needs the finance team, not only the SAP team.
- Run the conversion repeatedly in non-production until the runbook is timed and dull.
Questions buyers ask about this
How is a conversion different from a new implementation?
A conversion moves the existing system onto S/4HANA with its configuration and history intact. A new implementation builds a fresh system and migrates selected data into it. Conversion is usually faster and less disruptive to the business, but it carries forward whatever is already there, including process debt and unused custom code.
What is SAP Readiness Check and do we need it?
Readiness Check is SAP’s analysis of an existing ECC system that reports simplification items, custom code impact, add-on compatibility and sizing. It is a useful starting inventory and it is inexpensive to run, but it is a report rather than a plan. The value comes from working through each finding and deciding what to remediate, retire or accept.
What happens to our custom code?
Every custom object is checked against the simplified data model and the removed or changed transactions. Objects break most often where they read tables that no longer exist in the same form, particularly in finance and materials management. The practical approach is to retire unused objects first, which usually removes a large share of the work, then remediate what remains.
How many test cycles are needed?
Usually three to five conversion cycles in non-production. The first establishes how long the technical conversion runs and what fails. The middle cycles reduce both. The last is a rehearsal, timed end to end, with the business validating results against the source system.
Can we change processes at the same time?
It is possible but it is rarely wise. Combining conversion with process redesign means that when something behaves unexpectedly nobody can tell whether the cause is the conversion or the change. Most organisations convert first, stabilise, then take improvements in a following phase.
Marked up as FAQPage structured data, matching the visible text exactly.
Still not sure this is the right service?
Answer four questions and we will tell you which one fits — or that none of them do.
Tell us what you are trying to fix.
A short conversation about the objective, the constraints and the timing. If we are not the right fit, we will say so.