Waarom SAP-datamigratie mislukt en hoe u dat oplost

SAP-datamigratie mislukt om één reden vaker dan om welke andere ook: het plan is gebouwd op het beeld dat de business van haar data heeft, niet op wat een extractie laat zien. Deze gids is bedoeld voor programmadirecteuren, dataleads en financiële leidinggevenden in een S/4HANA-programma. Hij behandelt waarom migraties stuklopen, de vijf fouten achter de meeste mislukte cutovers, een mock-loadplan dat u kunt overnemen en welke SAP-tools in 2026 bij welke klus passen. Als u deze week maar één ding doet: maak een volledige extractie van uw klanten-, leveranciers- en materiaalstammen en tel zelf de records.

Een productiebedrijf besteedde 18 maanden en $4,5 miljoen aan zijn SAP-implementatie. De dag van de livegang brak aan. Iedereen was nerveus maar enthousiast. Toen mislukte de datamigratie.

Niets werkte goed. Klantgegevens ontbraken. De voorraadcijfers klopten niet. De boekhouding kon de boeken niet sluiten. De CEO was woedend.

Het lag niet aan de software en niet aan het implementatieteam. De fout zat in het gat tussen het beeld dat de business van haar data had en de werkelijkheid.

Het datamodel van SAP is geen vlakke import. Records zijn van elkaar afhankelijk. Een materiaalstam heeft een algemeen record (MARA), vestigingsgegevens (MARC), waarderingsgegevens (MBEW) en, waar MRP-gebieden worden gebruikt, MRP-gebiedsgegevens (MDMA). Laadt u de kop zonder de afhankelijke views, dan bestaat het materiaal wel maar kan het niet in een transactie worden gebruikt.

S/4HANA voegt een eigen regel toe. Klanten en leveranciers zijn business partners. Een legacyklant wordt een business partner met een klantrol, en een leverancier wordt er een met een leveranciersrol. Kredietlimieten, bankgegevens en fiscale nummers hangen aan die business partner. Een record dat een legacysysteem met hiaten tolereerde, faalt hier bij de validatie.

Dan is er het volume. De meeste bedrijven schrikken van hoeveel data ze werkelijk hebben. Eén klant dacht ongeveer 50.000 materiaalrecords te hebben. Als alle varianten en vestigingsspecifieke records werden meegeteld, kwam het aantal dichter bij 500.000. Een plan dat op het eerste getal is afgestemd, overleeft het tweede niet.

Schatting van de businessVolledige extractie

Materiaalrecords binnen de scope500,000+450,000 · +900%

Schatting van de business50,000

Volledige extractie500,000

• Elke variant en elk vestigingsspecifiek record geteld
• Een plan dat op de schatting is afgestemd, overleeft dit niet

Dat was geen datamigratieprobleem. Het was een scopingprobleem dat er een werd.

De beoordeling van de datakwaliteit aan het begin van een project is meestal een beschrijving van de data, geen onderzoek ervan. De financieel directeur zegt dat de leveranciersstam goed wordt onderhouden. De magazijnmanager zegt dat de materialen grotendeels schoon zijn. Dat zijn indrukken.

De eerste extractie vertelt u de waarheid. Leveranciers die jaren geleden hadden moeten worden opgeschoond en dat niet zijn. Materialen die al lang uit het assortiment zijn en nooit zijn gedeactiveerd. Klantadressen met inconsistente landcodes. Ontbrekende bankgegevens bij leveranciers die per bankoverschrijving worden betaald.

Elk daarvan vraagt om een besluit van de business, niet om een technische oplossing. Alleen crediteurenadministratie kan zeggen welke van twee dubbele leveranciers de juiste is. Alleen inkoop kan zeggen welke verouderde materialen u blokkeert en welke u achterlaat. Die besluiten kosten tijd en vragen om de mensen die de data kennen. Is de beoordeling niet gebaseerd op een echte extractie, dan rust het plan op aannames die het contact met de data niet overleven. Mijn gratis schatter voor datamigratie helpt de inspanning in te schatten zodra u echte aantallen hebt.

1. Migratie behandelen als een late technische taak

Migratie hoort in elke fase van SAP Activate. Explore bepaalt de scope: objecten, bronsystemen, volumes en kwaliteit. Realize bouwt de templates en voert de mock loads uit. Deploy voert de laatste repetitie en de cutover-load uit. Run stemt de eerste periodeafsluiting op live data af.

Projecten die pas in Deploy met migratiewerk beginnen, beginnen er maanden te laat mee. De kwaliteitsproblemen die in Realize hadden moeten zijn opgelost, duiken op in de eerste mock, weken voor de cutover. Mijn gids voor SAP-tijdlijnplanning laat zien waar migratie in het totaalplan thuishoort.

