SAP ECC:n ylläpito päättyy 31. joulukuuta 2027: hinnankorotus, ei sammutus

SAP lopettaa 31. joulukuuta 2027 SAP ECC 6.0:n ja muiden SAP Business Suite 7:n ydinsovellusten perusylläpidon (mainstream maintenance). Mikään ei sammu 1. tammikuuta 2028. Järjestelmäsi toimii edelleen, käyttäjäsi kirjaavat yhä laskuja, ja SAP myy sinulle edelleen tukea. Muuttuu se, kuinka paljon siitä maksat ja mitä sillä saat.

Ero on tärkeä, koska suuri osa liikkeellä olevista neuvoista käsittelee vuotta 2027 jyrkänteenä. Useimmille ECC:tä yhä käyttäville yrityksille se ei ole, ja ne tietävät sen: suurin jäljellä olevien ECC-käyttäjien ryhmä suunnittelee vuotta 2030. Todellinen riski on toinen. Työ, joka oikeasti ratkaisee päivämäärän (räätälöity ABAP, rajapinnat, data), rajataan myöhään, ja vuosi 2030 osoittautuu yhtä tiukaksi kuin 2027 oli.

Tämä on kirjoitettu keskisuurten yritysten tietohallintojohtajille ja SAP-vastaaville, joista useimmat toimivat saksankielisillä markkinoilla, jotka käyttävät yhä ECC:tä ja joiden on päätettävä, miltä seuraavat kolme vuotta näyttävät.

Mihin SAP on oikeasti sitoutunut

Ehdot ovat SAP:n ylläpitostrategiasivulla, ja ne julkistettiin ensimmäisen kerran helmikuussa 2020:

• 31. joulukuuta 2027 asti: Business Suite 7:n ydinsovellusten, muun muassa SAP ERP 6.0:n, perusylläpito kolmella viimeisimmällä enhancement packagella. Jos järjestelmäsi on vanhemmalla enhancement packagella, tarkista SAP Note 2881788 (linkki samalla sivulla) ennen kuin rakennat suunnitelman vuoden 2027 päivämäärän varaan.
• 1. tammikuuta 2028 ja 31. joulukuuta 2030 välillä: valinnainen laajennettu ylläpito (extended maintenance) ”kahden prosenttiyksikön lisähinnalla ylläpidon perusteesta”. Yksinkertaisesti sanottuna tänään maksamasi ylläpitoprosentti nousee kahdella yksiköllä.
• Jos et ota laajennettua ylläpitoa: siirryt automaattisesti asiakaskohtaiseen ylläpitoon (customer-specific maintenance). Sen kattavuus kuvataan SAP Notessa 52505, johon on linkki samalla sivulla. Lue se ennen kuin oletat sen riittävän.
• S/4HANA: SAP on sitoutunut ylläpitoon vuoden 2040 loppuun asti.

Pienemmälle ryhmälle on vielä yksi reitti. Elokuussa 2025 SAP esitteli SAP ERP, private edition, transition option -vaihtoehdon: määräaikaisen tilauksen, joka kantaa ECC:n vuodesta 2031 vuoteen 2033 SAP:n yksityisessä pilvessä. Ehdot ovat tiukat. ”Järjestelmät on siirrettävä SAP ERP, private editioniin SAP HANAn päällä ennen 31. joulukuuta 2030.” HANA on ainoa tuettu tietokanta, vaihtoehto on saatavilla vain yhdessä max success -suunnitelman kanssa vuosiksi 2031, 2032 ja 2033, ja SAP asettaa sen piiriin tilattaville järjestelmille 2 TB:n vähimmäiskoon. SAP:n mukaan se on tarkoitettu ”suurimmille ja monimutkaisimmille SAP ERP -asiakkaillemme”. SAP:n tarjoamat ”kaupallisesti vastaavat ehdot” koskivat asiakkaita, jotka sitoutuivat private editioniin vuoden 2025 loppuun mennessä.

Valitsitpa minkä tason tahansa, esitä SAP:lle ja kumppanillesi yksi kysymys kirjallisesti: mitkä lakimuutokset (verotus, palkanlaskenta, verkkolaskuformaatit) tulevat yhä ECC-järjestelmääsi ja mihin asti. Saksalaiselle yritykselle pelkkä tämä vastaus voi ratkaista, onko paikallaan pysyminen mahdollista.

