Underhållet av SAP ECC upphör 31 december 2027: ett pristrappsteg, inte en avstängning

Den 31 december 2027 upphör SAP med standardunderhållet (mainstream maintenance) för SAP ECC 6.0 och de övriga kärnapplikationerna i SAP Business Suite 7. Ingenting stängs av den 1 januari 2028. Ditt system fortsätter att gå, dina användare fortsätter att bokföra fakturor, och SAP säljer fortfarande support till dig. Det som ändras är hur mycket du betalar för den och vad du får.

Den skillnaden spelar roll, eftersom mycket av de råd som cirkulerar behandlar 2027 som ett stup. För de flesta företag som fortfarande kör ECC är det inte det, och det vet de: den största gruppen av kvarvarande ECC-användare planerar för 2030. Den verkliga risken är en annan. Det arbete som faktiskt avgör datumet (egen ABAP-kod, integrationer, data) avgränsas för sent, och 2030 visar sig vara lika snävt som 2027 var.

Den här artikeln är för it-chefer och SAP-ansvariga på medelstora företag, de flesta på tyskspråkiga marknader, som fortfarande kör ECC och måste bestämma hur de kommande tre åren ska se ut.

Vad SAP faktiskt har åtagit sig

Villkoren finns på SAP:s sida om underhållsstrategin och tillkännagavs första gången i februari 2020:

• Till och med 31 december 2027: standardunderhåll för kärnapplikationerna i Business Suite 7, däribland SAP ERP 6.0, på de tre senaste enhancement packages. Ligger ditt system på ett äldre enhancement package, kontrollera SAP Note 2881788 (länkad från den sidan) innan du bygger en plan på datumet 2027.
• 1 januari 2028 till 31 december 2030: valfritt förlängt underhåll (extended maintenance), med ”a premium of two percent points on the maintenance basis”. Enkelt uttryckt höjs den underhållsavgift du betalar i dag med två procentenheter.
• Om du inte tar förlängt underhåll flyttas du automatiskt till kundspecifikt underhåll (customer-specific maintenance). Vad det omfattar beskrivs i SAP Note 52505, som länkas från samma sida. Läs den innan du antar att den räcker.
• För S/4HANA har SAP åtagit sig underhåll till slutet av 2040.

Det finns ytterligare en väg för en mindre grupp. I augusti 2025 presenterade SAP SAP ERP, private edition, transition option: en tidsbegränsad prenumeration som bär ECC från 2031 till 2033 i SAP:s privata moln. Villkoren är strikta. ”Systems must be migrated to SAP ERP, private edition on SAP HANA before December 31, 2030.” HANA är den enda databas som stöds, alternativet följer bara med max success plan för 2031 till 2033, och SAP sätter ett minimum på 2 TB för system som prenumereras enligt det. SAP säger att det är avsett för ”our largest and most complex SAP ERP customers”. De ”commercially equivalent terms” som SAP erbjöd gällde kunder som band sig för private edition före slutet av 2025.

Oavsett vilken nivå du väljer, ställ en fråga skriftligt till SAP och din partner: vilka lagändringar (skatt, lön, format för e-fakturering) kommer fortfarande att nå ditt ECC-system, och fram till när. För ett tyskt företag kan enbart det svaret avgöra om det är hållbart att stanna kvar.

Vad resten av marknaden gör

DSAG, den tyskspråkiga SAP-användarföreningen, genomförde sin Investment Report 2026 med 198 svarande mellan 8 december 2025 och 21 januari 2026. Av dem kör 54 procent fortfarande ECC eller den äldre Business Suite, jämfört med 68 procent 2024.

När det gäller tidpunkten planerar nästan hälften av de svarande att gå över till S/4HANA före slutet av 2030, vilket enligt DSAG innebär att de betalar för förlängt underhåll. Ytterligare 37 procent vill gå över före slutet av 2027, och bara 4 procent siktar på 2033 och private edition transition option.

DSAG:s ordförande, Jens Hungershausen, angav skälen rakt ut: kompetensbrist, parallella förändringsprojekt och begränsade budgetar skjuter tidplanerna framåt, ”även om det leder till högre underhållskostnader”.

