Doorlooptijd en projectplan van een S/4HANA-migratie per route

In mijn ervaring duurt een S/4HANA-migratie vanaf SAP ECC 12 tot 18 maanden voor een brownfield-conversie en 18 tot 24 maanden voor een greenfield-implementatie. Een selectieve datatransitie duurt 12 tot 18 maanden. Het projectplan volgt de zes fasen van SAP Activate, en de fase die het vaakst uitloopt, is maatwerkcode.

Kort antwoord: begin het plan met de SAP Readiness Check en reserveer 30 tot 40 procent van de inspanning voor data. Plan bij brownfield drie proefconversies en reken op een cutover-downtime van een weekend tot een week.

Dit artikel is de uitwerking van doorlooptijd en planning achter mijn gids over de migratie van ECC naar S/4HANA, die de routes en de ECC-deadlines behandelt. Implementeert u SAP nieuw in plaats van van ECC over te stappen, dan behandelt mijn gids over de doorlooptijd van een SAP-implementatie die situatie, met de duur per fase.

De route bepaalt de lengte. Mijn regel: greenfield als u van andere systemen overstapt of als er nieuwe processen gedefinieerd moeten worden. Brownfield als de processen gedefinieerd zijn en werken, en selectief als de processen van sommige gebieden opnieuw gedefinieerd moeten worden.

Zo lang duurt elke route in de programma's die ik heb gezien, en dit is wat hem meestal oprekt:

Route	Gebruikelijke doorlooptijd	Waar het plan omheen gebouwd is	Wat hem meestal oprekt
Brownfield (systeemconversie)	12 tot 18 maanden	Het bestaande ECC-systeem converteren met de Software Update Manager, daarna herhaalde testconversies	Aanpassing van maatwerkcode en de conversie naar business partners
Greenfield (nieuwe implementatie)	18 tot 24 maanden	Fit-to-standard-ontwerp, bouw en herhaalde datalaadcycli	Explore-workshops die uitmonden in lange lijsten met eisen, en het opschonen van data
Selectieve datatransitie	12 tot 18 maanden	Afspreken welke bedrijfscodes, eenheden en historie meegaan, daarna gespecialiseerde tools	Afbakening van data en afhankelijkheid van gespecialiseerde partners

De kalender telt net zo zwaar als de route. Voor ECC op enhancement packages 6 tot en met 8 eindigt het mainstream-onderhoud op 31 december 2027 (SAP News). Een brownfield die deze maand start, gaat live tussen oktober 2027 en april 2028, en een greenfield die nu start, landt in 2028.

De meeste plannen die vandaag worden geschreven, hebben dus enig verlengd onderhoud in het budget nodig. Neem het vanaf het begin op, niet als verrassing in jaar twee.

RISE with SAP is een commercieel pakket, geen route. Een brownfield- of selectieve overstap onder RISE landt op SAP Cloud ERP Private, de huidige naam die SAP gebruikt voor wat velen nog zoeken als S/4HANA Cloud Private Edition. De 6 tot 9 maanden die ik noem voor GROW with SAP en de 9 tot 18 maanden voor RISE gelden voor nieuwe implementaties, niet voor overstappen vanaf ECC.

SAP Activate is de implementatiemethode van SAP voor S/4HANA. Die heeft zes fasen: Discover, Prepare, Explore, Realize, Deploy en Run (SAP Activate).

Een migratie gebruikt dezelfde fasen. Wat verandert, is het werk binnen elke fase.

Het projectplan van de migratie

1. 01

   Discover

   Readiness Check, routekeuze en business case.

2. 02

   Prepare

   Plan, governance, team en eerste sandbox.

3. 03

   Explore

   Fit-to-standard- of delta-ontwerp, WRICEF-lijst afgesproken.

4. 04

   Realize

   Bouw, maatwerkcode, dataloads, testconversies.

5. 05

   Deploy

   Generale repetitie, cutover en go-live.

6. 06

   Run

   Hypercare, stabiliseren en ECC uitfaseren.

Dit bevat elke fase bij een migratie, en hier verschillen de routes:

Fase	Wat er gebeurt bij een migratie	Hoe de routes verschillen
Discover	SAP Readiness Check, routekeuze, business case, eerste beeld van maatwerkcode en data	Selectief heeft hier al een eerste databescope nodig
Prepare	Plan, governance, team, eigenaarschap van data, sandbox	Brownfield draait een eerste sandboxconversie; greenfield richt het systeem en het workshopschema in
Explore	Fit-to-standard-workshops of delta-ontwerp, WRICEF-lijst afgesproken, datamapping	Greenfield besteedt hier de meeste tijd; brownfield werkt de simplification items af die van toepassing zijn
Realize	Bouw, aanpassing van maatwerkcode, datalaadcycli, testrondes	Brownfield draait proefconversies; greenfield draait laadcycli, meestal met de Migration Cockpit
Deploy	Generale repetitie, cutover, go-live	Het downtimevenster hangt af van route, datavolume en aanpak
Run	Hypercare, stabilisatie	ECC uitfaseren en archiveren wat u hebt bewaard

