Vedlikeholdet av SAP ECC slutter 31. desember 2027: et prishopp, ikke en avstengning

Den 31. desember 2027 avslutter SAP det ordinære vedlikeholdet (mainstream maintenance) for SAP ECC 6.0 og de andre kjerneapplikasjonene i SAP Business Suite 7. Ingenting slås av 1. januar 2028. Systemet ditt fortsetter å kjøre, brukerne fortsetter å bokføre fakturaer, og SAP vil fortsatt selge deg support. Det som endres, er hva du betaler for den og hva du får.

Det skillet betyr noe, for mye av rådgivningen som sirkulerer, behandler 2027 som et stup. For de fleste selskaper som fortsatt er på ECC, er det ikke det, og det vet de: den største gruppen av gjenværende ECC-brukere planlegger for 2030. Den reelle risikoen er en annen. Arbeidet som faktisk avgjør datoen (egenutviklet ABAP, grensesnitt, data), blir avgrenset for sent, og 2030 viser seg å bli like trangt som 2027 var.

Dette er skrevet for IT-direktører og SAP-ansvarlige i mellomstore selskaper, de fleste i tyskspråklige markeder, som fortsatt kjører ECC og må bestemme hvordan de neste tre årene skal se ut.

Hva SAP faktisk har forpliktet seg til

Vilkårene står på SAPs side om vedlikeholdsstrategi og ble først kunngjort i februar 2020:

• Til 31. desember 2027: ordinært vedlikehold for kjerneapplikasjonene i Business Suite 7, blant dem SAP ERP 6.0, på de tre nyeste enhancement packages. Står systemet ditt på en eldre enhancement package, sjekk SAP Note 2881788 (lenket fra den siden) før du bygger en plan på datoen i 2027.
• 1. januar 2028 til 31. desember 2030: valgfritt utvidet vedlikehold (extended maintenance), med «et tillegg på to prosentpoeng på vedlikeholdsgrunnlaget». Enkelt sagt går vedlikeholdssatsen du betaler i dag, opp med to poeng.
• Tar du ikke utvidet vedlikehold: du går automatisk over til kundespesifikt vedlikehold (customer-specific maintenance). Hva det dekker, er beskrevet i SAP Note 52505, lenket fra den samme siden. Les den før du går ut fra at det er nok.
• For S/4HANA: SAP har forpliktet seg til vedlikehold til utgangen av 2040.

Det finnes en vei til for en mindre gruppe. I august 2025 la SAP frem SAP ERP, private edition, transition option: et tidsbegrenset abonnement som bærer ECC fra 2031 til 2033 inne i SAPs private sky. Vilkårene er strenge. «Systemene må være migrert til SAP ERP, private edition på SAP HANA før 31. desember 2030.» HANA er den eneste støttede databasen, alternativet kommer bare sammen med max success plan for 2031 til 2033, og SAP setter et minimum på 2 TB for systemer som abonneres under det. SAP sier at det er ment for «våre største og mest komplekse SAP ERP-kunder». De «kommersielt likeverdige vilkårene» SAP tilbød, gjaldt kunder som forpliktet seg til private edition innen utgangen av 2025.

Uansett hvilket nivå du velger, still SAP og partneren din ett spørsmål skriftlig: hvilke lovendringer (skatt, lønn, formater for e-faktura) vil fortsatt nå ECC-systemet ditt, og frem til når. For et tysk selskap kan det svaret alene avgjøre om det er levedyktig å bli værende.

Hva resten av markedet gjør

DSAG, brukerforeningen for SAP i tyskspråklige land, gjennomførte sin Investment Report 2026 med 198 respondenter mellom 8. desember 2025 og 21. januar 2026. Av dem kjører 54 prosent fortsatt ECC eller den eldre Business Suite, ned fra 68 prosent i 2024.

Når det gjelder tidspunkt, planlegger nesten halvparten av respondentene å gå over til S/4HANA innen utgangen av 2030, noe DSAG påpeker betyr å betale for utvidet vedlikehold. Ytterligere 37 prosent vil gå over innen utgangen av 2027, og bare 4 prosent sikter mot 2033 og private edition transition option.

DSAGs styreleder, Jens Hungershausen, ga grunnene rett ut: mangel på kompetanse, parallelle transformasjonsprosjekter og begrensede budsjetter skyver tidsplanene, «selv om dette gir høyere vedlikeholdskostnader».

