Keep the history. Drop the baggage.
Keep the history. Drop the baggage.
Keep the history. Drop the baggage.

Selective data transition to S/4HANA — you choose what moves.

Selective transition
Slice by entity and year
Company code 1000
Company code 2000
Company code 3000
Shell client
FY 2024transfer
FY 2023transfer
FY 2022transfer
FY ≤ 2021archive
Downtime windowminimised by delta run
Selective Data TransitionShell conversionMulti-system consolidationCarve-outs
Selective transition

The third path to S/4HANA

Greenfield gives you a clean design and no history. A system conversion gives you all your history and all your legacy design. A selective data transition lets you choose: build the target the way you want it, then transfer only the entities, years and objects that earn their place.

Comparison

Greenfield, brownfield, selective

Most programmes discover the third option late, after the first two have already been priced. It is worth putting all three on the table at the start.

GreenfieldSystem conversionSelective transition
Target configurationDesigned from scratchInherited from ECCDesigned from scratch, or adopted selectively
Historical dataBalances and open items onlyEverything comes acrossYou choose: by entity, year or object
Custom codeRebuilt or droppedRemediated for S/4HANAReviewed and moved selectively
Business disruptionHigh — new processes and trainingLower — processes largely unchangedModerate — scoped to what changes
Downtime profileCutover weekend, load-boundConversion runtime, data-volume boundOptimised by delta runs, can be near-zero
Best suited toRedesign is the goalThe system is fundamentally fineConsolidation, carve-outs, selective history
Main riskChange adoption and load effortCarrying legacy problems forwardRule complexity and specialist dependency
Scenarios

When selective is the right answer

Selective transitions justify their extra complexity in a fairly narrow set of situations. These are the ones we see repeatedly.

Consolidating several ECC systems

Three regional instances becoming one global S/4HANA system. Selective transfer lets each source contribute its data under one agreed target design, instead of one system winning by default.

Carve-out or divestment

One legal entity leaving the group. Extract just that entity's data — with its history — into a separate system, without touching the systems that stay.

Keeping a few years of history

Finance needs three years of comparatives in the live system; the remaining decade belongs in an archive. Selective transfer draws that line explicitly.

Harmonising on the way over

Chart of accounts, fiscal year variant or controlling area changes applied during the transition, rather than as a separate project afterwards.

Shell conversion

Build the target from your existing configuration and repository but with no transactional data, then load exactly what you want. Familiar system, clean data.

Downtime that cannot stretch

Businesses that cannot give up a long weekend. Delta transfer techniques keep productive downtime far shorter than a full conversion of the same data volume.

Mechanics

How the slicing actually works

A selective transition is a set of rules describing which records move and how they are transformed on the way. The rules are the deliverable — and the reason this approach needs specialists rather than a standard tool.

  • By company code: whole legal entities transfer, others stay behind or go to a different target
  • By time slice: a cut-off date per object type, with open items handled separately from closed periods
  • By organisational unit: plants, sales organisations or controlling areas moved independently
  • By object: master data in full, transactional data filtered, custom tables ruled on individually
  • Delta runs: the bulk moves while the source is still productive, only the difference moves during downtime
  • Transformation in transit: account, org unit and currency mappings applied as records move, not afterwards
Our approach
Delivery

How a selective transition runs

The shape differs from a greenfield load: more analysis up front, more test transitions, and a production run that is a rehearsed repeat rather than a first attempt.

  1. 01

    Feasibility and scoping

    3–5 weeks

    Confirm selective is genuinely the right path, and price it honestly against greenfield and conversion. Includes source system analysis, data volumes, custom table inventory and a first view of the transfer rules.

    Path recommendationVolume analysisCustom object inventory
  2. 02

    Target and shell build

    4–8 weeks

    Create the target: either a fresh design or a shell carrying configuration and repository without transactional data. Ledger, currency and fiscal year settings are fixed here — they are expensive to revisit later.

    Shell systemConfig baselineFrozen settings list
  3. 03

    Rule design

    6–10 weeks

    The heart of the engagement. Selection rules per object, transformation rules for anything being harmonised, and explicit decisions on every custom table. Reviewed with the business and with audit.

    Selection rulesTransformation rulesCustom table decisions
  4. 04

    Test transitions

    3+ cycles

    Full transfer runs into a test target, each followed by reconciliation and business validation. Runtimes are measured every cycle to shape the downtime plan.

    Reconciliation resultsRuntime profileValidation sign-off
  5. 05

    Delta and production transition

    the cutover

    Bulk transfer ahead of the window where the approach allows it, then the delta during downtime. The production run repeats a sequence that has already been executed end to end.

    Cutover runbookDelta transferProduction target
  6. 06

    Validation and close

    4–8 weeks

    Reconciliation sign-off, first statutory close on the new system, and confirmation that retained history reports correctly in the periods it covers.

    Sign-off packFirst closeAudit evidence
