NegzelNegzel
Contact Us
Abstract SAP S/4HANA cloud architecture rising around a central data core

01SAP TRANSFORMATION

SAP S/4HANA Consulting

Choose the Right S/4HANA Deployment Model with Us

Cloud or on premise, we run your move to SAP S/4HANA as a business programme with a schedule, budget and success criteria agreed at the start.

Let's discuss your projectExplore the models

MODEL 01 · TRANSITION

SAP S/4HANA Transition

The choice of approach, technical preparation and project delivery for a move from ECC to SAP S/4HANA.

Most organisations moving to SAP S/4HANA do not start from scratch; they bring along an SAP ECC system that has run for years, carries custom developments and holds a long data history. The real subject of the project is therefore not the new system itself, but how much of the old one comes along.

There are three routes for that decision: brownfield (in SAP’s terms, system conversion), greenfield (new implementation) and selective (selective data transition). Each carries a different duration, cost and risk; the wrong choice either drags the project out or carries technical debt into the new system for years. We make the decision with the SAP Readiness Check results, a custom code inventory and a process map, and then run the project end to end, from preparation to go-live.

In all three routes the destination is SAP S/4HANA: on premise or as SAP S/4HANA Cloud Private Edition (new name: SAP Cloud ERP Private). SAP S/4HANA Cloud Public Edition (new name: SAP Cloud ERP) can only be reached with a greenfield implementation.

Where to start?

Every transition starts by measuring the current system: the SAP Readiness Check report, a simplification item scan and a custom code inventory. Without these three, durations and budgets are guesses.

One decision, three routes

The destination is the same; the data that moves, the processes that change and the project duration differ from start to finish.

SAP ECC 6.0Current system and data history
  1. BrownfieldSystem ConversionConverted in place; data stays where it is
  2. GreenfieldNew ImplementationBuilt from scratch; master data and balances move
  3. SelectiveSelective Data TransitionSelected company codes and periods move
SAP S/4HANAOn premise or Private Edition

Decided by: data history, process change, timeline

How much of the current system comes along?

Discussing timelines and budgets before the route is decided turns into a scope debate later in the project.

  1. ECCS/4HANAall data and configuration

    Approach 01

    BrownfieldSystem Conversion

    The existing system is converted in place. SUM runs the release upgrade, the database migration with DMO if the database is not SAP HANA, and the conversion to the new data model in one procedure.

    • Historical data, open items and document numbers stay in place
    • Organisational structure and company codes are kept
    • The route with the lowest change load for users
    • Unused custom code comes along too, which is why code clean-up happens before the conversion
    • Process improvement is planned as a separate piece of work

    Best suited to: Organisations happy with their processes that want to keep their data history and are short on time before 2027.

  2. ECCS/4HANAmaster data and open balances only

    Approach 02

    GreenfieldNew Implementation

    The system is built from scratch with SAP’s standard process content. Old configuration is not inherited; only the master data and open balances that are needed move.

    • A clean break from customisations that piled up over the years
    • A move to standard processes and a clean data model
    • The chance to set up clean core from day one
    • Historical data does not move; it stays in an archive or in the old system, kept read-only
    • The route with the highest change management and training load

    Best suited to: Organisations that want to redesign their processes, have been through a merger or split, or whose current system has become overly complex.

  3. S/4HANAselected company codes and periods

    Approach 03

    SelectiveSelective Data Transition

    The middle ground. Which company codes, processes and how many years of data move is chosen item by item; it needs specialist tools and methods and runs as a separate stream of work.

    • Critical data moves, what is not needed stays behind
    • A phased go-live by company code is possible
    • Process improvement and data continuity together
    • Planning and analysis demand the most careful work
    • Specialist tools and services add to the project cost

    Best suited to: Multi-company, multi-country groups that want to simplify some units and move others as they are.

A phased fourth option

  • Alongside the three routes there is a phased option: with SAP Central Finance, the group’s financial postings first come together in one SAP S/4HANA system while each company keeps working in its own ERP.

The transition in four phases

