Vedligeholdelsen af SAP ECC slutter 31. december 2027: et prisspring, ikke en slukning

Den 31. december 2027 afslutter SAP den almindelige vedligeholdelse (mainstream maintenance) af SAP ECC 6.0 og de øvrige kerneapplikationer i SAP Business Suite 7. Intet slukkes 1. januar 2028. Jeres system kører videre, jeres brugere bogfører stadig fakturaer, og SAP vil stadig sælge jer support. Det, der ændrer sig, er, hvor meget I betaler for den, og hvad I får.

Den forskel betyder noget, for mange af de råd, der florerer, behandler 2027 som en klippekant. For de fleste virksomheder, der stadig kører ECC, er det ikke tilfældet, og det ved de: den største gruppe af tilbageværende ECC-brugere planlægger efter 2030. Den reelle risiko er en anden. Det arbejde, der faktisk afgør datoen (egen ABAP-kode, grænseflader, data), bliver afgrænset for sent, og 2030 viser sig at være lige så stramt, som 2027 var.

Denne artikel er til it-direktører og SAP-ansvarlige i mellemstore virksomheder, de fleste på tysktalende markeder, der stadig kører ECC og skal beslutte, hvordan de næste tre år skal se ud.

Hvad SAP faktisk har forpligtet sig til

Vilkårene står på SAP's side om vedligeholdelsesstrategi og blev første gang meldt ud i februar 2020:

• Indtil 31. december 2027: almindelig vedligeholdelse af kerneapplikationerne i Business Suite 7, heriblandt SAP ERP 6.0, på de seneste tre enhancement packages. Står jeres system på en ældre enhancement package, så tjek SAP Note 2881788 (linket fra den side), før I bygger en plan på datoen i 2027.
• 1. januar 2028 til 31. december 2030: valgfri udvidet vedligeholdelse (extended maintenance) mod »et tillæg på to procentpoint på vedligeholdelsesgrundlaget«. Kort sagt stiger den vedligeholdelsessats, I betaler i dag, med to procentpoint.
• Tager I ikke udvidet vedligeholdelse: går I automatisk over til kundespecifik vedligeholdelse (customer-specific maintenance). Hvad den dækker, er beskrevet i SAP Note 52505, linket fra samme side. Læs den, før I går ud fra, at den er nok.
• For S/4HANA: SAP har forpligtet sig til vedligeholdelse indtil udgangen af 2040.

Der findes endnu en vej for en mindre gruppe. I august 2025 lancerede SAP SAP ERP, private edition, transition option: et tidsbegrænset abonnement, der fører ECC fra 2031 til 2033 inde i SAP's private cloud. Betingelserne er strenge. »Systemer skal være migreret til SAP ERP, private edition på SAP HANA før 31. december 2030.« HANA er den eneste understøttede database, muligheden fås kun sammen med supportplanen max success for 2031 til 2033, og SAP kræver mindst 2 TB for systemer, der abonneres under den. SAP siger, at den er tænkt til »vores største og mest komplekse SAP ERP-kunder«. De »kommercielt tilsvarende vilkår«, som SAP tilbød, gjaldt kunder, der forpligtede sig til private edition inden udgangen af 2025.

Uanset hvilket niveau I vælger, så stil SAP og jeres partner ét spørgsmål skriftligt: hvilke lovændringer (skat, løn, formater til e-fakturering) vil stadig nå jeres ECC-system, og indtil hvornår. For en tysk virksomhed kan det svar alene afgøre, om det er realistisk at blive, hvor man er.

Hvad resten af markedet gør

DSAG, den tysksprogede SAP-brugergruppe, gennemførte sin Investment Report 2026 med 198 respondenter mellem 8. december 2025 og 21. januar 2026. Af dem kører 54 procent stadig ECC eller den ældre Business Suite, ned fra 68 procent i 2024.

Hvad angår tidspunktet, planlægger næsten halvdelen af respondenterne at skifte til S/4HANA inden udgangen af 2030, hvilket ifølge DSAG betyder, at de skal betale for udvidet vedligeholdelse. Yderligere 37 procent vil skifte inden udgangen af 2027, og kun 4 procent sigter mod 2033 og private edition transition option.

DSAG's formand, Jens Hungershausen, gav grundene ligeud: mangel på kompetencer, parallelle transformationsprojekter og begrænsede budgetter skubber tidsplanerne, »selv hvis det medfører højere vedligeholdelsesomkostninger«.

