Az SAP ECC karbantartása 2027. december 31-én véget ér: árlépcső, nem lekapcsolás

2027. december 31-én az SAP befejezi az SAP ECC 6.0 és az SAP Business Suite 7 többi alapalkalmazásának általános karbantartását (mainstream maintenance). 2028. január 1-jén semmi nem kapcsol le. A rendszere tovább fut, a felhasználói tovább könyvelik a számlákat, és az SAP továbbra is elad Önnek támogatást. Az változik, mennyit fizet érte, és mit kap.

Ez a különbség azért fontos, mert a forgalomban lévő tanácsok jó része 2027-et szakadéknak tekinti. A legtöbb, még ECC-n lévő cég számára nem az, és ezt tudják is: a megmaradt ECC-felhasználók legnagyobb csoportja 2030-ra tervez. A valódi kockázat más. Az a munka, amely ténylegesen eldönti a dátumot (az egyedi ABAP, az interfészek, az adatok), későn kerül felmérésre, és 2030 ugyanolyan szorosnak bizonyul, mint 2027 volt.

Ez a cikk középvállalatok informatikai vezetőinek és SAP-felelőseinek szól, főként a német nyelvű piacokon, akik még ECC-t futtatnak, és el kell dönteniük, hogyan néz ki a következő három év.

Mire kötelezte el magát valójában az SAP

A feltételek az SAP karbantartási stratégiáról szóló oldalán szerepelnek, és először 2020 februárjában jelentették be őket:

• 2027. december 31-ig: általános karbantartás a Business Suite 7 alapalkalmazásaira, köztük az SAP ERP 6.0-ra, a legutóbbi három bővítőcsomagon (enhancement package). Ha a rendszere régebbi bővítőcsomagon áll, nézze meg a 2881788-as SAP Note-ot (az oldal hivatkozik rá), mielőtt a 2027-es dátumra tervet építene.
• 2028. január 1. és 2030. december 31. között: választható bővített karbantartás (extended maintenance), „a karbantartási alapra vetített két százalékpontos felárral”. Egyszerűen fogalmazva: a ma fizetett karbantartási díjszázalék két ponttal nő.
• Ha nem veszi igénybe a bővített karbantartást: automatikusan ügyfélspecifikus karbantartásra (customer-specific maintenance) kerül. Hogy ez mit fed le, azt a 52505-ös SAP Note írja le, amelyre ugyanez az oldal hivatkozik. Olvassa el, mielőtt feltételezi, hogy elég lesz.
• Az S/4HANA-ra: az SAP 2040 végéig vállalt karbantartást.

Egy kisebb csoport számára van egy további út is. 2025 augusztusában az SAP bemutatta az SAP ERP, private edition, transition option nevű lehetőséget: egy időben korlátozott előfizetést, amely 2031 és 2033 között az SAP privát felhőjében viszi tovább az ECC-t. A feltételek szigorúak. „A rendszereket 2030. december 31. előtt át kell migrálni az SAP HANA-n futó SAP ERP, private editionre.” A HANA az egyetlen támogatott adatbázis, a lehetőség csak a 2031 és 2033 közötti max success csomaggal együtt vehető igénybe, és az SAP legalább 2 TB-os méretet ír elő az ennek keretében előfizetett rendszerekre. Az SAP szerint „legnagyobb és legösszetettebb SAP ERP-ügyfeleinknek” szánja. Az SAP által kínált „kereskedelmileg egyenértékű feltételek” azoknak az ügyfeleknek szóltak, akik 2025 végéig elkötelezték magukat a private edition mellett.

Bármelyik szintet választja is, tegyen fel írásban egy kérdést az SAP-nak és a partnerének: mely jogszabályi változások (adó, bérszámfejtés, e-számlázási formátumok) jutnak még el az ECC-rendszeréhez, és meddig. Egy német cégnél már ez az egy válasz eldöntheti, hogy életképes-e maradni.

Mit csinál a piac többi része

A DSAG, a német nyelvű SAP-felhasználói egyesület 2025. december 8. és 2026. január 21. között 198 válaszadóval készítette el 2026-os beruházási jelentését. Közülük 54 százalék még mindig ECC-t vagy a régebbi Business Suite-ot futtatja, szemben a 2024-es 68 százalékkal.

Az időzítést tekintve a válaszadók csaknem fele 2030 végéig tervez átállni az S/4HANA-ra, ami a DSAG megjegyzése szerint bővített karbantartási díj fizetését jelenti. További 37 százalék 2027 végéig szeretne átállni, és mindössze 4 százalék célozza meg 2033-at és a private edition transition optiont.

A DSAG elnöke, Jens Hungershausen egyenesen megnevezte az okokat: a szakemberhiány, a párhuzamos átalakítási projektek és a szűkös költségvetések tolják hátrébb az ütemterveket, „még akkor is, ha ez magasabb karbantartási költségekkel jár”.