Whatever the route, every transition goes through the same four phases; what changes is the weight and length of each.

  1. Phase 01

    Assessment

    The phase where the current system is measured and the route is chosen.

    • SAP Readiness Check analysis
    • Simplification item scan
    • Custom code and add-on inventory
    • Route decision and business case

  2. Phase 02

    Planning

    The phase where scope, teams and risks become clear.

    • Project plan and milestones
    • Resource and role plan
    • Risk analysis and downtime strategy
    • Test and training approach

  3. Phase 03

    Conversion

    The busiest phase, where the technical and functional work is done.

    • CVI and custom code remediation
    • SUM and DMO rehearsal runs
    • Data migration and reconciliation
    • Integration and acceptance testing

  4. Phase 04

    Go-live

    The phase where cutover happens and the system settles into routine.

    • Executing the cutover plan
    • End-user training
    • Hypercare period
    • Handover to the AMS support model

Sample timeline: brownfield (12 months)

The critical path runs through CVI and custom code remediation: until both are finished, a rehearsal conversion on a production copy gives no meaningful result.

  1. Readiness Check and SI-CheckMonths 1-2
  2. CVI: move to business partnerMonths 2-6 · critical path
  3. Custom code remediationMonths 3-7 · critical path
  4. Sandbox conversionMonths 4-5 · downtime measured for the first time
  5. DEV and QAS conversionMonths 6-8
  6. Test cycles (SIT, UAT)Months 8-10
  7. Rehearsal conversionsMonths 8-11 · on a production copy, at least two full runs
  8. Go-live and hypercareMonth 12
  1. CVI and custom code closed, rehearsals start (Month 7)
  2. Go-live (Month 11)

Sample timeline; duration depends on data volume, custom code size and integrations.

Sample timeline: greenfield (18 months)

The weight lies not in technical conversion but in process design and user adoption. Data preparation starts early; cleaning the master data that will move is the project’s longest tail.

  1. Discovery and target designMonths 1-4
  2. Fit-to-Standard workshopsMonths 3-8
  3. Data preparation and clean-upMonths 4-12 · critical path
  4. Configuration and developmentMonths 6-13
  5. Data load rehearsalsMonths 10-15
  6. Test cycles (SIT, UAT)Months 12-17
  7. Training and user adoptionMonths 13-18
  8. Go-live and hypercareMonths 17-18
  1. Target process design approved (Month 4)
  2. Fit-to-Standard outcomes closed (Month 8)
  3. First full data load rehearsal (Month 13)
  4. Go-live (Month 17)

Sample timeline; SAP gives an indicative 15-21 months for a single-wave greenfield implementation.

Eight items to close before a brownfield conversion

What delays a brownfield conversion is usually not the SUM run itself but the preparation before it. Some items stop the tool technically and some do not; every item that is skipped comes back during the rehearsal conversions.

  1. SAP Readiness Check

    The current system’s readiness report for SAP S/4HANA: affected functions, custom code volume, data size and add-on compatibility. The project plan is built on this report.

    Recommended

  2. Simplification item check (SI-Check)

    Runs twice inside SUM: at the start and just before downtime. Findings with return code 7 can be exempted once confirmed; return code 8 or higher must be resolved before downtime (SAP Note 2399707).

    Required

  3. CVI: move to business partner

    Customer and supplier master data move to the business partner model; this is a prerequisite for the conversion (SAP Note 2265093). In our experience on projects, this is where the most time is lost.

    Required · before SUM

  4. Custom code analysis (ATC)

    The ABAP Test Cockpit checks Z code for compatibility; it does not stop SUM. The real gain is in elimination: retiring unused developments shrinks the code that needs fixing.

    Recommended

  5. Data volume and archiving

    Archiving old documents and cleaning up technical tables cuts conversion time, the downtime window and storage costs in the cloud.

    Recommended

  6. Add-on and third-party compatibility

    Every add-on needs a conversion path to the target release; supported add-ons are listed in SAP Note 2214409. A single add-on without a path stops the conversion.

    Required

  7. Maintenance Planner

    Checks components, add-ons and business functions; if there is no valid path it does not allow the conversion, otherwise it generates the stack file for the target release.

    Required

  8. SUM and DMO run

    The release upgrade, database migration and conversion to the SAP S/4HANA data model run in one procedure. Before production we run at least two full rehearsals; downtime only becomes predictable once it has been measured in a rehearsal.

    Required

Keeping master data clean

  • Business partner data cleaned up for CVI does not stay clean on its own after go-live. SAP recommends switching on SAP MDG central governance before or at go-live; from then on, new and changed records are distributed only after approval.

ECC maintenance timeline

