Поддръжката на SAP ECC приключва на 31 декември 2027 г.: поскъпване, а не изключване

На 31 декември 2027 г. SAP прекратява основната поддръжка (mainstream maintenance) на SAP ECC 6.0 и на другите основни приложения на SAP Business Suite 7. На 1 януари 2028 г. нищо не се изключва. Системата ви продължава да работи, потребителите ви продължават да осчетоводяват фактури, а SAP все така ще ви продава поддръжка. Променя се колко плащате за нея и какво получавате.

Разликата е важна, защото голяма част от съветите, които се разпространяват, представят 2027 г. като пропаст. За повечето компании, които още работят с ECC, тя не е такава и те го знаят: най-голямата група от останалите потребители на ECC планира за 2030 г. Истинският риск е друг. Работата, която всъщност определя датата (собствен ABAP код, интерфейси, данни), получава обхват късно и 2030 г. се оказва също толкова тясна, колкото беше 2027 г.

Статията е за ИТ директори и ръководители на SAP в средни компании, повечето от тях на немскоезичните пазари, които все още работят с ECC и трябва да решат как ще изглеждат следващите три години.

Какво всъщност е поела SAP

Условията са на страницата на SAP за стратегията за поддръжка и бяха обявени за първи път през февруари 2020 г.:

• До 31 декември 2027 г.: основна поддръжка за основните приложения на Business Suite 7, сред които SAP ERP 6.0, при последните три пакета за подобрения (enhancement packages). Ако системата ви е на по-стар пакет за подобрения, проверете SAP Note 2881788 (с връзка от същата страница), преди да изградите план около датата от 2027 г.
• От 1 януари 2028 г. до 31 декември 2030 г.: удължена поддръжка по избор, с „надбавка от два процентни пункта върху базата за поддръжка“. Казано просто, ставката за поддръжка, която плащате днес, се увеличава с два пункта.
• Ако не изберете удължена поддръжка: автоматично преминавате към поддръжка, специфична за клиента (customer-specific maintenance). Какво покрива тя, е описано в SAP Note 52505, също с връзка от тази страница. Прочетете я, преди да приемете, че е достатъчна.
• За S/4HANA: SAP се е ангажирала с поддръжка до края на 2040 г.

Има и още един път за по-малка група. През август 2025 г. SAP представи SAP ERP, private edition, transition option: ограничен във времето абонамент, който пренася ECC от 2031 до 2033 г. в частния облак на SAP. Условията са строги. „Системите трябва да бъдат мигрирани към SAP ERP, private edition на SAP HANA преди 31 декември 2030 г.“ HANA е единствената поддържана база данни, вариантът се предлага само заедно с плана max success за 2031-2033 г., а SAP определя минимум от 2 TB за системите, абонирани по него. SAP заявява, че той е предназначен за „нашите най-големи и най-сложни клиенти на SAP ERP“. „Търговски равностойните условия“, които SAP предложи, бяха за клиентите, които се ангажираха с private edition до края на 2025 г.

Каквото и ниво да изберете, задайте писмено един въпрос на SAP и на партньора си: кои законодателни промени (данъци, заплати, формати за електронно фактуриране) ще продължат да стигат до вашата ECC система и до кога. За германска компания само този отговор може да реши дали оставането на място е жизнеспособно.

Какво прави останалата част от пазара

DSAG, немскоезичната група на потребителите на SAP, проведе своя Investment Report 2026 със 198 респонденти между 8 декември 2025 г. и 21 януари 2026 г. От тях 54% все още работят с ECC или с по-стария Business Suite, при 68% през 2024 г.

Що се отнася до сроковете, почти половината от респондентите планират да преминат към S/4HANA до края на 2030 г., което според DSAG означава да плащат за удължена поддръжка. Други 37% искат да преминат до края на 2027 г., а едва 4% се целят в 2033 г. и в private edition transition option.

Председателят на DSAG Йенс Хунгерсхаузен посочи причините направо: недостигът на кадри, паралелните проекти за трансформация и ограничените бюджети изтласкват графиците назад, „дори ако това води до по-високи разходи за поддръжка“.

Движат се и публичните възложители. Според нашето собствено преброяване на обявленията за обществени поръчки в ЕС през 2025 и 2026 г. има около 200 процедури за миграция към S/4HANA на полугодие, а до началото на октомври 2026 г. те са над 300, повечето от тях в Германия. Работата се случва. Тя е разпределена в по-дълъг период, отколкото подсказват заглавията за 2027 г.