Offentlige indkøbere bevæger sig også. Vores egen optælling af EU-udbudsbekendtgørelser finder omkring 200 udbud om migrering til S/4HANA pr. halvår gennem 2025 og 2026 og mere end 300 i 2026 ved begyndelsen af oktober, de fleste i Tyskland. Arbejdet sker. Det er bare spredt over en længere startbane, end overskrifterne om 2027 antyder.

Hvor arbejdet faktisk ligger

Den tekniske konvertering fra ECC til S/4HANA er godt understøttet af værktøjer fra SAP og partnerne. Kører I et let tilpasset ECC med en håndfuld standardgrænseflader, har jeres integrator gjort det her mange gange, og det meste af det følgende er ikke jeres problem.

Det bliver jeres problem i takt med, hvor meget I selv har bygget.

Egen ABAP-kode: hvor projekterne skrider

S/4HANA er ikke ECC på en ny database. Dele af datamodellen er ændret. Kunder og leverandører bliver til forretningspartnere (business partners). Bogføringer i økonomi og lager er samlet i færre, bredere tabeller. Nogle transaktioner og funktioner er fjernet eller erstattet.

Egen kode, der læser tabeller direkte, afhænger af en exit, der er flyttet, eller stiltiende forudsætter en sorteringsrækkefølge (HANA lover ingen, medmindre forespørgslen beder om det), kan bestå en syntakskontrol og stadig gøre det forkerte. Det er den sidste slags, der gør ondt, fordi den viser sig i integrationstest eller efter go live og ikke i kodescanningen.

Den proces, der virker:

1. Mål brugen først. Slå brugslogning til i produktion (ABAP call monitor, transaktion SCMON), og lad den køre gennem en fuld årsafslutning. I systemer med lang levetid kører en betragtelig del af de egne objekter ofte aldrig. Kode, som ingen udfører, slettes, den migreres ikke.
2. Kør analyseværktøjerne mod det, der er tilbage. SAP's kontroller finder mulige problemer. De kan ikke fortælle jer, hvilke der betyder noget for forretningen.
3. Klassificér hvert objekt. Udfas det, erstat det med standardfunktionalitet, ret det på stedet, eller byg det om uden for kernen. Én beslutning pr. objekt, med en navngiven forretningsansvarlig.
4. Test efter proces, ikke efter objekt. At ændre koden er den billige del. At bevise, at order-to-cash og månedsafslutningen stadig giver de samme tal, er den dyre del.

Projekter skrider her af en kedelig grund: ingen talte op tidligt nok. Mængden af egen kode kendes kun omtrent, de personer, der skrev den, er ofte gået, og de reelle fund kommer i den anden testcyklus, efter at datoen er meldt ud internt.

Grænseflader, og PI/PO på samme ur

ECC står sjældent alene. IDocs til lageret, RFC- og BAPI-kald fra produktionen, flade filer til banken og revisoren, en kundeportal, der læser et databaseview, som nogen oprettede i 2011. Hver eneste af dem skal findes, testes og i nogle tilfælde bygges om.

Kører de grænseflader gennem SAP Process Integration eller Process Orchestration, er der en anden frist på de samme datoer. SAP's Architecture Center siger, at PI/PO nærmer sig »afslutningen på standardvedligeholdelsen i 2027«, at kunderne kan forlænge vedligeholdelsen indtil 2030, og at SAP's support slutter derefter. SAP henviser PI/PO-kunder til SAP Integration Suite, som kommer med en migreringsvurdering og guidebaserede migreringsværktøjer.

Værktøjerne hjælper med standardobjekterne. De fortæller jer ikke, hvilke grænseflader der stadig tjener et formål, og egen mappinglogik kræver stadig en person, der læser den. Byg overblikket ud fra middlewarekonfiguration, logs og planlagte job, ikke ud fra et spørgeskema. Planlæg derefter flytningen af ERP og af middleware sammen. Gøres de én efter én, bliver hver grænseflade testet to gange.

Datamigrering

Ved en systemkonvertering flytter jeres data med systemet, og det gør deres kvalitet også. Konverteringen til forretningspartnere er som regel det første sammenstød: dubletter blandt kunderne, leverandører der også er kunder, adresser i fritekstfelter, skattenumre det forkerte sted. Alt det skal renses før konverteringen, ikke under den.

Ved en ny implementering udtrækker, renser, transformerer og indlæser I, og den svære del er afstemningen. Økonomiafdelingen godkender, når saldi og åbne poster stemmer, ikke når indlæsningsjobbet er færdigt. Byg migreringen som gentagelig kode, som I kan køre en halv snes gange mod stadig renere data, med automatisk sammenligning af resultaterne ved hver kørsel.