Governance

How selective transitions are governed

Unlike greenfield and conversion, a selective transition touches the target system in ways SAP does not consider standard. Getting the governance right is part of the project.

SAP's SDT framework

SAP positions Selective Data Transition as a formal approach delivered under its own engagement framework, involving SAP's Data Management and Landscape Transformation organisation or a partner working within that framework. Confirm the arrangement before committing to a plan.

Specialist tooling

Selective transfers are executed with dedicated platforms rather than the Migration Cockpit. Established options include SNP CrystalBridge and cbs Enterprise Transformer; the choice affects licensing, timeline and who can support you afterwards.

Supportability afterwards

Agree in writing what SAP will support in the resulting system and what evidence is retained from the transfer. This is a conversation for the feasibility phase, not after go-live.

Watch items

Where selective transitions get difficult

None of these are reasons to avoid the approach. They are the things that need an answer before rule design starts.

Data model changes between ECC and S/4HANA are not one-to-one
Universal Journal, material documents and Business Partner all need explicit transformation rules, designed once and reused across every cycle.
Ledger, currency and fiscal year settings are frozen at shell creation
Treat these as a formal design gate with finance sign-off before the shell is built, not as configuration to be tuned later.
Custom tables have no standard transfer rule
A full custom object inventory during feasibility, with an explicit move, transform or drop decision recorded against every entry.
Open items that straddle the time slice boundary
Open item handling is designed separately from the period cut-off, so a partially cleared item never arrives half-transferred.
Retained history must still satisfy statutory reporting
Reporting requirements per retained year confirmed with finance and audit during scoping, then tested explicitly in the test transitions.
Deep dependency on one specialist partner
Rules, mappings and reconciliation evidence documented as project deliverables, so the resulting system remains supportable by other teams.
Questions

Frequently asked

Is selective transition officially supported by SAP?

Yes — SAP recognises it as one of the transition paths to S/4HANA alongside new implementation and system conversion, and delivers it through a defined engagement framework with its DMLT organisation or partners working inside it. Because it is not a standard tool you simply download, the governance arrangement should be confirmed early.

How much history can we bring?

Technically a lot; commercially, less than people first ask for. Each additional year adds transfer volume, test effort and reconciliation scope. Most finance teams settle on two to three years live plus an archive once they see the cost curve.

Is it cheaper than greenfield?

Not usually, and that is the wrong comparison. Selective typically costs more than a greenfield load in isolation, but it removes the separate archive project, the parallel legacy system and much of the change management burden. Compare total programme cost, not the migration line item.

Can we change our chart of accounts during the transition?

Yes — harmonisation during transfer is one of the strongest arguments for the approach. The mapping is applied as records move, which is considerably cleaner than converting a live system afterwards.

What about our custom Z-tables?

Every one gets an explicit decision: move as is, transform, or leave behind. There is no automatic handling, which is exactly why the inventory belongs in the feasibility phase rather than the build.

How long is the downtime?

Shorter than a conversion of the same data volume, because the bulk moves ahead of the window and only the delta transfers during downtime. The real number comes from your test transitions, and we quote it from measurements rather than estimates.

Not sure which path fits?

Most of our selective engagements start as a two- to three-week assessment comparing all three paths against your actual data volumes and history requirements. You get a recommendation you can take to the steering committee.

Third-party product names are referenced for orientation only and remain the trademarks of their respective owners. Tooling and engagement arrangements are confirmed per project with SAP and the selected partner.