SAP S/4HANA Implementation
An SAP S/4HANA implementation is the design, configuration, data migration and cutover that puts SAP’s current-generation ERP into live operation. OMAV runs greenfield, brownfield and selective transition projects, from fit-to-standard workshops through to hypercare after go-live.
Putting S/4HANA into live operation
An S/4HANA implementation is the work that takes SAP’s current-generation ERP from a licence agreement to a system the business actually runs on. It covers process design, configuration, data migration, integration with the surrounding application estate, testing, cutover and the support period immediately after go-live.
The difficulty is rarely the software. Implementations run long because process decisions stay open, because master data turns out to be in worse condition than anyone expected, and because integrations that were assumed to be reconnections turn out to be rebuilds. Each of those is discoverable early and expensive late.
OMAV runs implementations that front-load those discoveries. Fit-to-standard design establishes where the business will adopt standard SAP process and where it genuinely differs. Data profiling starts in the first weeks rather than the last. Integration inventory is treated as a deliverable, not an assumption.
What an implementation covers
Six workstreams run in parallel through most of the project. They are staffed differently and they fail differently.
Fit-to-standard design
Workshops that walk the business through standard S/4HANA process and record where it fits, where it needs configuration and where a genuine gap exists. Gaps are costed before they are approved, so custom development is a decision rather than a default.
Landscape and provisioning
Sizing, the development, quality and production systems, transport routes, and the decision between on-premise, private cloud and public cloud deployment. Set up early enough that the build team is never waiting on infrastructure.
Configuration and build
Configuration of finance, controlling, procurement, sales, and where relevant production planning and warehouse management, plus the ABAP and Fiori development that the approved gaps require.
Data migration
Profiling legacy data, agreeing what transfers and what stays in an archive, cleansing at source, then repeated load cycles into the quality system. Each cycle is measured, and the load is not considered ready until it is boring.
Integration
Interfaces to banking, tax, logistics providers, plant systems, e-commerce and any surrounding applications, built and tested as their own workstream with named owners on both sides.
Test, cutover and hypercare
Unit, integration and user acceptance testing, a rehearsed cutover with a timed runbook, and a staffed hypercare period after go-live while the business learns the system under real volume.
How an implementation runs
Discovery and fit-gap
Current process, system landscape, custom code inventory and data condition assessed. The output is a scope with known gaps rather than an assumption of standard fit.
Design sign-off
Fit-to-standard workshops close with signed process designs, an approved gap list with costs, and a data migration scope. Open decisions here are the main source of later delay.
Build and unit test
Configuration, development and interface build proceed in sprints against the signed design, with the first data load cycle running alongside rather than afterwards.
Integration and UAT
End-to-end business processes tested with migrated data by the people who will run them, and defects worked down to an agreed threshold before cutover is confirmed.
Cutover and hypercare
A rehearsed, timed cutover over a defined window, then a staffed support period at go-live volume until incident rates settle and the system is handed to support.
Greenfield, brownfield and selective transition
How the three implementation approaches differ.
| Dimension | Greenfield | Brownfield | Selective transition |
|---|---|---|---|
| Starting point | A new system, designed to standard | The existing ECC system, converted in place | A new system, with chosen data and configuration carried across |
| Process change | Substantial and intentional | Minimal at the point of conversion | Selective, by entity or process area |
| Historical data | Opening balances and defined history | Carried forward in full | Chosen per entity |
| Custom code | Rebuilt only where justified | Remediated for the new data model | Reviewed and reduced |
| Typical duration | 9 to 14 months | 6 to 10 months | 10 to 16 months |
| Best suited to | Accumulated process debt, or a genuine reset | A clean system where the configuration still fits | Mixed estates and phased group rollouts |
| Main risk | Change adoption across the business | Carrying existing problems into the new system | Complexity of the transition tooling and rules |
What an implementation will not fix
An ERP implementation does not repair a process the business has not agreed on. Where two divisions run incompatible order-to-cash processes and neither will change, the system will either hold both, at cost, or the disagreement will surface during user acceptance testing, at greater cost. That decision belongs to the business before design closes.
Nor does it clean data on its own. Migration tooling moves what it is given. If customer, material and vendor master data are duplicated or incomplete in the source, the same records arrive in S/4HANA faster than before. Cleansing is a business activity with a business owner, and it is the single most common reason a go-live date moves.
- Fit-to-standard first. Custom code is justified only where a process genuinely differentiates the business.
- Data migration and master data quality decide the go-live date more often than configuration does.
- Greenfield, brownfield and selective transition are three different projects, not three labels for one.
- Hypercare belongs in the plan. Budget four to eight weeks of it before the team disperses.
Questions buyers ask about this
How long does an S/4HANA implementation take?
Mid-market scope covering finance, procurement and sales usually runs six to fourteen months from kick-off to go-live. Manufacturing, multiple legal entities or several country rollouts extend that. The variables that move the date most are decision latency on process design, the state of master data, and how many integrations have to be rebuilt rather than reconnected.
Should we go greenfield or brownfield?
Greenfield suits organisations whose current processes carry enough accumulated workarounds that carrying them forward would be a liability. Brownfield suits a clean ECC system where the configuration still fits the business and the priority is the technical move. Selective data transition sits between the two, and is chosen when some entities need a fresh start while others must keep history. The decision should follow an assessment of the existing system rather than a preference stated at the outset.
Do we have to move to the cloud?
No. S/4HANA runs on-premise, in a private cloud and in a public cloud edition. The public cloud edition constrains configuration and custom code more tightly in exchange for a faster start and a managed upgrade cycle. Organisations with heavy industry-specific requirements or tight integration to plant systems more often choose private cloud or on-premise.
What happens to our ECC custom code?
It is inventoried, classified and then reduced. A typical ECC system carries a large body of custom objects, of which a meaningful share is unused, duplicated, or now covered by standard S/4HANA functionality. What remains is remediated for the simplified data model and re-tested. Treating custom code as a deliverable in its own right, early, prevents it from becoming the reason a cutover slips.
How much of our own team’s time will this take?
More than most plans allow for. Process owners are needed in design workshops, in data cleansing and in user acceptance testing, and those are the same people who run the current operation. An implementation that assumes business participation is free is the most common reason a realistic plan turns into a late one.
Is the 2027 deadline real?
SAP mainstream maintenance for Business Suite 7, including ECC, runs to the end of 2027, with optional extended maintenance at additional cost to the end of 2030. SAP has committed to maintenance and innovation for S/4HANA until 2040. The dates are real, but they mark a maintenance boundary rather than a switch-off. They matter mainly because implementation capacity becomes scarcer and more expensive as they approach.
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.