Offentliga upphandlare rör sig också. Vår egen genomgång av EU:s offentliga upphandlingsannonser visar ungefär 200 förfaranden för migrering till S/4HANA per halvår under 2025 och 2026, och fler än 300 under 2026 fram till början av oktober, de flesta i Tyskland. Arbetet pågår. Det är bara utspritt över en längre startbana än rubrikerna om 2027 ger intryck av.

Var arbetet faktiskt finns

Den tekniska konverteringen från ECC till S/4HANA har gott verktygsstöd från SAP och dess partner. Kör du ett lätt anpassat ECC med en handfull standardintegrationer har din integratör gjort det här många gånger, och det mesta av det som följer är inte ditt problem.

Det blir ditt problem i proportion till hur mycket du har byggt själv.

Egen ABAP-kod: där projekten halkar efter

S/4HANA är inte ECC på en ny databas. Delar av datamodellen har ändrats. Kunder och leverantörer blir affärspartner (business partners). Bokningar inom ekonomi och lager har slagits ihop till färre, bredare tabeller. Vissa transaktioner och funktioner har tagits bort eller ersatts.

Egen kod som läser tabeller direkt, förlitar sig på en exit som har flyttats eller tyst förutsätter en sorteringsordning (HANA lovar ingen om inte frågan ber om det) kan klara en syntaxkontroll och ändå göra fel. Det är den sista sorten som gör ont, eftersom den visar sig i integrationstestet eller efter driftstart, inte i kodskanningen.

Arbetssättet som fungerar:

1. Mät användningen först. Slå på användningsloggning i produktion (ABAP call monitor, transaktion SCMON) och låt den gå genom ett helt årsbokslut. I system som levt länge körs en betydande andel av de egna objekten ofta aldrig. Kod som ingen kör raderas, den migreras inte.
2. Kör analysverktygen på det som återstår. SAP:s kontroller hittar möjliga problem. De kan inte säga vilka som spelar roll för verksamheten.
3. Klassificera varje objekt. Avveckla det, ersätt det med standardfunktionalitet, rätta det på plats eller bygg om det utanför kärnan. Ett beslut per objekt, med en namngiven ansvarig i verksamheten.
4. Testa per process, inte per objekt. Att ändra koden är den billiga delen. Att visa att order till betalning och månadsbokslutet fortfarande ger samma siffror är den dyra.

Projekten halkar efter här av ett tråkigt skäl: ingen räknade tillräckligt tidigt. Mängden egen kod är bara ungefärligt känd, de som skrev den har ofta slutat, och de verkliga fynden kommer i den andra testcykeln, efter att datumet har kommunicerats internt.

Integrationer, och PI/PO på samma klocka

ECC står sällan ensamt. IDocs till lagret, RFC- och BAPI-anrop från verkstadsgolvet, platta filer till banken och skatterådgivaren, en kundportal som läser en databasvy som någon skapade 2011. Var och en av dem måste hittas, testas och i vissa fall byggas om.

Går de integrationerna genom SAP Process Integration eller Process Orchestration finns det en andra deadline på samma datum. SAP:s Architecture Center säger att PI/PO närmar sig ”the end of standard maintenance in 2027”, att kunderna kan förlänga underhållet till 2030 och att SAP:s support upphör därefter. SAP hänvisar PI/PO-kunder till SAP Integration Suite, som har en migreringsbedömning och guidebaserade verktyg för migrering.

Verktygen hjälper med standardobjekten. De talar inte om vilka integrationer som fortfarande fyller någon funktion, och egen mappningslogik behöver fortfarande en människa som läser den. Bygg inventeringen utifrån konfigurationen i mellanprogramvaran, loggarna och de schemalagda jobben, inte utifrån en enkät. Planera sedan flytten av affärssystemet och flytten av mellanprogramvaran tillsammans. Görs de efter varandra testas varje integration två gånger.

Datamigrering

Vid en systemkonvertering följer dina data med systemet, och det gör deras kvalitet också. Konverteringen till affärspartner är oftast den första krocken: dubblettkunder, leverantörer som också är kunder, adresser i fritextfält, skattenummer på fel ställe. Allt det måste städas före konverteringen, inte under den.

Vid en nyimplementering extraherar, tvättar, transformerar och läser du in, och det svåra är avstämningen. Ekonomiavdelningen godkänner när saldon och öppna poster stämmer, inte när inläsningsjobbet är klart. Bygg migreringen som repeterbar kod som du kan köra ett dussin gånger mot allt renare data, med automatisk jämförelse av resultaten vid varje körning.