Offentlige innkjøpere er også i bevegelse. Vår egen opptelling av offentlige anbudskunngjøringer i EU finner rundt 200 anskaffelser av S/4HANA-migrering per halvår gjennom 2025 og 2026, og over 300 i 2026 per begynnelsen av oktober, de fleste i Tyskland. Arbeidet skjer. Det er spredt over en lengre tidshorisont enn overskriftene om 2027 antyder.

Hvor arbeidet faktisk ligger

Den tekniske konverteringen fra ECC til S/4HANA er godt understøttet av verktøy fra SAP og partnerne. Kjører du et lett tilpasset ECC med en håndfull standardgrensesnitt, har integratoren din gjort dette mange ganger, og det meste av det som følger, er ikke ditt problem.

Det blir ditt problem i takt med hvor mye du har bygget selv.

Egenutviklet ABAP: der prosjekter sklir

S/4HANA er ikke ECC på en ny database. Deler av datamodellen er endret. Kunder og leverandører blir forretningspartnere (business partners). Bokføringer i økonomi og lager er slått sammen i færre, bredere tabeller. Noen transaksjoner og funksjoner er fjernet eller erstattet.

Egenutviklet kode som leser tabeller direkte, er avhengig av en exit som er flyttet, eller stilltiende forutsetter en sorteringsrekkefølge (HANA lover ingen med mindre spørringen ber om det), kan bestå en syntakskontroll og likevel gjøre feil ting. Det er den siste typen som gjør vondt, fordi den dukker opp i integrasjonstestingen eller etter at systemet er satt i drift, ikke i kodeskanningen.

Prosessen som fungerer:

1. Mål bruken først. Slå på bruksregistrering i produksjon (ABAP call monitor, transaksjon SCMON) og la den gå gjennom en hel årsavslutning. I systemer som har levd lenge, kjøres en betydelig andel av de egenutviklede objektene ofte aldri. Kode ingen kjører, slettes, den migreres ikke.
2. Kjør analyseverktøyene mot det som gjenstår. SAPs kontroller finner mulige problemer. De kan ikke fortelle deg hvilke som betyr noe for virksomheten.
3. Klassifiser hvert objekt. Avvikle det, erstatt det med standardfunksjonalitet, rett det på stedet, eller bygg det på nytt utenfor kjernen. Én beslutning per objekt, med en navngitt eier i virksomheten.
4. Test per prosess, ikke per objekt. Å endre koden er den billige delen. Å bevise at ordre-til-betaling og månedsavslutningen fortsatt gir de samme tallene, er den dyre delen.

Prosjekter sklir her av en kjedelig grunn: ingen telte tidlig nok. Mengden egenutviklet kode er bare grovt kjent, de som skrev den, har ofte sluttet, og de reelle funnene kommer i den andre testsyklusen, etter at datoen er kunngjort internt.

Grensesnitt, og PI/PO på samme klokke

ECC står sjelden alene. IDocs til lageret, RFC- og BAPI-kall fra produksjonen, flate filer til banken og skatterådgiveren, en kundeportal som leser et databaseview noen opprettet i 2011. Hvert eneste av dem må finnes, testes og i noen tilfeller bygges på nytt.

Går de grensesnittene gjennom SAP Process Integration eller Process Orchestration, er det en frist til på de samme datoene. SAPs Architecture Center sier at PI/PO nærmer seg «slutten på standardvedlikeholdet i 2027», at kunder kan forlenge vedlikeholdet til 2030, og at SAPs support opphører etter det. SAP viser PI/PO-kunder til SAP Integration Suite, som kommer med en migreringsvurdering og veiviserbaserte migreringsverktøy.

Verktøyene hjelper med standardobjektene. De forteller deg ikke hvilke grensesnitt som fortsatt tjener noe formål, og egenutviklet mappinglogikk trenger fortsatt et menneske som leser den. Bygg oversikten fra konfigurasjonen i mellomvaren, logger og planlagte jobber, ikke fra et spørreskjema. Planlegg deretter ERP-flyttingen og flyttingen av mellomvaren sammen. Gjøres de etter hverandre, testes hvert grensesnitt to ganger.

Datamigrering

Ved en systemkonvertering flyttes dataene dine med systemet, og det samme gjør kvaliteten deres. Konverteringen til forretningspartnere er som regel det første sammenstøtet: dupliserte kunder, leverandører som også er kunder, adresser i fritekstfelt, skattenumre på feil sted. Alt det må ryddes før konverteringen, ikke under den.