Къде всъщност е работата

Техническото преобразуване от ECC към S/4HANA е добре обезпечено с инструменти от SAP и партньорите ѝ. Ако работите с леко персонализирана ECC и шепа стандартни интерфейси, вашият интегратор е правил това много пъти и по-голямата част от следващото не е ваш проблем.

То става ваш проблем пропорционално на това колко сте изградили сами.

Собствен ABAP код: къде проектите се забавят

S/4HANA не е ECC върху нова база данни. Части от модела на данните са променени. Клиентите и доставчиците стават бизнес партньори. Финансовите и складовите осчетоводявания са обединени в по-малко и по-широки таблици. Някои транзакции и функции са премахнати или заменени.

Собствен код, който чете таблиците директно, разчита на точка за разширение (exit), която е преместена, или мълчаливо предполага определен ред на сортиране (HANA не гарантира такъв, освен ако заявката не го изисква), може да мине синтактичната проверка и пак да прави грешното нещо. Именно последният вид боли, защото се проявява при интеграционното тестване или след пускането в експлоатация, а не при сканирането на кода.

Процесът, който работи:

1. Първо измерете използването. Включете регистрирането на използването в продуктивната среда (ABAP call monitor, транзакция SCMON) и го оставете да работи през цяло годишно приключване. В системите с дълъг живот значителен дял от собствените обекти често никога не се изпълнява. Код, който никой не изпълнява, се изтрива, а не се мигрира.
2. Пуснете инструментите за анализ върху това, което остава. Проверките на SAP откриват възможни проблеми. Те не могат да ви кажат кои от тях имат значение за бизнеса.
3. Класифицирайте всеки обект. Извеждане от употреба, замяна със стандартна функционалност, поправка на място или изграждане наново извън ядрото. По едно решение за обект, с поименно посочен бизнес собственик.
4. Тествайте по процеси, а не по обекти. Промяната на кода е евтината част. Скъпата част е да докажете, че процесът от поръчка до плащане и месечното приключване все още дават същите числа.

Проектите се забавят тук по скучна причина: никой не е броил достатъчно рано. Обемът на собствения код е известен само приблизително, хората, които са го писали, често са напуснали, а истинските находки идват във втория цикъл на тестване, след като датата вече е обявена вътрешно.

Интерфейсите и PI/PO със същия часовник

ECC рядко стои сама. IDoc към склада, RFC и BAPI извиквания от производствения цех, плоски файлове към банката и данъчния консултант, клиентски портал, който чете изглед в базата данни, създаден от някого през 2011 г. Всеки от тях трябва да бъде открит, тестван и в някои случаи изграден наново.

Ако тези интерфейси минават през SAP Process Integration или Process Orchestration, има втори краен срок на същите дати. Architecture Center на SAP посочва, че PI/PO наближава „края на стандартната поддръжка през 2027 г.“, че клиентите могат да удължат поддръжката до 2030 г. и че след това поддръжката от SAP приключва. SAP насочва клиентите на PI/PO към SAP Integration Suite, който идва с оценка за миграция и инструменти за миграция с помощник.

Инструментите помагат със стандартните обекти. Те не ви казват кои интерфейси все още обслужват нещо, а собствената логика за съпоставяне все така трябва да бъде прочетена от човек. Изградете инвентаризацията от конфигурацията на междинния софтуер, дневниците и планираните задачи, а не от въпросник. После планирайте преминаването на ERP и на междинния софтуер заедно. Ако се правят едно след друго, всеки интерфейс се тества два пъти.

Миграция на данни

При преобразуване на системата данните ви се преместват заедно с нея, а с тях и качеството им. Преобразуването в бизнес партньори обикновено е първият сблъсък: дублирани клиенти, доставчици, които са и клиенти, адреси в полета за свободен текст, данъчни номера на грешното място. Всичко това трябва да бъде изчистено преди преобразуването, а не по време на него.

При ново внедряване извличате, почиствате, трансформирате и зареждате, а трудната част е равнението. Финансовият отдел одобрява, когато салдата и отворените позиции съвпадат, а не когато задачата за зареждане приключи. Изградете миграцията като повторяем код, който можете да пуснете десетина пъти върху все по-чисти данни, като сравнявате резултатите автоматично при всяко изпълнение.