WRICEF staat voor workflows, reports, interfaces, conversions, enhancements en forms. Het is de lijst van alles wat u bouwt bovenop de SAP-standaard, en het is het getal om in de gaten te houden.

In de 21 SAP-programma's die ik heb geleid of gered, is de grootste fout dat er aan het begin van de implementatie niet goed wordt gepland. Spreek in Prepare af wie eigenaar is van het opschonen van data, welke maatwerkcode wordt uitgefaseerd en wanneer elke testconversie en generale plaatsvindt. Die data worden de ruggengraat van het plan.

Brownfield: plan rond testconversies

Een brownfield-plan is gebouwd rond de conversiecyclus. De Software Update Manager converteert het systeem, en elke testrun vertelt u hoe lang de echte gaat duren en wat er breekt.

Bij brownfield plan ik drie proefconversies vóór de cutover. Elke conversie hoort te draaien op een recente kopie van productie, zodat de tijden iets betekenen. De laatste moet zich gedragen als de go-live: dezelfde volgorde, dezelfde mensen, dezelfde controles.

Het eigen plan van SAP voor de downtime-optimized aanpak lijkt daarop. Het beschrijft een sandboxrun, een run voor kwaliteitsborging, een loadverificatie op een kloon en een generale repetitie (SAP Learning). SAP merkt op dat minder runs technisch mogelijk zijn, maar het risico verhogen.

Greenfield: plan rond ontwerp en dataloads

Bij greenfield gaat de tijd naar Explore. Fit-to-standard-workshops bepalen hoeveel van de SAP-standaard u overneemt, en elk gat wordt een WRICEF-object om te bouwen, te testen en te onderhouden.

Data verhuist in laadcycli, meestal met de SAP S/4HANA Migration Cockpit. Plan meerdere volledige laadcycli, elk gevolgd door een aansluiting die de business aftekent. Mijn stap-voor-stapgids voor de Migration Cockpit behandelt staging tables, migratieobjecten en het laadproces.

Selectief: plan rond de databescope

Een selectief plan begint met een databescope. Welke bedrijfscodes, bedrijfsonderdelen en jaren historie gaan mee, en welke processen worden herontworpen.

Die scope bepaalt de tools, de gespecialiseerde partner en de testcycli. Verandert u hem laat, dan schuift de planning mee.

In mijn ervaring is maatwerkcode de fase die het vaakst uitloopt. Het is ook de meest vergeten verborgen kostenpost bij een migratie, en die behandelt mijn gids over de kosten van een S/4HANA-migratie.

Dit zijn de plekken die ik in de gaten zou houden, in deze volgorde:

1. Maatwerkcode. Teams bepalen de omvang op basis van een rapport en ontdekken de echte omvang pas als het herstel begint. In één programma bracht analyse met smartShift de maatwerkobjecten terug van 18.000 naar 3.200. Eerst uitfaseren, dan aanpassen.
2. Maatwerkobjecten die de beoordeling miste. In mijn ervaring zijn de maatwerkobjecten die de SAP Readiness Check mist, de objecten die later pijn doen. Lees mijn gids over de SAP Readiness Check voordat u de uitkomst ervan als uw scope behandelt.
3. Data. Datamigratie kost 30 tot 40 procent van de inspanning. Als het opschonen geen eigenaar heeft, begint het laat en knijpt het daarna de testcycli af. Mijn artikel over waarom SAP-datamigratie mislukt gaat dieper.
4. Explore. Budgetten worden geraakt in Explore, terwijl de WRICEF-lijst groeit. Als de leverancier de scope beheert, heeft niemand aan de kant van de leverancier een reden om die groei te stoppen.
5. Generales geschrapt om tijd te winnen. Een generale die vervalt om de datum te beschermen, kost in het go-liveweekend meestal meer tijd dan hij opleverde.

Mijn standpunt: leg de go-livedatum vast aan het eind van Explore, als de WRICEF-lijst en de scope van de maatwerkcode bekend zijn. Een datum die bij de kick-off wordt gezet, is een gok met een bestuurspresentatie eraan vast.