Ved en ny implementering henter du ut, renser, transformerer og laster, og den vanskelige delen er avstemmingen. Økonomiavdelingen godkjenner når saldoer og åpne poster stemmer, ikke når lastejobben er ferdig. Bygg migreringen som gjentakbar kode du kan kjøre et dusin ganger mot stadig renere data, med automatisk sammenligning av resultatene ved hver kjøring.

Uansett vei: arkiver først det dere ikke lenger trenger. Mindre data betyr kortere konverteringskjøringer og et kortere nedetidsvindu.

Clean core-utvidelser

Fristelsen i et fristdrevet prosjekt er å ta med hver modifikasjon over og love å rydde opp senere. Senere kommer ikke.

SAPs navn på alternativet er clean core: la standardsystemet være uendret og bygg utvidelser mot grensesnitt SAP publiserer og holder stabile, enten inne i S/4HANA eller ved siden av på SAP Business Technology Platform. Ikke alt kan være rent fra første dag. Regelen du faktisk kan holde, er enklere: ingenting nytt bygges på den gamle måten. Hver modifikasjon du unngår nå, er én du ikke må teste på nytt ved hver fremtidige oppgradering.

Et rammeverk for beslutningen

Det finnes tre realistiske veier, og en fjerde som får mindre oppmerksomhet.

Gå i drift på S/4HANA innen 31. desember 2027. Dette passer selskaper som allerede har startet, kjører et stort sett standard system og har en partner booket. Fra i dag er det femten måneder, og få økonomiavdelinger vil godta en overgang midt i årsavslutningen. Er analysen av egenutviklet kode ikke gjort, er dette trolig ikke din vei.

Betal for utvidet vedlikehold og gå i drift innen 2030. Det er her mesteparten av markedet er på vei. Kostnaden er tillegget på to poeng; bekreft med SAP hvordan det gjelder hvis du går i drift midt i perioden. Risikoen er å behandle 2030 slik 2027 ble behandlet: som fjernt, helt til det plutselig ikke er det.

Ta private edition transition option frem til 2033. Det betyr en RISE with SAP-kontrakt, HANA, systemet ditt flyttet til SAP ERP, private edition før 31. desember 2030, max success plan og minimumet på 2 TB. For et mellomstort selskap er det sjelden den billigste måten å kjøpe tid på.

Forlat SAP. For noen mellomstore produsenter og distributører er et mindre ERP-system et reelt alternativ. Arbeidet med grensesnitt og data krymper ikke. Det blir mesteparten av prosjektet.

De neste seks månedene, uansett hva du velger

Fra nå til utgangen av mars 2027 betaler alt dette seg på hver vei:

1. Bekreft utgangspunktet ditt. Enhancement package, database, vedlikeholdskontrakt. Be SAP-kontoteamet ditt skriftlig om vilkårene for utvidet vedlikehold som gjelder for dere.
2. Slå på bruksregistrering nå, slik at den fanger opp årsavslutningen for 2026.
3. Kjør en analyse av egenutviklet kode og kom ut med et antall, ikke et inntrykk: hvor mange objekter, hvor mange i bruk, hvor mange som berører de endrede delene av datamodellen.
4. Bygg oversikten over grensesnitt, inkludert alt som går gjennom PI/PO, med en eier og en beslutning for hvert grensesnitt.
5. Start rensingen av stamdata, kunder og leverandører først.
6. Slutt å legge til modifikasjoner. Ny utvikling følger clean core fra i dag.
7. Legg vedlikeholdspåslaget for 2028 inn i budsjettet for 2027 som en kjent kostnad i stedet for en overraskelse.
8. Book kapasitet: partneren, det interne SAP-teamet deres og utviklerne som tar seg av systemene rundt SAP. Kompetansemangel er en av grunnene DSAGs medlemmer oppgir for at tidsplanene sklir.

Regnet bakover fra oppstart i 2030: testsykluser og generalprøver på overgangen i 2030, utvikling og utbedring i 2029, design og datarensing i 2028, analyse nå. Det er mindre slakk i det enn det ser ut til.

Hvor du får hjelp

Vi er ikke et funksjonelt SAP-konsulentselskap, og vi gjennomfører ikke S/4HANA-konverteringer; vi jobber ved siden av partneren som gjør det, med oversikten over og gjenoppbyggingen av grensesnitt, koden for datamigreringen og avstemmingen av den, og applikasjonene som er bygget rundt ECC og må overleve flyttingen. Det arbeidet er beskrevet på siden vår om ERP-modernisering, og vedlikehold av eldre systemer dekker systemene som blir stående der de er til dere flytter. Vil du ha landskapet rundt ERP-systemet ditt kartlagt før du signerer et program, skriv til office@c9group.dev.