2. Te weinig betrokkenheid van de business

Migratie is technisch in de uitvoering en een bedrijfsactiviteit in de besluitvorming. IT kan de lijst met dubbele leveranciers niet opstellen. Welke klantaccounts als actief meegaan en welke als historie achterblijven, is een besluit van finance. Het opschonen van verouderde materialen vraagt om inkoop, magazijn en productmanagement.

Programma's die migratie alleen met technische mensen bemensen en de business pas aan het einde laten tekenen, leveren data op die laadt. Zakelijk klopt die niet.

3. Te weinig mock loads inplannen

Een goed gestuurde SAP-datamigratie heeft vóór de cutover minstens drie mock loads nodig, en complexe programma's meer. Projecten die er één of twee inplannen, plannen voor schone data en een schone mapping. Dat scenario is zeldzaam. Meer cycli zijn geen teken van een migratie in problemen. Ze zijn een teken van een goed geplande migratie.

4. Proefloads niet afstemmen

Een loadjob die zonder fouten eindigt, is geen validatie. Validatie vergelijkt wat is geladen met wat werd verwacht: aantallen records, financiële totalen, saldi van openstaande posten. Daarna bevestigt een smoke test van de processen dat de data in transacties werkt.

Een proefload die niet wordt afgestemd, kost nog steeds tijd. Het gat dat hij opleverde, is bij de volgende mock nog steeds aanwezig, alleen is het nu moeilijker terug te voeren op de oorzaak. Stem elke load af voordat u aan de volgende begint.

5. Een cutover-load die afwijkt van de repetities

De cutover-migratie moet de laatste mock exact herhalen: dezelfde extractiescripts, transformatielogica, laadvolgorde, controles en timing. Elke wijziging bij de cutover is een ongetest risico op het moment met de hoogste druk van het programma.

Het minst geteste onderdeel is meestal de delta. Tussen de laatste mock en de cutover blijft de business leveranciers toevoegen, orders wijzigen en voorraad verplaatsen. Bepaal de datum van de data freeze en repeteer de deltaload als onderdeel van de laatste mock.

Gebruik deze cyclusstructuur als uitgangspunt. Elke cyclus heeft een doel en een exitcriterium, en is pas afgerond als de afstemming is ondertekend.

Cyclus	Doel	Exitcriterium	Eigenaar
Mock 1	Structuur: elk object laadt in volgorde van afhankelijkheid	Mappinggaps en formaatfouten per object vastgelegd	Leider datamigratie
Mock 2	Kwaliteit: de mappingcorrecties testen en dataproblemen blootleggen	Foutpercentage daalt per object; opschoningsbesluiten vastgelegd	Data stewards
Mock 3	Bedrijfsregels: uitzonderingen en grensgevallen	Stewards accepteren in elk domein een afgestemde steekproef	Data stewards
Mock 4	Volume en timing op volledige productieomvang	De volledige load rondt af binnen het cutovervenster	Cutovermanager
Laatste repetitie	Generale repetitie van de cutover, inclusief delta en freeze	Aantallen en financiële totalen afgestemd en ondertekend	Financial controller en datalead

Rond dat plan maken vijf dingen het verschil:

1. Een volledige extractie in Prepare. Alles, geen steekproef. Profileer volledigheid, juistheid, consistentie en duplicaten, en bepaal op basis van de uitkomsten de omvang van de opschoning en de tijdlijn.
2. Mapping per object. Leg voor elk object (business partners, materialen, openstaande inkoop- en verkooporders, openstaande posten, voorraad, vaste activa) de velden van bron naar doel vast, plus transformatieregels, validatiecontroles en uitzonderingsregels.
3. Data stewards met naam. Finance is eigenaar van de financiële gegevens van klanten en leveranciers. Inkoop is eigenaar van de materiaalstam. Het magazijn is eigenaar van de voorraad. Elke steward tekent na elke cyclus voor zijn domein.
4. Afstemming vooraf gedefinieerd. Spreek vóór de eerste mock af welke aantallen en totalen bewijzen dat een load klopt, zodat niemand er bij de cutover over discussieert.
5. Een schriftelijke cutovervolgorde. Freeze, extractie, transformatie, load, validatie, akkoord van de business, go/no-go. Dezelfde volgorde als in de laatste repetitie.

Voor een nieuwe S/4HANA-implementatie is de SAP S/4HANA Migration Cockpit het door SAP aanbevolen hulpmiddel voor de initiële load. Sinds S/4HANA 2020 draait hij als de Fiori-app Migrate Your Data. Transactie LTMC is verouderd en bestaande LTMC-projecten kunnen alleen nog worden weergegeven. De app biedt twee aanpakken: data migreren via stagingtabellen (gevuld vanuit bestanden of met uw eigen tools) en data rechtstreeks migreren vanuit een SAP-bronsysteem. Teams op on-premise en private cloud gebruiken transactie LTMOM, de migration object modeler, om standaardobjecten aan te passen of eigen objecten te bouwen. De cockpit is gebouwd voor initiële loads, niet voor terugkerende interfaces of massawijzigingen.