De cutover-downtime die ik heb gezien, varieert van een weekend tot een week. Het datavolume, de conversieaanpak, het aantal entiteiten en interfaces dat tegelijk live gaat en hoe snel de business kan valideren, bepalen allemaal de duur.

Voor brownfield biedt SAP een downtime-optimized conversieaanpak in de Software Update Manager. Die verplaatst een deel van de dataconversie en -migratie naar uptime, terwijl productie gewoon doordraait.

Gratis tijd is het niet. SAP noemt extra testruns, complexere planning, bevriezing van customizing en ontwikkeling vóór de downtime, en een expert die in de aanpak is getraind.

Spreek dus af welke downtime de business kan accepteren voordat u de technische aanpak kiest. Bewijs het daarna in de proefconversies, niet in het go-liveweekend. Houd de cutover weg van de maandafsluiting en het piekseizoen.

Een plan is maar zo goed als de aannames erachter. Dit zijn de vragen die ik zou stellen voordat iemand tekent:

1. Van welke route gaat het plan uit, en wat in onze Readiness Check-resultaten onderbouwt dat?
2. Hoeveel maatwerkobjecten zijn in scope na gebruiksanalyse, en hoeveel worden uitgefaseerd?
3. Wie is eigenaar van het opschonen van data, en in welke fase begint het?
4. Hoeveel proefconversies of laadcycli zijn gepland, en op welke data?
5. Van welke downtime gaat het plan uit, en welke testrun bewijst dat?
6. Wanneer wordt de datum vastgelegd, en wat gebeurt ermee als de WRICEF-lijst in Explore groeit?

Vraag de partner om referenties van programma's zoals het uwe en om hun high-level design. Zijn de antwoorden algemeen en niet specifiek voor uw bedrijf, behandel dat dan als een rode vlag.

Draai dit kwartaal de SAP Readiness Check. Leg de bevindingen over maatwerkcode en data voor aan de CFO en de programmadirecteur voordat iemand zich aan een go-livedatum vastlegt.

Bouw het plan daarna terug vanaf het cutovervenster dat u kunt accepteren, met drie proefconversies bij brownfield of de laadcycli die uw route nodig heeft. Wilt u eerst de route zelf toetsen, doe dan mijn migratiebeoordeling greenfield vs brownfield.

Ik help organisaties migratieplannen zoals dit op te bouwen en onder druk te testen. Wilt u een onafhankelijke blik, neem dan contact op.

Hoe lang duurt een S/4HANA-migratie?

In mijn ervaring duurt een brownfield-conversie vanaf ECC 12 tot 18 maanden, een greenfield-implementatie 18 tot 24 maanden en een selectieve datatransitie 12 tot 18 maanden. Maatwerkcode is de fase die het vaakst uitloopt, en datamigratie kost 30 tot 40 procent van de inspanning.

Wat zijn de fasen van een projectplan voor een S/4HANA-migratie?

Het plan volgt SAP Activate: Discover, Prepare, Explore, Realize, Deploy en Run. Bij een migratie bevat Discover de Readiness Check en de routekeuze, Realize de maatwerkcode, dataloads en testconversies, en Deploy de generale repetitie en de cutover.

Hoeveel proefconversies hebt u nodig voor een brownfield-migratie naar S/4HANA?

Bij brownfield plan ik drie proefconversies vóór de cutover. Voor de downtime-optimized aanpak beschrijft SAP een sandboxrun, een run voor kwaliteitsborging, een loadverificatie en een generale repetitie, en zegt SAP dat minder runs het risico verhogen.

Hoe lang duurt de cutover-downtime bij S/4HANA?

De cutover-downtime die ik heb gezien, varieert van een weekend tot een week. Die hangt af van het datavolume, de conversieaanpak en hoeveel entiteiten en interfaces tegelijk live gaan. De downtime-optimized conversie van SAP verplaatst een deel van het werk naar uptime, maar vraagt meer testruns en planning.

Kunnen we een S/4HANA-migratie afronden voordat de ECC-ondersteuning in 2027 eindigt?

Het mainstream-onderhoud voor ECC op enhancement packages 6 tot en met 8 eindigt op 31 december 2027. Een brownfield die in oktober 2026 start, gaat live tussen oktober 2027 en april 2028, en een greenfield in 2028. De meeste programma's die nu starten, zouden enig verlengd onderhoud moeten budgetteren.

Wat vertraagt S/4HANA-migratieprojecten het meest?

In mijn ervaring loopt maatwerkcode het vaakst uit, gevolgd door het opschonen van data dat te laat begint en een WRICEF-lijst die in Explore blijft groeien. Niet goed plannen aan het begin van het programma is de oorzaak van de meeste hiervan.