CAL & Associates

S/4HANA transformation

Decide first, then move. A transition to SAP S/4HANA is a business decision as much as a technical one, and the transition path is the last thing to settle rather than the first.

Three transition paths to a target state A current estate on the left connects to a target state on the right by three alternative routes: a new implementation, a system conversion and a selective transition. Current Target New Convert Selective Three transition paths to a target state A current estate on the left connects to a target state on the right by three alternative routes: a new implementation, a system conversion and a selective transition. Current estate Three routes New implementation System conversion Selective transition Target state

Transition approaches

Three established paths

SAP describes three established transition paths. Selecting a transition approach combines business, process, data, architecture, regulatory, operational, and technical considerations.

Three routes from the current estate to a target state A current estate on the left connects to a target state on the right by three alternative routes. A new implementation arcs above, a system conversion runs straight across, and a selective transition is drawn as a dashed route between them. Beneath the routes, a band of four inputs — business and process intent, data condition, architecture, and timing — feeds the choice. The inputs are unweighted and no route is marked as recommended. Current estate Config, code, history New implementation System conversion Selective transition Target state What you chose to carry Read together, unweighted Business intent Data condition Architecture Timing Three routes from the current estate to a target state A current estate on the left connects to a target state on the right by three alternative routes. A new implementation arcs above, a system conversion runs straight across, and a selective transition is drawn as a dashed route between them. Beneath the routes, a band of four inputs — business and process intent, data condition, architecture, and timing — feeds the choice. The inputs are unweighted and no route is marked as recommended. Current estate Config, code, history New implementation System conversion Selective transition Target state What you chose to carry Read together, unweighted · Business intent · Data condition · Architecture · Timing
The route is an output of the four inputs beneath it rather than a starting position.
  1. New implementation

    Rebuilds processes on a fresh system and migrates the data you choose to bring. Relevant where much of the current solution no longer reflects how the business works.

    Fits when little of the current solution still earns its keep.

  2. System conversion

    Moves your existing system in place, keeping configuration and history — including the parts nobody has revisited. Existing custom code comes with it, and sets the later upgrade cost.

    Fits when the current solution is sound and history must survive.

  3. Selective data transition

    Sits between the two — SAP describes shell-conversion and mix-and-match variants depending on how much of the existing solution is being reused.

    Fits when parts earn their keep and the rest should not follow.

On deployment: SAP’s current naming for its private cloud ERP offering is SAP Cloud ERP Private (previously, and still widely, referred to as SAP S/4HANA Cloud Private Edition). SAP S/4HANA Cloud Public Edition is a foundational application of SAP Cloud ERP. SAP also continues to support on-premise deployment and describes RISE with SAP as its transformation offering. The deployment choice affects how much current configuration carries forward; confirm current commercial and operating specifics with SAP directly.

Upgrade coupling across the core and extension patterns The standard SAP core is shown alongside three extension patterns: on-stack extensions with ABAP Cloud, side-by-side extensions on SAP BTP, and integration through SAP Integration Suite. Coupling to the upgrade cycle is labelled high for the core and progressively lower across the extension patterns. A band across all four states that impact analysis and regression testing are required for every pattern. Coupling to the upgrade cycle High Standard core SAP-delivered functionality Moderate On-stack extensions ABAP Cloud Lower Side-by-side extensions SAP BTP Lower Integration Integration Suite Impact analysis and regression testing Required for every pattern, including integrations Upgrade coupling across the core and extension patterns The standard SAP core is shown alongside three extension patterns: on-stack extensions with ABAP Cloud, side-by-side extensions on SAP BTP, and integration through SAP Integration Suite. Coupling to the upgrade cycle is labelled high for the core and progressively lower across the extension patterns. A band across all four states that impact analysis and regression testing are required for every pattern. Upgrade coupling Standard core SAP-delivered functionality High On-stack extensions ABAP Cloud Moderate Side-by-side extensions SAP BTP Lower Integration Integration Suite Lower Impact analysis and regression testing Required for every pattern
Clean-core patterns reduce direct core remediation. Extensions and integrations still require impact analysis and regression testing.

Clean core

The constraint that decides whether the next upgrade is routine

SAP’s clean-core guidance is that changes to standard functionality should be built outside the core through supported extensibility — side-by-side extensions on SAP Business Technology Platform, and on-stack extensions built with ABAP Cloud.

SAP has moved past treating clean core as binary: its A–D level model grades extensions from released interfaces through conditionally clean internal-object use to not-recommended techniques. We assess where custom code sits before deciding what should change.

BTP, data and AI readiness

Assessment scope

What assessment and readiness cover

These topics establish the evidence for path selection and the conditions for a workable transition. The full argument for why evidence precedes the path is set out in the Insight below.

  1. Custom-code and process inventory

    What the estate actually runs, graded by the business consequence of replacing each significant process with SAP standard.

  2. Data profiling

    What your master data will support, established before design workshops rather than discovered during them.

  3. Finance target state

    Chart of accounts, profitability analysis, legal-entity structure and the Central Finance question, positioned against where finance intends to end up.

  4. Sequencing against the calendar

    Reporting periods, filing windows and operational seasons mapped so subject-matter-expert availability is a planned constraint rather than a surprise.

  5. Integration readiness

    What belongs in SAP Integration Suite, what should stay where it is, and how integration is governed once more than one team is building.

  6. Cutover and stabilization readiness

    Dress rehearsals, data-load and reconciliation windows, period-close controls, handover and the stabilization work needed after go-live.

The full decision argument: The S/4HANA decisions worth arguing about sets out why each of these is settled before a transition path is chosen.

What we don’t publish

We don’t publish SAP maintenance or end-of-support dates. They change, they are commonly misquoted, and a date on a consultancy’s website is not a source. Check SAP’s own maintenance strategy pages, or ask us and we’ll point you at the current official statement.

Where this connects

Working through one of these decisions?

We run transition-path assessments that end with a documented recommendation.

info@cal-assoc.com

8003 Bulrush Canyon Trail, Katy, TX 77494 · the Greater Houston area