Solution blueprint
SAP ECC to S/4HANA system conversion
A conversion keeps the business processes and changes the system underneath them. That makes it a technical program with a hard cutover, and the work that decides the date is custom code and data.
The situation
A manufacturer runs a single ECC 6.0 production system covering finance, materials, sales, production and quality. The processes work and the business does not want to redesign them. Mainstream maintenance for Business Suite 7 ends at the close of 2027, so the move has to happen, and the board wants the smallest change that gets them onto a supported platform.
That points to a system conversion. The decision is not automatic, though: a conversion is only the cheaper route if the custom code and the data are in reasonable shape. The first phase exists to find out.
Constraints that shape the plan
- One production system, so there is no pilot site to learn on.
- Downtime limited to a single weekend, with no option at quarter-end or year-end.
- Custom code written over more than a decade, much of it undocumented.
- Interfaces to a warehouse system, an MES and a bank, all of which must work on Monday.
- Authorization roles built up over years and never cleaned.
- A small internal team that cannot be taken off support work full time.
What changes, and what does not
Stays
- Business processes
- Organizational structure
- Chart of accounts
- Document history
A conversion keeps the configuration and the data, so the business sees fewer changes than in a new build.
Changes
- Database (HANA)
- Data model (universal journal, material documents)
- Business Partner for customers and vendors
- Fiori launchpad and apps
- Authorization objects for new transactions
These are the changes that create the testing and training effort, even when no process changes.
Needs a decision
- Custom code: keep, fix, replace with standard or retire
- Reports: convert or rebuild in CDS and Fiori
- Interfaces: keep as-is or move to the Integration Suite
- History: keep all, or archive before conversion
Each of these is a scope decision, and each one moves the date.
The approach, phase by phase
Phase 1: Readiness
Four to six weeks. Learn what is really there before committing to a date.
-
1
Inventory the landscape
Systems, release and enhancement package levels, add-ons, industry solutions, interfaces and the batch schedule.
-
2
Run SAP Readiness Check
Produce the report against your production system and work through the simplification items that apply.
-
3
Custom code analysis
ABAP Test Cockpit with the S/4HANA checks, plus usage data from production over a full business cycle including year-end.
-
4
Data profiling and archiving view
Volumes by object, data quality issues, and what can be archived before conversion to shorten downtime.
-
5
Decide the route
Confirm that a conversion is right, or report honestly that a new implementation or selective transition fits better.
Phase 2: Prepare and design
Six to ten weeks. Fix what the readiness phase found.
-
6
Custom code remediation plan
Classify every object: in use and must fix, in use and compatible, unused and retire. Fix in priority order.
-
7
Business Partner and CVI
Design the customer and vendor conversion, including rules for records that exist as both.
-
8
Finance design
Universal journal implications, ledger setup, open item handling and the reconciliation approach.
-
9
Security and authorization design
Role changes for new transactions and Fiori apps, with a plan for testing them.
-
10
Sandbox conversion
Convert a copy of production. This is where the real duration and the real error list appear.
Phase 3: Realize and test
Eight to sixteen weeks. Do it repeatedly until it is boring.
-
11
Conversion rehearsals
At least three, each on a current copy of production, each timed and documented.
-
12
Functional testing
Scripts per process, run by business users, with defects tracked and retested.
-
13
Interface testing
End to end with the warehouse system, MES and bank, including failure cases.
-
14
Authorization testing
Role by role, including the roles people actually use rather than the ones on paper.
-
15
Performance validation
Month-end close, large reports and the batch window at production volume.
Phase 4: Deploy and run
Cutover weekend plus four to six weeks of hypercare.
-
16
Cutover runbook
Every step with an owner, a duration from the rehearsals, a checkpoint and a rollback decision point.
-
17
Dress rehearsal
The full runbook executed with the real people at the real times.
-
18
Go-live
Execute, reconcile, obtain finance sign-off, open the system.
-
19
Hypercare
Floor-walking, a triage desk, daily defect review and a date when support transitions back.
-
20
Post-conversion improvement
Fiori rollout, report rationalization and retiring the custom code that standard functions now cover.
Phase names and order change with the engagement. This is a typical shape, not a fixed method you would be held to.
Data and downtime are the same problem
Shortening the window
Most of the cutover is data work.
- Archive before conversion rather than converting history you do not need
- Use the migration option to combine database move and conversion where it applies
- Pre-process what can be done before downtime starts
- Measure every rehearsal and attack the longest step
Proving it worked
Finance signs off, not IT.
- Balances by ledger and company code, source against target
- Open items: receivables, payables, purchase orders, sales orders
- Inventory quantities and values by plant
- A reconciliation pack prepared before cutover with named approvers
The kind of team this needs
Roles can be ours, yours or shared. Where you only need people rather than a project owner, the same roles are available through staffing.
Typical deliverables
- Landscape inventory and readiness report
- Custom code classification with effort per object
- Conversion strategy and route decision memo
- Finance, security and integration design documents
- Test strategy, scripts and defect log
- Rehearsal records with timings
- Cutover runbook and rollback plan
- Reconciliation pack with finance sign-off
- Hypercare plan and support transition document
What usually goes wrong, and what we do about it
-
Custom code found late
We analyze it in phase one, with production usage data, and treat remediation as a critical-path item rather than a parallel task.
-
Downtime longer than the window
Rehearsals are timed from the first one. If the window cannot be met, we say so early, while archiving and pre-processing can still change it.
-
Authorization problems on Monday
Role testing is a named workstream, tested with the roles people actually hold.
-
Interfaces failing after go-live
Each interface is tested end to end including failure cases, and the runbook includes a check for each one before the system opens.
-
Business team not available
Testing needs business users. We agree the days with their managers in phase two, not the week before.
-
Scope creeping into redesign
A conversion that absorbs process change becomes a different project. Improvements are logged for after go-live.
Questions people ask
Could we do a new implementation instead?
Possibly, and the readiness phase is where that gets decided on evidence. See greenfield or brownfield for the factors.
Can you run this, or only staff it?
Either. Under a statement of work we own the agreed deliverables. Under staffing, our consultants work in your program under your direction.
How long does a conversion take?
For a landscape like this one, programs commonly run six to twelve months from readiness to go-live. We will not give you a number for your system before looking at your custom code and data.
What about the 2030 and 2033 dates?
Extended maintenance runs through 2030 at a premium, and SAP announced a paid transition option for 2031 to 2033 for large customers moving to RISE. Neither is the same as mainstream maintenance. Check SAP’s current maintenance pages before planning to a date.
Related
-
SAP
S/4HANA implementation and migration, Finance and Supply Chain modules, Fiori, BTP and integration, plus the architects, functional consultants, developers and Basis engineers who do the work.
-
ERP implementation
SAP, Oracle, Dynamics 365 and Workday implementations covering design, configuration, data migration, integration, testing and hypercare.
-
Data migration
Plan, extract, cleanse, map, load and reconcile data between systems, with business owners signing off every object.
-
Oracle EBS to Fusion Cloud
A finance-first re-implementation from E-Business Suite onto Oracle Fusion Cloud.
Have a technology challenge? Let’s work out the approach.
Discuss a project
Tell us the current system, the target and the timeline. A technical lead replies to talk about scope.
Start the project briefRequest technical talent
Need consultants inside your team rather than a project owner? Send the requirement.
Request talentBecome a partner
Delivery firm, staffing supplier or consulting partner? Register your company.
Register as a partner