For organisations that keep postponing the decision, the real constraint is the calendar rather than the budget; with the average transition taking a year and a half, the window is narrower than it looks.

  1. EHP 5 and below: mainstream endedMoved to customer-specific maintenance
  2. EHP 6-8: end of mainstreamStandard maintenance for SAP ERP 6.0
  3. End of extended maintenancePaid; two points on the maintenance base
  4. End of the transition optionSelected large RISE customers, 2031-2033
  5. S/4HANA commitmentAt least one release maintained until 2040

ECC after 2030

  • SAP ERP, private edition, transition option is only for the largest and most complex RISE with SAP customers: the system must move to SAP ERP, private edition on SAP HANA before the end of 2030, be at least 2 TB in size and come with the max success plan.
  • According to SAP’s October 2026 announcement, database-specific support for SAP Business Suite 7 systems on third-party databases ends at the end of 2030; after that, these systems can only move with a greenfield implementation.

What the transition changes in practice

A move to SAP S/4HANA changes four things in day-to-day work.

  • One accounting table

    Line items from the general ledger, profit centres, fixed assets, the Material Ledger and controlling meet in one table, the Universal Journal (ACDOCA), so there is less reconciliation between ledgers.

  • Real-time reporting

    Reports read transaction data directly instead of totals tables, so current figures are available without waiting for overnight batch jobs.

  • Role-based SAP Fiori

    Users work with apps assigned to their business role instead of memorising transaction codes; approval flows come as standard.

  • A smaller data footprint

    With totals and index tables gone, data volume shrinks; in the cloud that is a direct cost item.

MODEL 02 · PUBLIC EDITION

SAP S/4HANA Cloud Public Edition

A fast, predictable cloud ERP model with standard processes, operated by SAP.

SAP S/4HANA Cloud Public Edition (SAP Cloud ERP) is a multi-tenant cloud ERP operated by SAP and licensed by subscription. Every customer runs the same software release on shared infrastructure, while each customer’s data and configuration stay separate in its own tenant.

The system comes with processes preconfigured through SAP Best Practices, so companies go live on proven processes without long analysis and design phases. SAP runs the infrastructure, backups, security patches and the two releases a year (February and August); configuration and release testing stay with the customer. SAP chooses the infrastructure provider, and the customer picks the data centre region.

The guiding principle is Fit-to-Standard: the process adapts to the system rather than the system being rewritten around the process. Specific needs are met in an extension layer without touching the core, so no pile of custom code builds up that needs fixing after every release.

Who is it for?

Companies ready to work with standard processes and few custom developments, and organisations starting from scratch. SAP positions GROW with SAP (new name: SAP GROW) for midsize companies, yet large, multi-country projects run on the public edition too. The only route to this edition is a greenfield implementation.

Shared code line, separate data

The same SAP release runs for every customer; customisation moves to the extension layer and the core stays clean.

  1. 01

    Tenants

    • Each customer's data in its own tenant
    • Configuration specific to the tenant
  2. 02

    One shared code line

    • Same release for every customer
    • Major releases in February and August
  3. 03

    Extension layer

    • Key user tools
    • ABAP Cloud (three-system landscape)
    • Side-by-side apps on SAP BTP
  4. 04

    Infrastructure and operations: SAP

    • Hosting, backups and security patches
    • Customer picks the region, SAP the infrastructure
  • Planned releasesTwo major releases a year (February, August) with monthly hotfix collections in between; a four-week test period before each major release.
  • Fast deploymentAccording to SAP, most projects go live in 5-7 months; fixed-scope SAP GROW Fast projects in 2-4 months.
  • Predictable costA subscription model with a lower upfront investment than an on-premise installation.
  • Infrastructure run by SAPHosting, backups, security patches and disaster recovery are with SAP.
  • Ready processes and localisationProcesses preconfigured with SAP Best Practices; SAP provides ready localisation for 60 countries and regions.
  • Three ways to extendKey user tools, developer extensibility with ABAP Cloud (in a three-system landscape) and side-by-side apps on SAP BTP.

End-to-end processes on one platform

