Rollouts and migrations that never bet the close on one weekend

SAP Implementation

SAP sits underneath finance, supply chain and manufacturing at once, so a rollout that goes wrong does not fail quietly. This practice delivers module implementations and S/4HANA migrations in phases small enough to reconcile and reverse, because a controlled rollout beats a fast one every time the close is on the line.

Talk to UsScope the Work
AI augmented, human governedEvidence before estimatesYour IP from day oneOne accountable owner per engagementFounded in 2011. Part of the Vinove Group500+ full-time engineers, as of September 2026NASSCOM member
Watch · the 90-second brief

Why an SAP rollout runs phase by phase

Cutover sequencing, reconciliation gates and the rollback plan behind every phase.

90 secWatch without filling in a form.
A phased SAP module rollout plan under review.90 secSample frame · video pending

01Before scoping a migration

Brownfield, greenfield or hybrid is the real question

The migration approach gets picked on vendor pressure more often than on your actual landscape. Four questions settle it against what you are carrying forward.

How much custom ABAP is load-bearing?

Heavy customisation favours brownfield, which carries existing code forward. A lighter footprint makes greenfield's clean rebuild more affordable.

Is your current configuration something you would repeat?

If years of workarounds have accumulated, greenfield is a chance to reset rather than migrate the mess forward intact.

How many entities need to move together?

A single entity can often move faster with a clean approach. Multiple entities usually favour a phased hybrid path.

What downtime can the business actually absorb?

Brownfield migrations typically need less downtime per phase than a greenfield rebuild running in parallel.

Brownfield against greenfield migration
BrownfieldGreenfield
Carries forwardExisting configuration and codeNothing, rebuilt clean
Typical durationShorter per entityLonger, but resets debt
Best fitHeavy, working customisationYears of accumulated workarounds
Downtime shapeShorter, more frequentLonger, less frequent

02Agreed before the first phase is scheduled

The ledger that keeps a rollout accountable

SAP engagements drift when phase ownership is assumed rather than written down. This ledger fixes what you bring, what we configure, what returns, and what stays under your sign-off at every gate.

  1. Your side

    You bring

    • The process the module needs to support
    • Access to the current SAP landscape and any related modules
    • The plants or business units in scope for rollout
  2. Our side

    We build

    • Module configuration matched to the documented process
    • Custom developments where standard configuration falls short
    • A phased cutover plan sequenced by plant or unit
  3. Your side

    You receive

    • A live module in production with the first phase cut over
    • User acceptance sign-off recorded per phase
    • A support runbook for the team that owns it after go-live

Never leaves you

  • The SAP landscape, its licences and its Basis support
  • The decision on rollout pace and phase sequencing
  • Sign-off authority at every cutover gate

Where the line sitsEvery phase gets a rehearsed rollback before it gets a go-live date. Reversibility is planned in, not improvised afterward.

03From landscape map to closed phase

Four stages, repeated per phase

SAP rollouts that go wrong usually skipped one of these stages under deadline pressure. This system repeats all four for every phase, however small.

  1. Map before configuring

    Existing modules, customisations and interfaces are documented so a new phase never collides with something nobody knew existed.

    The landscape as it runs today

  2. Configure and test in sequence

    Each phase configures and tests one plant, module or entity, so a defect in one phase never blocks the whole rollout.

    One plant or entity per phase

  3. Reconcile against the legacy system

    Financial and operational data are reconciled against the prior system before a phase is signed off as complete.

    Numbers that agree before cutover

  4. Rehearse rollback before go-live

    Every phase carries a rollback that has actually been run once in rehearsal, not merely written down as a plan.

    A tested way back

04What actually moves the number

Four drivers, priced from the landscape map

SAP implementation is priced against a landscape assessment, because these four factors change scope and duration by multiples.

Driver 01

Number of entities or plants in scope

A single-plant rollout is far smaller than a migration spanning a dozen legal entities with different statutory requirements.

Driver 02

Volume of custom ABAP to carry or remediate