Mitä muu markkina tekee

Saksankielinen SAP-käyttäjäyhdistys DSAG toteutti Investment Report 2026 -kyselyn, johon vastasi 198 yritystä 8. joulukuuta 2025 ja 21. tammikuuta 2026 välisenä aikana. Heistä 54 prosenttia käyttää yhä ECC:tä tai vanhempaa Business Suitea, kun vuonna 2024 osuus oli 68 prosenttia.

Ajoituksen osalta lähes puolet vastaajista aikoo siirtyä S/4HANAan vuoden 2030 loppuun mennessä, mikä DSAG:n mukaan tarkoittaa laajennetusta ylläpidosta maksamista. Toiset 37 prosenttia haluavat siirtyä vuoden 2027 loppuun mennessä, ja vain 4 prosenttia tähtää vuoteen 2033 ja private editionin siirtymävaihtoehtoon.

DSAG:n puheenjohtaja Jens Hungershausen kertoi syyt suoraan: osaajapula, rinnakkaiset muutosprojektit ja rajalliset budjetit siirtävät aikatauluja, ”vaikka se johtaisi korkeampiin ylläpitokustannuksiin”.

Myös julkiset hankkijat liikkuvat. Oman laskelmamme mukaan EU:n julkisissa hankintailmoituksissa on vuosina 2025 ja 2026 ollut noin 200 S/4HANA-siirtomenettelyä puolivuosittain, ja vuonna 2026 yli 300 lokakuun alkuun mennessä, suurin osa Saksassa. Työ on käynnissä. Se on vain jakautunut pidemmälle aikajanalle kuin vuoden 2027 otsikot antavat ymmärtää.

Missä työ oikeasti on

Tekninen konversio ECC:stä S/4HANAan on SAP:n ja sen kumppanien hyvin työkaluttama. Jos käytät kevyesti räätälöityä ECC:tä ja kourallista vakiorajapintoja, integraattorisi on tehnyt tämän monta kertaa, eikä suurin osa seuraavasta ole sinun ongelmasi.

Siitä tulee sinun ongelmasi sitä mukaa, kuinka paljon olet rakentanut itse.

Räätälöity ABAP: siinä projektit venyvät

S/4HANA ei ole ECC uudella tietokannalla. Osa tietomallista on muuttunut. Asiakkaista ja toimittajista tulee liikekumppaneita (business partner). Talouden ja varaston kirjaukset on yhdistetty harvempiin, leveämpiin tauluihin. Joitakin transaktioita ja toimintoja on poistettu tai korvattu.

Räätälöity koodi, joka lukee tauluja suoraan, nojaa siirtyneeseen exitiin tai olettaa hiljaisesti lajittelujärjestyksen (HANA ei lupaa sellaista, ellei kysely sitä pyydä), voi läpäistä syntaksitarkistuksen ja silti tehdä väärin. Juuri tämä viimeinen laji sattuu, koska se tulee esiin integraatiotestauksessa tai käyttöönoton jälkeen eikä koodiskannauksessa.

Toimiva prosessi:

1. Mittaa käyttö ensin. Kytke käyttölokitus päälle tuotannossa (ABAP call monitor, transaktio SCMON) ja anna sen olla päällä koko tilinpäätöksen ajan. Pitkäikäisissä järjestelmissä huomattava osa räätälöidyistä objekteista ei usein koskaan aja. Koodi, jota kukaan ei suorita, poistetaan eikä siirretä.
2. Aja analyysityökalut jäljelle jäävää vasten. SAP:n tarkistukset löytävät mahdollisia ongelmia. Ne eivät pysty kertomaan, mitkä ovat liiketoiminnalle merkityksellisiä.
3. Luokittele jokainen objekti. Poista se, korvaa se vakiotoiminnallisuudella, korjaa se paikallaan tai rakenna se uudelleen ytimen ulkopuolelle. Yksi päätös objektia kohden, ja nimetty liiketoiminnan omistaja.
4. Testaa prosesseittain, älä objekteittain. Koodin muuttaminen on halpa osa. Sen todistaminen, että tilauksesta maksuun -prosessi ja kuukauden sulkeminen tuottavat yhä samat luvut, on kallis osa.