Az állami beszerzők is mozognak. Az uniós közbeszerzési hirdetmények saját számlálásunk szerint 2025 és 2026 folyamán félévente nagyjából 200 S/4HANA-migrációs eljárást mutatnak, 2026-ban október elejéig pedig több mint 300-at, többségüket Németországban. A munka zajlik. Csak hosszabb kifutópályán oszlik el, mint amit a 2027-es szalagcímek sugallnak.

Hol van valójában a munka

Az ECC-ről S/4HANA-ra történő technikai konverzióhoz az SAP és partnerei jó eszközöket kínálnak. Ha enyhén testre szabott ECC-t futtat néhány szabványos interfésszel, az integrátora ezt már sokszor megcsinálta, és az alábbiak többsége nem az Ön problémája.

Annál inkább az Ön problémájává válik, minél többet épített saját maga.

Egyedi ABAP: itt csúsznak a projektek

Az S/4HANA nem az ECC egy új adatbázison. Az adatmodell egyes részei megváltoztak. Az ügyfelekből és a szállítókból üzleti partnerek lesznek. A pénzügyi és a készletkönyvelések kevesebb, szélesebb táblába kerültek. Egyes tranzakciókat és funkciókat eltávolítottak vagy lecseréltek.

Az az egyedi kód, amely közvetlenül olvas táblákat, egy áthelyezett exitre támaszkodik, vagy csendben feltételez egy rendezési sorrendet (a HANA nem ígér ilyet, hacsak a lekérdezés nem kéri), átmehet a szintaktikai ellenőrzésen, és mégis rosszat csinálhat. Ez az utolsó fajta fáj, mert az integrációs tesztelésben vagy az élesítés után jön elő, nem a kódellenőrzésben.

A folyamat, amely működik:

1. Először mérje a használatot. Kapcsolja be a használati naplózást az éles rendszerben (az ABAP call monitort, az SCMON tranzakciót), és hagyja futni egy teljes évzáráson át. A hosszú életű rendszerekben az egyedi objektumok jelentős része gyakran soha nem fut. Azt a kódot, amelyet senki nem futtat, törölni kell, nem migrálni.
2. A maradékon futtassa az elemzőeszközöket. Az SAP ellenőrzései lehetséges problémákat találnak. Azt nem tudják megmondani, melyik számít az üzletnek.
3. Sorolja be az összes objektumot. Kivezetés, csere standard funkcióra, helyben javítás, vagy újraépítés a magon kívül. Objektumonként egy döntés, megnevezett üzleti gazdával.
4. Folyamatonként teszteljen, ne objektumonként. A kód módosítása az olcsó rész. A drága annak bizonyítása, hogy a rendeléstől a pénzbeérkezésig tartó folyamat (order-to-cash) és a hónapzárás ugyanazokat a számokat adja.

A projektek itt egy unalmas ok miatt csúsznak: senki nem számolt elég korán. Az egyedi kód mennyiségét csak nagyjából ismerik, az írói gyakran már elmentek, a valódi megállapítások pedig a második tesztciklusban érkeznek, miután a dátumot házon belül már bejelentették.

Interfészek, és a PI/PO ugyanazon az órán

Az ECC ritkán áll egyedül. IDocok a raktár felé, RFC- és BAPI-hívások az üzemből, egyszerű szöveges fájlok a bank és az adótanácsadó felé, egy ügyfélportál, amely egy 2011-ben valaki által létrehozott adatbázisnézetet olvas. Mindegyiket meg kell találni, tesztelni kell, és némelyiket újra kell építeni.

Ha ezek az interfészek az SAP Process Integrationön vagy a Process Orchestrationön futnak, ugyanezekre a dátumokra esik egy második határidő is. Az SAP Architecture Centerje szerint a PI/PO közeledik „a standard karbantartás 2027-es végéhez”, az ügyfelek 2030-ig meghosszabbíthatják a karbantartást, utána pedig véget ér az SAP támogatása. Az SAP a PI/PO-ügyfeleket az SAP Integration Suite felé irányítja, amelyhez migrációs felmérés és varázslóalapú migrációs eszközök tartoznak.

Az eszközök a standard objektumoknál segítenek. Azt nem mondják meg, mely interfészek szolgálnak még bármit, és az egyedi leképezési logikát továbbra is el kell olvasnia valakinek. A leltárt a köztesréteg (middleware) konfigurációjából, a naplókból és az ütemezett feladatokból építse fel, ne kérdőívből. Ezután az ERP és a köztesréteg költöztetését tervezze együtt. Ha egymás után végzik, minden interfészt kétszer kell tesztelni.

Adatmigráció

Rendszerkonverziónál az adatai a rendszerrel együtt költöznek, és velük együtt a minőségük is. Az első ütközés általában az üzleti partnerekre való átalakítás: duplikált ügyfelek, szállítók, akik egyben ügyfelek is, szabad szöveges mezőkben tárolt címek, rossz helyen lévő adószámok. Mindezt a konverzió előtt kell rendbe tenni, nem közben.