The public edition is an integrated set of processes, from finance to manufacturing, running on one data model.

  • Financial management

    General ledger, period-end close, cost centre and profit centre accounting, asset accounting and group reporting.

  • Sales

    Order management, pricing, delivery and billing.

  • Sourcing and procurement

    From requisition to purchase order, from invoice processing to inventory and warehouse management.

  • Manufacturing and asset management

    Production planning, MRP and quality management; maintenance management sits under asset management.

  • Human resources

    The public edition is not an HR solution; workforce data comes from SAP SuccessFactors Employee Central through SAP Master Data Integration.

  • Sustainability

    Integrates with SAP Green Ledger for carbon accounting and SAP Sustainability Footprint Management for product footprints; both are separate products.

GROW WITH SAP

A fast-track package for the midmarket

GROW with SAP (SAP GROW) turns the move to the public edition into a packaged programme. According to SAP, a technical go-live can happen within four to six weeks; taking processes live for the business takes longer, depending on scope and data readiness. In early 2026 SAP introduced SAP GROW Fast, a fixed-scope approach, and says implementation costs in these projects are up to 40 percent lower than in conventional ERP projects.

  • Accelerated SAP ActivateA proven implementation framework and a predictable go-live calendar.
  • Ready process contentPreconfigured business scenarios and sample data for many industries.
  • SAP BTP and learning resourcesSAP BTP and SAP Build for extensions; learning resources and the community for key users and the team.

Sample timeline: greenfield on the public edition (6 months)

A sample timeline for a single-country, medium-scope implementation. The analysis phase is short; the discussion is not about how to code the process but where the standard process does not fit.

  1. Discovery and preparationMonth 1 · Discover, Prepare: scope, team, trial system
  2. Fit-to-Standard workshopsMonths 2-3 · Explore: delta list, extension needs
  3. Configuration, integration and testingMonths 3-5 · Realize: data load rehearsals
  4. Go-live and hypercareMonth 6 · Deploy (including hypercare), then Run: handover to AMS
  1. Scope and project plan approved (Month 1)
  2. Delta list closed (Month 3)
  3. Go-live (Month 5)

Sample timeline. According to SAP, most public edition projects take 5-7 months; duration depends on the number of company codes, integrations and data quality.

The public edition in four phases

  1. Phase 01

    Discovery and preparation

    A short phase where scope and teams become clear and the system is opened.

    • Gathering business requirements
    • Initial mapping to SAP Best Practices scope
    • Opening the trial system
    • Project plan, team and decision rules

  2. Phase 02

    Fit-to-Standard

    The phase where the standard process is shown live and the gaps are written down.

    • Process-based workshops
    • Delta list and solution decisions
    • Identifying extension needs
    • Defining integration and data scope

  3. Phase 03

    Configuration and testing

    The phase where decisions are built into the system and verified.

    • Fit-to-Standard configuration
    • SAP BTP extensions and integrations
    • Data migration rehearsals and reconciliation
    • Unit, integration and acceptance testing

  4. Phase 04

    Go-live

    The phase where cutover runs and the system settles into routine.

    • Final data load and cutover
    • End-user training
    • Hypercare
    • Handover to the AMS support model

Two releases a year: the 2026 calendar

On the public edition an upgrade is not a project but a routine with a calendar known in advance. A release reaches the test system first, the organisation runs regression tests in a four-week window, and then the development and production systems are upgraded.

  1. Release 2602Test 17-18 January, production 14-15 February
  2. Release 2608Test 18-19 July, production 15-16 August
  3. Hotfix collections (HFC)All year · monthly; after a one-week preview
  1. 2602 in production (Month 1.45)
  2. 2608 in production (Month 7.45)

Planned dates for the next release, 2702: test systems on 16-17 January 2027, development and production systems on 13-14 February 2027. Dates are from SAP's published schedule; SAP may change the plan.

MODEL 03 · PRIVATE EDITION

SAP S/4HANA Cloud Private Edition

RISE with SAP

A cloud transformation programme that brings software, infrastructure, process analysis and transition services into one contract.

RISE with SAP is a buying and transformation model that brings licences, hosting, maintenance, process analysis tools and transition services into one subscription commitment. At its centre is SAP S/4HANA Cloud Private Edition (SAP Cloud ERP Private): a single-tenant system dedicated to one organisation.

Alongside the core, the RISE with SAP package as renewed by SAP in 2025 includes SAP Signavio and SAP LeanIX capabilities, SAP Build, SAP HANA Cloud, SAP Master Data Governance and SAP Business Network Supplier Portal; package contents vary by contract. The system runs in an SAP data centre, on AWS, Microsoft Azure or Google Cloud, or under the customer data centre option, and in every case SAP operates it.