Projektit venyvät tässä tylsästä syystä: kukaan ei laskenut ajoissa. Räätälöidyn koodin määrä tunnetaan vain karkeasti, sen kirjoittajat ovat usein lähteneet, ja todelliset havainnot saapuvat toisessa testikierroksessa sen jälkeen, kun päivämäärä on jo ilmoitettu sisäisesti.

Rajapinnat ja PI/PO samassa aikataulussa

ECC on harvoin yksin. IDocit varastoon, RFC- ja BAPI-kutsut tuotannosta, tasatiedostot pankkiin ja veroneuvojalle, asiakasportaali, joka lukee jonkun vuonna 2011 luomaa tietokantanäkymää. Jokainen niistä on löydettävä ja testattava ja joissakin tapauksissa rakennettava uudelleen.

Jos nämä rajapinnat kulkevat SAP Process Integrationin tai Process Orchestrationin kautta, samoille päivämäärille osuu toinen määräaika. SAP:n Architecture Center toteaa, että PI/PO lähestyy ”vakioylläpidon päättymistä vuonna 2027”, että asiakkaat voivat jatkaa ylläpitoa vuoteen 2030 ja että SAP:n tuki päättyy sen jälkeen. SAP ohjaa PI/PO-asiakkaat SAP Integration Suiteen, jonka mukana tulee siirron arviointi ja ohjattu siirtotyökalu.

Työkalut auttavat vakio-objekteissa. Ne eivät kerro, mitkä rajapinnat yhä palvelevat jotain, ja räätälöity kohdistuslogiikka tarvitsee edelleen ihmisen lukemaan sen. Rakenna luettelo väliohjelmiston konfiguraatiosta, lokeista ja ajastetuista töistä, ei kyselylomakkeesta. Suunnittele sitten ERP:n ja väliohjelmiston siirto yhdessä. Peräkkäin tehtyinä jokainen rajapinta testataan kahdesti.

Datan siirto

Järjestelmäkonversiossa data siirtyy järjestelmän mukana, ja niin siirtyy sen laatukin. Liikekumppanikonversio on yleensä ensimmäinen törmäys: päällekkäiset asiakkaat, toimittajat, jotka ovat myös asiakkaita, osoitteet vapaatekstikentissä, verotunnisteet väärässä paikassa. Kaikki tämä on siivottava ennen konversiota, ei sen aikana.

Uudessa käyttöönotossa poimit, puhdistat, muunnat ja lataat, ja vaikea osa on täsmäytys. Talous kuittaa hyväksyntänsä, kun saldot ja avoimet erät täsmäävät, ei silloin, kun latausajo päättyy. Rakenna siirto toistettavaksi koodiksi, jota voit ajaa kymmeniä kertoja yhä puhtaampaa dataa vasten ja jonka tuloksia verrataan automaattisesti joka ajolla.

Kummallakin polulla arkistoi ensin se, mitä et enää tarvitse. Vähemmän dataa tarkoittaa lyhyempiä konversioajoja ja lyhyempää katkoikkunaa.

Clean core -laajennukset

Määräaikavetoisessa projektissa houkutus on kantaa jokainen muutos mukana ja luvata siivota myöhemmin. Myöhemmin ei tule.

SAP:n nimi vaihtoehdolle on clean core: jätä vakiojärjestelmä muuttamatta ja rakenna laajennukset rajapintoja vasten, jotka SAP julkaisee ja pitää vakaina, joko S/4HANAn sisällä tai sen rinnalla SAP Business Technology Platformissa. Kaikki ei voi olla puhdasta ensimmäisestä päivästä. Sääntö, jonka voi oikeasti pitää, on yksinkertaisempi: mitään uutta ei rakenneta vanhalla tavalla. Jokainen nyt vältetty muutos on muutos, jota ei tarvitse testata uudelleen jokaisessa tulevassa päivityksessä.

Päätöskehys

Realistisia polkuja on kolme, ja neljäs saa vähemmän huomiota.