И при двата пътя първо архивирайте онова, което вече не ви трябва. По-малко данни означава по-кратки преобразувания и по-кратък прозорец на прекъсване.

Разширения по принципа clean core

В проект, воден от краен срок, изкушението е да пренесете всяка модификация и да обещаете, че ще подредите по-късно. По-късно не идва.

SAP нарича алтернативата clean core: оставяте стандартната система непроменена и изграждате разширения срещу интерфейси, които SAP публикува и поддържа стабилни, било в S/4HANA, било до нея в SAP Business Technology Platform. Не всичко може да е чисто от първия ден. Правилото, което реално можете да спазвате, е по-просто: нищо ново не се изгражда по стария начин. Всяка модификация, която избегнете сега, е модификация, която няма да тествате отново при всяко бъдещо надграждане.

Рамка за решение

Има три реалистични пътя и четвърти, на който се обръща по-малко внимание.

Пускане в експлоатация на S/4HANA до 31 декември 2027 г. Това подхожда на компании, които вече са започнали, работят с предимно стандартна система и имат резервиран партньор. Оттук нататък това са петнайсет месеца, а малко финансови екипи ще приемат преминаване по средата на годишното приключване. Ако анализът на собствения ви код не е направен, това вероятно не е вашият път.

Плащане за удължена поддръжка и пускане в експлоатация до 2030 г. Натам върви по-голямата част от пазара. Цената е надбавката от два пункта; потвърдете със SAP как се прилага тя, ако пуснете системата в експлоатация по средата на периода. Рискът е да се отнасяте към 2030 г. така, както се отнасяхте към 2027 г.: като към нещо далечно, докато изведнъж не стане близко.

Избор на private edition transition option до 2033 г. Това означава договор RISE with SAP, HANA, системата ви преместена в SAP ERP, private edition преди 31 декември 2030 г., планът max success и минимумът от 2 TB. За средна компания това рядко е най-евтиният начин да купите време.

Напускане на SAP. За някои средни производители и дистрибутори по-малка ERP система е реален вариант. Работата по интерфейсите и данните не намалява. Тя се превръща в по-голямата част от проекта.

Следващите шест месеца, какъвто и път да изберете

От днес до края на март 2027 г. всичко това се отплаща при всеки от пътищата:

1. Потвърдете отправната си точка. Пакет за подобрения, база данни, договор за поддръжка. Поискайте писмено от екипа на SAP, който обслужва акаунта ви, условията за удължена поддръжка, които се отнасят за вас.
2. Включете регистрирането на използването още сега, за да обхване годишното приключване за 2026 г.
3. Направете анализ на собствения код и излезте с число, а не с впечатление: колко обекта, колко от тях се използват, колко засягат променените части на модела на данните.
4. Изградете инвентаризацията на интерфейсите, включително всичко, което минава през PI/PO, с отговорник и решение за всеки интерфейс.
5. Започнете почистването на основните данни, първо клиентите и доставчиците.
6. Спрете да добавяте модификации. Новата разработка следва clean core от днес.
7. Включете поскъпването на поддръжката от 2028 г. в бюджета за 2027 г. като известен разход, а не като изненада.
8. Резервирайте капацитет: партньора, вътрешния си SAP екип и разработчиците, които поддържат системите около SAP. Недостигът на кадри е една от причините, които членовете на DSAG посочват за забавящите се графици.

Като броим назад от пускане в експлоатация през 2030 г.: цикли на тестване и репетиции на преминаването през 2030 г., изграждане и отстраняване на проблеми през 2029 г., проектиране и почистване на данни през 2028 г., анализ сега. В това има по-малко резерв, отколкото изглежда.

Къде да получите помощ

Ние не сме консултантска компания по функционалностите на SAP и не извършваме преобразувания към S/4HANA; работим до партньора, който ги извършва, по инвентаризацията и изграждането наново на интерфейсите, кода за миграция на данни и неговото равнение, както и по приложенията около ECC, които трябва да оцелеят при преминаването. Тази работа е описана на страницата ни за модернизация на ERP, а поддръжката на наследени системи обхваща системите, които остават където са, докато не преминете. Ако искате средата около вашата ERP система да бъде преброена, преди да подпишете програма, пишете ни на office@c9group.dev.