SAP Data Services is het ETL-platform van SAP. Gebruik het bij grote volumes, zware transformatielogica, meerdere bronsystemen of wanneer u een herbruikbaar datakwaliteitsraamwerk wilt dat het project overleeft.

ETL-tools van derden zoals Informatica, Talend of Microsoft SSIS zijn zinvol waar de organisatie ze al in huis heeft en over de vaardigheden beschikt.

SAP Datasphere, inmiddels onderdeel van SAP Business Data Cloud, is geen migratietool. Zijn plek is de analyselaag na de go-live. Het speelt een rol als u historie in het legacysysteem laat staan en er toch over moet rapporteren.

Bij de meeste standaardimplementaties dekt de Migration Cockpit het grootste deel van de objecten. Grote volumes, sterk aangepaste legacysystemen of ongebruikelijke bronstructuren vragen meestal om Data Services of een ETL-tool ernaast. Conversies vanuit ECC zijn een andere oefening, die ik behandel in mijn migratiegids van ECC naar S/4HANA.

Wat is SAP-datamigratie?

SAP-datamigratie is het extraheren van data uit legacysystemen, ze transformeren zodat ze passen bij de structuren en regels van SAP, en ze in SAP laden als onderdeel van een implementatie of conversie. Typische objecten zijn business partners (klanten en leveranciers), materialen met vestigingsgegevens, openstaande inkoop- en verkooporders, voorraadsaldi, financiële openstaande posten en vaste activa. Het is lastig omdat SAP afhankelijkheden en validatieregels afdwingt die legacysystemen vaak niet kenden.

Wat zijn de belangrijkste aanpakken voor SAP-datamigratie?

Een nieuwe implementatie (greenfield) laadt geselecteerde stamgegevens en openstaande posten in een nieuw S/4HANA-systeem en laat de historie achter in het legacysysteem of in een archief. Een systeemconversie (brownfield) converteert een bestaand ECC-systeem en de bijbehorende historie ter plekke. Selective Data Transition zit daartussen en verplaatst gekozen bedrijfscodes, objecten of tijdsegmenten. De juiste keuze hangt af van de datakwaliteit, de eisen aan historie en hoeveel van het oude proces u wilt behouden.

Wat is de SAP Migration Cockpit en wanneer gebruikt u hem?

De SAP S/4HANA Migration Cockpit is het door SAP aanbevolen hulpmiddel voor de initiële dataload naar S/4HANA, in alle edities. Sinds S/4HANA 2020 draait hij als de Fiori-app Migrate Your Data; transactie LTMC is verouderd. Hij biedt vooraf gedefinieerde migratieobjecten, valideert data vóór het boeken en meldt fouten op veldniveau. Gebruik hem voor standaardobjecten bij normale volumes. Voeg SAP Data Services of een andere ETL-tool toe wanneer volumes, transformatielogica of bronstructuren verder gaan dan de templates aankunnen.

Op hoeveel mock loads moet een SAP-datamigratie plannen?

Minstens drie, waarvan de laatste een volledige cutoverrepetitie is. Complexe programma's hebben er meer nodig. In een typisch plan vindt de eerste structurele mappinggaps. De tweede test de correcties en legt datakwaliteitsproblemen bloot. De derde werkt bedrijfsregels en grensgevallen door. De laatste run herhaalt de cutover exact, en de afstemming ervan wordt de basislijn voor de dag van de go-live.

Hoe migreert u klanten en leveranciers naar SAP S/4HANA?

Als business partners. In S/4HANA worden de stamgegevens van klanten en leveranciers onderhouden via de business partner, met klant- en leveranciersrollen eraan gekoppeld. In een nieuwe implementatie laadt de Migration Cockpit ze via zijn business partner-objecten. Bij een conversie vanuit ECC moet de klant-leveranciersintegratie worden ingericht en uitgevoerd vóór de conversie zelf.

Wat zorgt ervoor dat SAP-datamigratie bij de cutover mislukt?

Vijf patronen veroorzaken de meeste mislukte cutovers. Te weinig mock loads. Een cutovervolgorde die nooit van begin tot eind is getest. Wijzigingen in het legacysysteem na de laatste mock, met een ongeteste deltaload. Openstaande hiaten in de afstemming. Akkoord van de business op basis van een steekproef. “De eerste 1.000 records zagen er goed uit” is geen validatie. Voor de go-live zijn afgestemde aantallen en totalen nodig.