The end of mainstream maintenance for SAP ECC at the close of 2027 has turned this decision into an agenda item with a fixed date for most organisations. We take part in every step of the programme, from readiness analysis and target architecture to the transition and improvement after go-live.

Who is it for?

Mid-sized and large organisations that want to keep their ECC investment and custom developments but do not want to run the infrastructure themselves. It also suits companies that want licences, infrastructure and maintenance under one budget line.

One contract, four components

The ERP core, the extension platform, process analysis and the supplier network, on the infrastructure of your choice.

  1. 01

    SAP S/4HANA Cloud Private Edition

    • Single-tenant ERP core
    • Classic ABAP and industry processes
  2. 02

    Capabilities in the package

    • SAP BTP: SAP Build, SAP HANA Cloud
    • SAP Signavio and SAP LeanIX
    • SAP Business Network Supplier Portal
  3. 03

    Infrastructure choice: SAP operates

    • SAP data centre
    • AWS, Microsoft Azure, Google Cloud
    • Customer data centre

Four components inside the contract

Each component covers its own capability area; together they form one structure that reaches from the ERP core to the supplier network.

  • SAP S/4HANA Cloud Private Edition

    The programme’s ERP core. Its single-tenant set-up means classic ABAP developments and industry-specific process design can be kept.

    • A single-tenant environment for one organisation
    • Custom developments can move across
    • The customer decides when to upgrade
    • Local legal compliance packages

  • SAP Signavio

    Measures processes with real transaction data from the system, not assumptions; it makes bottlenecks visible before the transition and improvement visible after it.

    • Process mining and flow analysis
    • Industry benchmark data
    • Spotting deviations from the standard
    • Process monitoring after the transition

  • SAP BTP

    The way to keep the core clean. Specific needs are built in a separate layer on the platform instead of being embedded in the ERP.

    • Side-by-side application development
    • Low-code solutions with SAP Build
    • A data layer with SAP HANA Cloud
    • Master data with SAP Master Data Governance

  • SAP Business Network

    The digital connection layer with suppliers and trading partners; it puts document exchange on a standard footing.

    • Supplier portal and order flow
    • Electronic document exchange
    • Tracking order and invoice status
    • A shared data model on the network

INFRASTRUCTURE CHOICE

The infrastructure decision stays with you

The choice weighs the current cloud strategy, data residency requirements, regional reach and the cost model together. Whichever infrastructure is chosen, SAP operates the system; we run this assessment independently.

  • Amazon Web ServicesA wide regional network and a mature service portfolio; one provider for organisations already running workloads on AWS.
  • Microsoft AzureA natural choice for organisations working in the Microsoft ecosystem. Single sign-on with Entra ID is set up through SAP Cloud Identity Services and does not depend on the infrastructure.
  • Google CloudFor data and analytics-heavy organisations. SAP Business Data Cloud Connect for BigQuery connects SAP data to BigQuery regardless of where the ERP runs.
  • SAP data centresWhen one point of contact is preferred; infrastructure and application operations under one roof.
  • Customer data centreFor organisations bound by data residency; the system runs in the organisation’s own data centre on Dell, HPE or Lenovo hardware.
  • One budget lineLicences, infrastructure, maintenance and core services in one contract.
  • Ready for 2027A planned, controlled move before ECC mainstream maintenance ends.
  • Measurable processesSAP Signavio finds bottlenecks with real data and tracks improvement.
  • Planned innovationA major release every two years with feature packs every six months; the customer plans upgrades, SAP does the technical work, and one upgrade a year can be requested.
  • Security and complianceCertification, access management and data protection are covered at the infrastructure layer.
  • Flexible scalingUser numbers, scope and capacity adjust as the business grows.

A 12-month sample transition with SAP Activate

A sample plan for a mid-sized RISE with SAP transition. Each phase closes with a quality gate; some work is prepared in the preceding phase, for example cutover is planned in Realize and executed in Deploy.

  1. Preparation and assessmentMonths 1-3 · Discover, Prepare: Readiness Check, infrastructure and route decision
  2. Analysis and target designMonths 3-6 · Explore: Fit-to-Standard, delta list, SAP BTP architecture
  3. Realisation and testingMonths 5-10 · Realize: conversion rehearsals, data, integration, acceptance testing
  4. Go-live and hypercareMonths 10-12 · Deploy (including hypercare), then Run: handover to AMS
  1. Readiness Check and route decision (Month 3)
  2. Target design approved (Month 6)
  3. Acceptance testing complete (Month 9)
  4. Hypercare closes, handover to AMS (Month 12)