Új bevezetésnél kinyer, megtisztít, átalakít és betölt, és a nehéz rész az egyeztetés. A pénzügy akkor hagyja jóvá, amikor az egyenlegek és a nyitott tételek egyeznek, nem akkor, amikor a betöltési feladat lefut. Az adatmigrációt megismételhető kódként építse meg, amelyet egyre tisztább adatokon akár tucatszor is lefuttathat, minden futásnál automatikusan összehasonlítva az eredményeket.

Mindkét úton archiválja előbb azt, amire már nincs szüksége. Kevesebb adat rövidebb konverziós futásokat és rövidebb leállási ablakot jelent.

Clean core bővítések

Egy határidő vezérelte projektben nagy a kísértés, hogy minden módosítást átvigyenek, és megígérjék, hogy később rendet raknak. A később nem jön el.

Az SAP a másik utat clean core-nak nevezi: a standard rendszert hagyja módosítatlanul, a bővítéseket pedig az SAP által közzétett és stabilan tartott interfészekre építse, akár az S/4HANA-n belül, akár mellette, az SAP Business Technology Platformon. Az első napon nem lehet minden tiszta. A ténylegesen tartható szabály egyszerűbb: semmi újat nem építenek a régi módon. Minden módosítás, amelyet most elkerül, olyan, amelyet nem kell minden jövőbeli frissítésnél újratesztelni.

Döntési keret

Három reális út van, és egy negyedik, amely kevesebb figyelmet kap.

Élesítés S/4HANA-n 2027. december 31-ig. Ez azoknak a cégeknek illik, amelyek már elkezdték, nagyrészt standard rendszert futtatnak, és van lefoglalt partnerük. Mától ez tizenöt hónap, és kevés pénzügyi csapat fogad el átállást az évzárás közepén. Ha az egyedi kód elemzése nem történt meg, valószínűleg nem ez az Ön útja.

Bővített karbantartás fizetése és élesítés 2030-ig. A piac nagy része erre tart. A költség a két pontos felár; erősíttesse meg az SAP-val, hogyan alkalmazzák, ha az időszak közepén élesít. A kockázat az, hogy 2030-at ugyanúgy kezelik, ahogy 2027-et: távolinak, amíg hirtelen már nem az.

A private edition transition option igénybevétele 2033-ig. Ez RISE with SAP szerződést, HANA-t, a rendszer 2030. december 31. előtti átköltöztetését az SAP ERP, private editionre, a max success csomagot és a 2 TB-os minimumot jelenti. Egy középvállalatnak ritkán ez a legolcsóbb módja az időnyerésnek.

Az SAP elhagyása. Egyes közepes méretű gyártóknak és forgalmazóknak egy kisebb ERP valódi lehetőség. Az interfész- és adatmunka nem lesz kisebb. A projekt nagy részévé válik.

A következő hat hónap, bármelyiket választja

Mostantól 2027 márciusának végéig az alábbiak minden úton megtérülnek:

1. Erősítse meg a kiindulópontját. Bővítőcsomag, adatbázis, karbantartási szerződés. Kérje írásban az SAP ügyfélcsapatától az Önre vonatkozó bővített karbantartási feltételeket.
2. Kapcsolja be most a használati naplózást, hogy rögzítse a 2026-os évzárást.
3. Végezzen egyedikód-elemzést, és az eredmény egy szám legyen, ne benyomás: hány objektum, ebből hány van használatban, hány érinti az adatmodell megváltozott részeit.
4. Építse fel az interfészleltárt, beleértve mindent, ami a PI/PO-n fut, minden interfészhez gazdával és döntéssel.
5. Kezdje el a törzsadatok tisztítását, elsőként az ügyfelekét és a szállítókét.
6. Ne adjon hozzá több módosítást. Mától az új fejlesztés a clean core elvet követi.
7. A 2028-as karbantartási díjemelést tegye bele a 2027-es költségvetésbe ismert költségként, ne meglepetésként.
8. Foglaljon kapacitást: a partnert, a belső SAP-csapatát, valamint azokat a fejlesztőket, akik az SAP körüli rendszerekkel foglalkoznak. A szakemberhiány az egyik ok, amelyet a DSAG tagjai a csúszó ütemtervek mögött megneveznek.

Egy 2030-as élesítéstől visszafelé számolva: tesztciklusok és átállási főpróbák 2030-ban, fejlesztés és javítás 2029-ben, tervezés és adattisztítás 2028-ban, elemzés most. Ebben kevesebb a tartalék, mint amilyennek látszik.

Hol kaphat segítséget

Nem vagyunk SAP funkcionális tanácsadó cég, és nem végzünk S/4HANA-konverziókat; a konverziót végző partner mellett dolgozunk, az interfészleltáron és az interfészek újraépítésén, az adatmigrációs kódon és annak egyeztetésén, valamint az ECC köré épült alkalmazásokon, amelyeknek túl kell élniük a költözést. Ezt a munkát az ERP-modernizációs oldalunk írja le, a régi rendszerek karbantartása pedig azokat a rendszereket fedi le, amelyek a költözésig a helyükön maradnak. Ha szeretné, hogy egy program aláírása előtt felmérjük az ERP-je körüli rendszereket, írjon az office@c9group.dev címre.