Oavsett väg: arkivera först det du inte längre behöver. Mindre data ger kortare konverteringskörningar och ett kortare fönster för driftstopp.

Tillägg enligt clean core

Frestelsen i ett projekt som styrs av en deadline är att ta med varje modifiering och lova att städa upp senare. Senare kommer aldrig.

SAP:s namn på alternativet är clean core: lämna standardsystemet omodifierat och bygg tillägg mot gränssnitt som SAP publicerar och håller stabila, antingen inne i S/4HANA eller vid sidan av, på SAP Business Technology Platform. Allt kan inte vara rent från dag ett. Regeln du faktiskt kan hålla är enklare: inget nytt byggs på det gamla sättet. Varje modifiering du undviker nu är en du inte behöver testa om vid varje framtida uppgradering.

En ram för beslutet

Det finns tre realistiska vägar, och en fjärde som får mindre uppmärksamhet.

Gå i drift på S/4HANA senast 31 december 2027. Det passar företag som redan har börjat, kör ett i stort sett standardiserat system och har en partner bokad. Från i dag är det femton månader, och få ekonomiavdelningar accepterar en övergång mitt i årsbokslutet. Har analysen av den egna koden inte gjorts är det här förmodligen inte din väg.

Betala för förlängt underhåll och gå i drift senast 2030. Det är dit större delen av marknaden är på väg. Kostnaden är påslaget på två procentenheter; bekräfta med SAP hur det tillämpas om du går i drift mitt under perioden. Risken är att behandla 2030 som 2027 behandlades: som avlägset, ända tills det plötsligt inte är det.

Ta private edition transition option till 2033. Det innebär ett avtal om RISE with SAP, HANA, ditt system flyttat till SAP ERP, private edition före 31 december 2030, max success plan och minimum på 2 TB. För ett medelstort företag är det sällan det billigaste sättet att köpa tid.

Lämna SAP. För en del medelstora tillverkare och grossister är ett mindre affärssystem ett verkligt alternativ. Arbetet med integrationer och data krymper inte. Det blir den största delen av projektet.

De kommande sex månaderna, vilken väg du än väljer

Från nu till slutet av mars 2027 lönar sig allt det här, oavsett väg:

1. Bekräfta din utgångspunkt. Enhancement package, databas, underhållsavtal. Be ditt kontoteam på SAP skriftligt om de villkor för förlängt underhåll som gäller för dig.
2. Slå på användningsloggningen nu, så att den fångar årsbokslutet 2026.
3. Gör en analys av den egna koden och kom ut med en siffra, inte ett intryck: hur många objekt, hur många som används, hur många som berör de ändrade delarna av datamodellen.
4. Bygg integrationsinventeringen, inklusive allt som går genom PI/PO, med en ansvarig och ett beslut för varje integration.
5. Börja tvätta grunddata, kunder och leverantörer först.
6. Sluta lägga till modifieringar. Ny utveckling följer clean core från i dag.
7. Lägg in underhållshöjningen 2028 i budgeten för 2027 som en känd kostnad i stället för en överraskning.
8. Boka kapacitet: partnern, ditt interna SAP-team och de utvecklare som sköter systemen runt SAP. Kompetensbrist är ett av de skäl som DSAG:s medlemmar anger till att tidplanerna glider.

Räknat baklänges från driftstart 2030: testcykler och generalrepetitioner av övergången 2030, bygge och åtgärder 2029, design och datatvätt 2028, analys nu. Det finns mindre marginal i det än det ser ut.

Var du får hjälp

Vi är inga funktionella SAP-konsulter och vi genomför inga konverteringar till S/4HANA; vi arbetar vid sidan av den partner som gör det, med integrationsinventeringen och ombyggnaden av integrationer, koden för datamigrering och dess avstämning, och de applikationer som byggts runt ECC och som måste överleva flytten. Det arbetet beskrivs på vår sida om modernisering av affärssystem, och underhåll av äldre system omfattar de system som stannar där de är tills du flyttar. Vill du få systemlandskapet runt ditt affärssystem inventerat innan du skriver under på ett program, skriv till office@c9group.dev.