Sample timeline; duration depends on scope, the number of company codes and the chosen transition route.

SAP Activate's six phases in four steps

  1. Phase 01

    Preparation and assessment

    The phase where the current state is put into numbers and decisions are made.

    • SAP Readiness Check analysis
    • Custom code and add-on inventory
    • Interface and integration map
    • Infrastructure and route decision
    • Roadmap, team and budget plan

  2. Phase 02

    Analysis and target design

    The phase that settles where the standard is enough and where it is not.

    • Fit-to-Standard workshops
    • Delta list and solution decisions
    • Data migration strategy
    • Integration and SAP BTP architecture
    • Communication and training plan

  3. Phase 03

    Realisation and testing

    The busiest phase of the project, where the design becomes a working system.

    • Configuration and development cycles
    • Data migration rehearsals and reconciliation
    • Building SAP BTP extensions
    • Integration and user acceptance testing
    • Cutover plan and end-user training

  4. Phase 04

    Go-live and improvement

    The phase where cutover runs and the system settles into operational routine.

    • Cutover and go-live
    • Hypercare
    • Performance and workload monitoring
    • Process measurement with SAP Signavio
    • Handover to the AMS support model

COMPARISONS

Models and routes side by side

Public, private and on premise

Hosting, upgrades and the split of responsibilities differ across the three models.

CriterionPublicSAP S/4HANA Cloud Public EditionPrivateSAP S/4HANA Cloud Private EditionOn premiseSAP S/4HANA (on premise)
DeploymentMulti-tenant; everyone on the same releaseSingle-tenant system dedicated to one organisationThe organisation's own system
HostingSAP operates; SAP picks the infrastructure, the customer the regionSAP operates; SAP data centre, AWS, Azure, Google Cloud or customer data centreThe organisation's data centre or a hyperscaler under its own IaaS contract
CustomisationKey user tools, ABAP Cloud (in a three-system landscape) and side-by-side extensions on SAP BTPThe same options plus classic ABAP development; clean core is recommendedFull, including classic ABAP; clean core is recommended
UpgradesTwo major releases a year (February, August) with monthly hotfix collections; SAP sets the calendarThe customer picks the timing, SAP performs the technical upgrade; at least once every seven years to stay in mainstream maintenanceUpgrade decision and timing with the organisation; seven years of mainstream maintenance per release
Transition routeGreenfield onlyBrownfield, greenfield or selectiveBrownfield, greenfield or selective
Implementation timeMost projects 5-7 months according to SAP; 2-4 months with GROW Fast12-21 months depending on the route (SAP indicative durations)12-21 months depending on the route (SAP indicative durations)
Commercial modelSubscription (GROW with SAP)Subscription (RISE with SAP)Software licence and SAP maintenance agreement
AI capabilitiesCome with the cloud editionCome with the cloud editionSelected scenarios only with a commitment to move to the cloud
ResponsibilitiesInfrastructure, operations and releases with SAP; configuration and release testing with the customerInfrastructure and technical operations with SAP; application management with the customer or a partnerInfrastructure, operations and application management with the organisation or a partner
Typical fitCompanies ready for standard processes; GROW is positioned for midsize firmsCompanies with deep customisation or industry-specific processes, many coming from ECCOrganisations that must run their own infrastructure or face data residency limits

Brownfield, greenfield and selective

The decision rests not on one criterion but on how much each of these weighs in your organisation.

CriterionSystem ConversionBrownfieldNew ImplementationGreenfieldSelective Data TransitionSelective
Historical dataAll of it movesDoes not move; stays in the archiveAs much as the selected scope
Process changeLimited; improvement planned separatelyExtensive; move to the standardSelective; by business unit
Typical duration12-15 months15-21 months (single wave)12-18 months
Downtime windowLong; depends on data volumeShort; final data loadShort; can be phased
Custom codeMoves after remediationRe-evaluatedMoves with the selected scope
Change management loadLowHighMedium
Typical profileA company with settled processes that wants to keep its data historyA company redesigning its processes or reshaped by a merger or splitA multi-company group simplifying some units and moving others as they are