Heavily customised landscapes take longer to migrate safely than ones running close to SAP standard configuration.

Driver 03

Data volume and quality going into cutover

Years of accumulated master data records add reconciliation time that a newer, cleaner landscape does not carry.

Driver 04

Downtime tolerance during cutover windows

A business that can absorb a longer weekend outage often completes a phase faster than one requiring near-zero downtime.

05Evidence and proof

Phases finance signed off without hesitation.

Implementation proof is a phase that reconciled clean and a plant that kept running through cutover. Every record here waits for written client approval before production.

Explore case studies
A phased S/4HANA migration sequenced by manufacturing plant.
Nexa Foundry · Industrial manufacturing, EU

An S/4HANA migration that closed nine plants without a missed deadline.

Nexa Foundry needed an S/4HANA migration that could not risk a single plant's monthly close. Phasing the cutover by plant kept every close on its normal schedule.

Plants cut over on schedule
9 of 9
Rollback plans actually invoked
Zero
Sample · pending client approval
A production planning module rolled out to a new plant.
Nexa Foundry · Industrial manufacturing, EU

A new manufacturing module rolled out without a production stoppage.

Nexa Foundry added a new plant that needed a production planning module configured to group standards inside a live SAP landscape.

Production stoppage during rollout
None recorded
Configuration decisions documented
Every one
Sample · pending client approval
Portrait of a CTO reviewing an SAP phase sign-off.

Finance signed off every phase before we cut over. Nobody upstairs lost sleep over a single one of them.

Daniel MercerCTO, Vela Ledger
Sample · pending client approval

06Read this first

When implementation is not the right entry point

Starting a rollout before the connections to surrounding systems are understood risks breaking interfaces nobody scoped. The exits are marked plainly. When implementation is justified, it runs on standard SAP tooling, transport management and a documented cutover runbook.

  • The core is fine but nothing else talks to it

    If SAP itself works and the pain is other systems disagreeing with it, integration is the more direct fix.

    SAP Integration

  • You need Basis or ABAP capacity, not a delivery team

    If your team already owns the rollout plan and needs hands, team extension fits better than a commissioned build.

    Team extension

  • The landscape has never been assessed

    Committing to a migration approach before a landscape map exists usually costs more to unwind than the assessment itself.

    Project scoping
Engagement shapes for SAP rollout work
ShapeBest whenYou directWe carry
Scoped rolloutScope and entities are already definedPhase sequencing and sign-offConfiguration and cutover delivery
Phased programmeA multi-entity migration spans yearsProgramme priorities each phaseDelivery across every phase
Team extensionYour Basis team owns the roadmapStandards and architectureNamed engineers and continuity

07Straight answers

Asked before a rollout date gets fixed.

Not answered here?

Ask us directly Or scope the work first
How is this different from SAP integration?

This practice changes the SAP core itself through configuration, module rollout or S/4HANA migration. Integration instead connects SAP to other systems without changing what SAP does internally. A migration sometimes needs both, scoped separately.

What does an SAP implementation cost?

Pricing follows the landscape assessment, driven mainly by the number of entities, custom code volume and data quality. A single-plant module rollout costs a fraction of a multi-entity S/4HANA migration.

Can you work alongside our existing SAP Basis team?

Yes, Basis ownership typically stays with your team, and this practice scopes configuration and migration work around whatever they already run.

Do you migrate custom ABAP code to S/4HANA?

Yes, custom code gets assessed for compatibility and remediated where S/4HANA requires it, documented object by object rather than migrated blind.

How do you avoid disrupting the financial close during a migration?

By phasing cutover around the close calendar and reconciling financial data against the legacy system before any phase is marked complete.

Can we roll back if a phase goes wrong?

Yes, every phase carries a rollback plan that gets rehearsed before go-live, not one that only exists on paper in case something breaks.

What happens to customisations during a future SAP upgrade?

They get catalogued during the landscape assessment with a keep, retire or rewrite verdict, so a later upgrade inherits less accumulated debt.