Uanset vej skal I først arkivere det, I ikke længere har brug for. Mindre data betyder kortere konverteringskørsler og et kortere nedetidsvindue.

Udvidelser efter clean core

Fristelsen i et projekt styret af en deadline er at tage hver modifikation med over og love at rydde op senere. Senere kommer aldrig.

SAP's navn for alternativet er clean core: lad standardsystemet være uændret, og byg udvidelser mod grænseflader, som SAP offentliggør og holder stabile, enten inde i S/4HANA eller ved siden af på SAP Business Technology Platform. Ikke alt kan være rent fra første dag. Den regel, man faktisk kan holde, er enklere: intet nyt bygges på den gamle måde. Hver modifikation, I undgår nu, er en, I ikke skal genteste ved hver fremtidig opgradering.

En beslutningsramme

Der er tre realistiske veje og en fjerde, der får mindre opmærksomhed.

Gå i drift på S/4HANA senest 31. december 2027. Det passer til virksomheder, der allerede er i gang, kører et overvejende standardiseret system og har en partner booket. Fra i dag er det femten måneder, og få økonomiafdelinger vil acceptere en omstilling midt i årsafslutningen. Er analysen af jeres egen kode ikke lavet, er det her sandsynligvis ikke jeres vej.

Betal for udvidet vedligeholdelse, og gå i drift senest 2030. Det er her, det meste af markedet er på vej hen. Omkostningen er tillægget på to procentpoint; få bekræftet hos SAP, hvordan det beregnes, hvis I går i drift midt i perioden. Risikoen er at behandle 2030, som 2027 blev behandlet: som fjernt, indtil det pludselig ikke er.

Tag private edition transition option frem til 2033. Det betyder en RISE with SAP-kontrakt, HANA, jeres system flyttet til SAP ERP, private edition før 31. december 2030, supportplanen max success og minimummet på 2 TB. For en mellemstor virksomhed er det sjældent den billigste måde at købe tid på.

Forlad SAP. For nogle mellemstore producenter og distributører er et mindre ERP-system en reel mulighed. Arbejdet med grænseflader og data bliver ikke mindre. Det bliver det meste af projektet.

De næste seks måneder, uanset hvad I vælger

Fra nu og til udgangen af marts 2027 betaler alt dette sig på enhver vej:

1. Bekræft jeres udgangspunkt. Enhancement package, database, vedligeholdelseskontrakt. Bed jeres SAP-kundeteam skriftligt om de vilkår for udvidet vedligeholdelse, der gælder for jer.
2. Slå brugslogning til nu, så den fanger årsafslutningen for 2026.
3. Kør en analyse af jeres egen kode, og kom ud med et tal, ikke et indtryk: hvor mange objekter, hvor mange i brug, hvor mange der rører de ændrede dele af datamodellen.
4. Byg overblikket over grænseflader, inklusive alt, der kører gennem PI/PO, med en ejer og en beslutning for hver grænseflade.
5. Start rensningen af stamdata, kunder og leverandører først.
6. Stop med at tilføje modifikationer. Ny udvikling følger clean core fra i dag.
7. Sæt stigningen i vedligeholdelse for 2028 ind i budgettet for 2027 som en kendt omkostning og ikke en overraskelse.
8. Book kapacitet: partneren, jeres interne SAP-team og de udviklere, der passer systemerne omkring SAP. Mangel på kompetencer er en af de grunde, DSAG's medlemmer angiver for skridende tidsplaner.

Talt baglæns fra go live i 2030: testcyklusser og generalprøver på omstillingen i 2030, udvikling og udbedring i 2029, design og datarensning i 2028, analyse nu. Der er mindre luft i det, end det ser ud til.

Hvor I kan få hjælp

Vi er ikke et funktionelt SAP-konsulenthus, og vi gennemfører ikke S/4HANA-konverteringer; vi arbejder ved siden af den partner, der gør, med overblikket over og ombygningen af grænseflader, koden til datamigrering og dens afstemning samt de applikationer, der er bygget omkring ECC og skal overleve flytningen. Det arbejde er beskrevet på vores side om ERP-modernisering, og vedligeholdelse af ældre systemer dækker de systemer, der bliver, hvor de er, indtil I flytter. Vil I have systemlandskabet omkring jeres ERP-system talt op, før I skriver under på et program, så skriv til office@c9group.dev.