Durations are indicative ranges published by SAP (2024).

Typical duration ranges

For each route, duration falls between the lower and upper bounds SAP gives.

  1. Brownfield12-15 months
  2. Greenfield15-21 months · single wave
  3. Selective12-18 months
  1. Average transition in ASUG research: 1.5 years (Month 18)

Ranges from SAP's planning guide (2024). In ASUG's 2025 research the average transition takes a year and a half; according to Horváth's 2025 study, projects run on average 30 percent longer than planned.

GET STARTED

Which model fits you? We assess it with you.

We review your current SAP landscape, custom development load and regulatory requirements, and map out the deployment model and transition roadmap that fit you.

Request an assessment

OUTCOMES FIRST

Business outcomes

  1. 01

    A clear target architecture

    A basis for the decision that compares the public and private editions of SAP S/4HANA Cloud against business processes, integration and operating requirements.

  2. 02

    A controlled transition

    A workable programme that runs data, development, testing, training and cutover work packages in one roadmap.

  3. 03

    A sustainable core

    A measurable SAP platform, open to change through clean-core principles, with technical debt under control.

FOCUS

What do we solve?

  1. Unclear transformation scope

    We make the process, development, data and integration dependencies in your current ECC or S/4HANA landscape visible.

  2. The wrong cloud choice

    We balance the wish to standardise against the need for flexibility and base the choice between the public and private edition on evidence.

  3. Fragility after go-live

    We design the operating model, support, monitoring and continuous improvement before the project closes.

METHOD

How we work

  1. 01

    Discover

    SAP Activate's Discover and Prepare phases: we measure the current system with SAP Readiness Check, a simplification item scan and a custom code and add-on inventory, map processes and bottlenecks in joint sessions, and choose the cloud model and transition route on that basis.

  2. 02

    Decide

    Explore: we tie scope and downtime strategy, and on the public edition the delta list from the Fit-to-Standard workshops, to concrete decision records.

  3. 03

    Implement

    Realize: CVI and custom code remediation, SUM and DMO rehearsals, data migration and reconciliation, integration and acceptance testing run in one delivery plan.

  4. 04

    Safeguard

    Deploy and Run: we execute the cutover, watch the system closely through hypercare, and hand the new core over to the AMS support model and an improvement backlog.

COMMON QUESTIONS

Frequently asked questions

How do you decide between SAP S/4HANA Cloud Public Edition and Private Edition?

We decide on how well processes fit the standard, the need for custom development, integration density, regulation, the upgrade model and operating responsibilities. Rather than a single right answer, we build a target model that fits your organisation.

Will all our existing developments be moved?

No. Usage, business value and the option of returning to the standard are analysed; unnecessary code is retired and the differentiation you need is repositioned on clean-core principles.

How is go-live risk reduced?

Repeated data migrations, end-to-end tests, a cutover rehearsal, clear fallback criteria and a task-based hypercare plan run within the same programme.

When does ECC maintenance end?

For SAP ERP 6.0 with EHP 6, 7 and 8, mainstream maintenance ends on 31 December 2027; paid extended maintenance is available until 31 December 2030. Without extended maintenance, or once it ends, the system moves to customer-specific maintenance. For EHP 5 and below, mainstream maintenance ended on 31 December 2025. SAP commits to keeping at least one S/4HANA release in maintenance until 2040.

Can we get shared financial reporting without moving every company at once?

Yes, with SAP Central Finance. Companies keep running their current SAP ERP, S/4HANA or non-SAP systems while FI and CO postings are mapped to shared master data and replicated into one S/4HANA system. Whether the e-Ledger (e-Defter) runs in the source or the central system is decided at project start.

Do we need SAP MDG before moving to SAP S/4HANA?

No. The conversion does not require SAP MDG; it requires customers and suppliers on the business partner (CVI), and per SAP Note 2265093 a system without CVI is declined. SAP suggests MDG consolidation during preparation for a non-redundant master data repository, and central governance before or at go-live to keep the data clean. MDG is licensed separately.

THE COMPLETE JOURNEY

Other areas of expertise

Quick access

SAP module consulting

We provide consulting across SAP modules, from finance to manufacturing and from integration to data.

Looking for the right consultant?Find an Expert SAP Consultant
Finance8
Human resources3
Logistics11
Manufacturing7
Projects and engineering2
Platform and development4
Integration2
Data and control3