S/4HANA tuotantoon 31. joulukuuta 2027 mennessä. Tämä sopii yrityksille, jotka ovat jo aloittaneet, käyttävät pääosin vakiojärjestelmää ja joilla on kumppani varattuna. Tästä päivästä aikaa on viisitoista kuukautta, eikä moni taloustiimi hyväksy siirtymää kesken tilinpäätöksen. Jos räätälöidyn koodin analyysia ei ole tehty, tämä ei todennäköisesti ole sinun polkusi.

Maksa laajennetusta ylläpidosta ja siirry tuotantoon vuoteen 2030 mennessä. Tähän suurin osa markkinasta on menossa. Kustannus on kahden prosenttiyksikön lisähinta; varmista SAP:lta, miten se lasketaan, jos siirryt tuotantoon kesken jakson. Riski on käsitellä vuotta 2030 samoin kuin vuotta 2027 käsiteltiin: kaukaisena, kunnes yhtäkkiä ei olekaan.

Ota private editionin siirtymävaihtoehto vuoteen 2033. Se tarkoittaa RISE with SAP -sopimusta, HANAa, järjestelmäsi siirtoa SAP ERP, private editioniin ennen 31. joulukuuta 2030, max success -suunnitelmaa ja 2 TB:n vähimmäiskokoa. Keskisuurelle yritykselle se on harvoin halvin tapa ostaa aikaa.

Lähde SAP:sta. Joillekin keskisuurille valmistajille ja jakelijoille pienempi toiminnanohjausjärjestelmä on todellinen vaihtoehto. Rajapinta- ja datatyö ei kutistu. Siitä tulee suurin osa projektia.

Seuraavat kuusi kuukautta, valitsitpa minkä tahansa

Tästä maaliskuun 2027 loppuun kaikki seuraava kannattaa jokaisella polulla:

1. Vahvista lähtötilanteesi. Enhancement package, tietokanta, ylläpitosopimus. Pyydä SAP:n asiakastiimiltä kirjallisesti sinua koskevat laajennetun ylläpidon ehdot.
2. Kytke käyttölokitus päälle nyt, jotta se kattaa vuoden 2026 tilinpäätöksen.
3. Tee räätälöidyn koodin analyysi ja saa tulokseksi luku, ei vaikutelma: kuinka monta objektia, kuinka moni käytössä, kuinka moni koskee tietomallin muuttuneita osia.
4. Rakenna rajapintaluettelo, mukaan lukien kaikki PI/PO:n kautta kulkeva, ja anna jokaiselle rajapinnalle omistaja ja päätös.
5. Aloita perustietojen puhdistus, asiakkaat ja toimittajat ensin.
6. Lopeta muutosten lisääminen. Uusi kehitys noudattaa clean corea tästä päivästä alkaen.
7. Lisää vuoden 2028 ylläpidon korotus vuoden 2027 budjettiin tunnettuna kustannuksena eikä yllätyksenä.
8. Varaa kapasiteetti: kumppani, sisäinen SAP-tiimisi ja kehittäjät, jotka huolehtivat SAP:n ympärillä olevista järjestelmistä. Osaajapula on yksi syistä, joita DSAG:n jäsenet antavat aikataulujen venymiselle.

Taaksepäin laskettuna vuoden 2030 käyttöönotosta: testikierrokset ja siirtymäharjoitukset vuonna 2030, rakentaminen ja korjaukset vuonna 2029, suunnittelu ja datan puhdistus vuonna 2028, analyysi nyt. Siinä on vähemmän pelivaraa kuin miltä näyttää.

Mistä saat apua

Emme ole SAP:n toiminnallinen konsulttiyritys emmekä tee S/4HANA-konversioita; työskentelemme sen tekevän kumppanin rinnalla rajapintaluettelon ja uudelleenrakentamisen, datan siirtokoodin ja sen täsmäytyksen sekä ECC:n ympärille rakennettujen sovellusten parissa, joiden on selvittävä siirrosta. Tätä työtä kuvataan toiminnanohjausjärjestelmän modernisointisivullamme, ja vanhojen järjestelmien ylläpito kattaa järjestelmät, jotka pysyvät paikallaan siihen asti, kun siirryt. Jos haluat ERP:si ympärillä olevan kokonaisuuden laskettavan ennen kuin allekirjoitat ohjelman, kirjoita osoitteeseen office@c9group.dev.