SAP ECC Bakımı 31 Aralık 2027'de Bitiyor: Sistem Kapanmıyor, Fiyat Kademesi Değişiyor

SAP, 31 Aralık 2027'de SAP ECC 6.0 ve SAP Business Suite 7'nin diğer çekirdek uygulamaları için ana akım bakımı (mainstream maintenance) sona erdiriyor. 1 Ocak 2028'de hiçbir şey kapanmıyor. Sisteminiz çalışmaya devam ediyor, kullanıcılarınız fatura kaydetmeyi sürdürüyor ve SAP size destek satmaya devam edecek. Değişen, bunun için ne kadar ödediğiniz ve karşılığında ne aldığınız.

Bu ayrım önemli, çünkü dolaşımdaki tavsiyelerin çoğu 2027'yi bir uçurum gibi ele alıyor. Hâlâ ECC kullanan şirketlerin çoğu için öyle değil ve bunu biliyorlar: geriye kalan ECC kullanıcılarının en büyük grubu 2030'a göre plan yapıyor. Asıl risk başka. Tarihi gerçekte belirleyen işin (özel ABAP kodu, arayüzler, veri) kapsamı geç çıkarılıyor ve 2030 da en az 2027 kadar sıkışık hâle geliyor.

Bu yazı, hâlâ ECC kullanan ve önümüzdeki üç yılın nasıl geçeceğine karar vermek zorunda olan, çoğu Almanca konuşulan pazarlardaki orta ölçekli şirketlerin bilgi işlem yöneticileri (CIO) ve SAP sorumluları için.

SAP'nin Gerçekte Taahhüt Ettikleri

Koşullar SAP'nin bakım stratejisi sayfasında yer alıyor ve ilk kez Şubat 2020'de duyuruldu:

• 31 Aralık 2027'ye kadar: aralarında SAP ERP 6.0'ın da bulunduğu Business Suite 7 çekirdek uygulamaları için, en son üç geliştirme paketi (enhancement package) üzerinde ana akım bakım. Sisteminiz daha eski bir geliştirme paketindeyse, 2027 tarihine dayanan bir plan yapmadan önce (o sayfadan bağlantı verilen) SAP Note 2881788'i kontrol edin.
• 1 Ocak 2028 ile 31 Aralık 2030 arası: “bakım bazına iki yüzde puanlık bir ek ücretle” isteğe bağlı genişletilmiş bakım (extended maintenance). Basitçe söylemek gerekirse, bugün ödediğiniz bakım oranı iki puan artıyor.
• Genişletilmiş bakımı almazsanız: otomatik olarak müşteriye özel bakıma (customer-specific maintenance) geçersiniz. Bunun neleri kapsadığı, aynı sayfadan bağlantı verilen SAP Note 52505'te anlatılıyor. Yeterli olduğunu varsaymadan önce okuyun.
• S/4HANA için: SAP, 2040 sonuna kadar bakım taahhüt etti.

Daha küçük bir grup için bir yol daha var. SAP, Ağustos 2025'te SAP ERP, private edition, transition option'ı açıkladı: ECC'yi 2031'den 2033'e kadar SAP'nin özel bulutu içinde taşıyan, süresi sınırlı bir abonelik. Koşullar katı. “Sistemlerin 31 Aralık 2030'dan önce SAP HANA üzerinde SAP ERP, private edition'a taşınmış olması gerekir.” Desteklenen tek veritabanı HANA; seçenek yalnızca 2031-2033 dönemi için max success plan ile birlikte sunuluyor ve SAP, bu seçenek kapsamında abone olunan sistemler için en az 2 TB şartı koyuyor. SAP, seçeneğin “en büyük ve en karmaşık SAP ERP müşterilerimiz” için düşünüldüğünü söylüyor. SAP'nin sunduğu “ticari açıdan eşdeğer koşullar”, 2025 sonuna kadar private edition'a taahhüt veren müşteriler içindi.

Hangi seviyeyi seçerseniz seçin, SAP'ye ve iş ortağınıza tek bir soruyu yazılı olarak sorun: hangi yasal değişiklikler (vergi, bordro, e-Fatura biçimleri) ECC sisteminize ulaşmaya devam edecek ve ne zamana kadar? Bir Alman şirketi için yalnızca bu cevap, olduğu yerde kalmanın mümkün olup olmadığını belirleyebilir.

Pazarın Geri Kalanı Ne Yapıyor

Almanca konuşulan ülkelerin SAP kullanıcı grubu DSAG, 2026 Yatırım Raporu'nu 8 Aralık 2025 ile 21 Ocak 2026 arasında 198 katılımcıyla yürüttü. Bunların %54'ü hâlâ ECC ya da daha eski Business Suite kullanıyor; bu oran 2024'te %68'di.

Zamanlama konusunda katılımcıların neredeyse yarısı 2030 sonuna kadar S/4HANA'ya geçmeyi planlıyor; DSAG, bunun genişletilmiş bakım için ödeme yapmak anlamına geldiğine dikkat çekiyor. %37'lik bir grup 2027 sonuna kadar geçmek istiyor; yalnızca %4'ü 2033'ü ve private edition transition option'ı hedefliyor.

DSAG başkanı Jens Hungershausen gerekçeleri açıkça ortaya koydu: nitelikli personel eksikliği, paralel yürüyen dönüşüm projeleri ve sınırlı bütçeler takvimleri geriye itiyor, “bu daha yüksek bakım maliyetlerine yol açsa bile”.

Kamu alıcıları da harekete geçiyor. AB kamu ihale ilanları üzerinde kendi yaptığımız sayım, 2025 ve 2026 boyunca her yarıyılda yaklaşık 200 S/4HANA geçiş ihalesi olduğunu ve 2026'da ekim başı itibarıyla bu sayının 300'ü aştığını gösteriyor; çoğu Almanya'da. İş yapılıyor. Yalnızca 2027 manşetlerinin düşündürdüğünden daha uzun bir zamana yayılıyor.

İşin Asıl Yoğunlaştığı Yerler

ECC'den S/4HANA'ya teknik dönüşüm, SAP ve iş ortakları tarafından iyi araçlarla destekleniyor. Az özelleştirilmiş, birkaç standart arayüzü olan bir ECC kullanıyorsanız entegratörünüz bunu defalarca yapmıştır ve aşağıdakilerin çoğu sizin sorununuz değildir.

Kendinizin ne kadar çok şey geliştirdiğinize bağlı olarak sizin sorununuz hâline gelir.

Özel ABAP: projelerin kaydığı yer

S/4HANA, yeni bir veritabanı üzerindeki ECC değildir. Veri modelinin bazı kısımları değişti. Müşteriler ve tedarikçiler iş ortağına (business partner) dönüşüyor. Finans ve stok kayıtları daha az sayıda, daha geniş tabloda birleştirildi. Bazı işlemler ve fonksiyonlar kaldırıldı ya da yerine başkaları geldi.

Tabloları doğrudan okuyan, yeri değişmiş bir exit'e dayanan ya da sessizce bir sıralama varsayan özel kod (HANA, sorgu açıkça istemedikçe sıralama garanti etmez) sözdizimi kontrolünden geçip yine de yanlış şey yapabilir. Asıl canı yakan bu son türdür, çünkü kod taramasında değil, entegrasyon testinde ya da canlıya geçişten sonra ortaya çıkar.

İşe yarayan süreç:

1. Önce kullanımı ölçün. Üretim sisteminde kullanım kaydını açın (ABAP call monitor, SCMON işlemi) ve tam bir yıl sonu kapanışı boyunca çalışır durumda bırakın. Uzun ömürlü sistemlerde özel nesnelerin azımsanmayacak bir kısmı çoğu zaman hiç çalışmaz. Kimsenin çalıştırmadığı kod taşınmaz, silinir.
2. Kalanlar üzerinde analiz araçlarını çalıştırın. SAP'nin kontrolleri olası sorunları bulur. Hangilerinin iş için önemli olduğunu söyleyemez.
3. Her nesneyi sınıflandırın. Kullanımdan kaldırın, standart işlevle değiştirin, yerinde düzeltin ya da çekirdeğin dışında yeniden geliştirin. Her nesne için tek bir karar ve adı belli bir iş sorumlusu.
4. Nesne bazında değil, süreç bazında test edin. Kodu değiştirmek işin ucuz kısmı. Siparişten tahsilata sürecinin ve ay sonu kapanışının hâlâ aynı rakamları ürettiğini kanıtlamak pahalı kısmı.

Projeler burada sıkıcı bir nedenle kayar: kimse yeterince erken saymamıştır. Özel kodun hacmi ancak kabaca bilinir, onu yazanlar çoğu zaman ayrılmıştır ve gerçek bulgular, tarih şirket içinde duyurulduktan sonra, ikinci test döngüsünde gelir.

Arayüzler ve aynı takvime bağlı PI/PO

ECC nadiren tek başına durur. Depoya giden IDoc'lar, üretim sahasından gelen RFC ve BAPI çağrıları, bankaya ve mali müşavire giden düz dosyalar, birinin 2011'de oluşturduğu bir veritabanı görünümünü okuyan bir müşteri portalı. Bunların her birinin bulunması, test edilmesi ve bazı durumlarda yeniden geliştirilmesi gerekir.

Bu arayüzler SAP Process Integration ya da Process Orchestration üzerinden çalışıyorsa, aynı tarihlerde ikinci bir son tarih var. SAP'nin Architecture Center'ı, PI/PO'nun “2027'de standart bakımın sonuna” yaklaştığını, müşterilerin bakımı 2030'a kadar uzatabileceğini ve SAP desteğinin bundan sonra sona ereceğini söylüyor. SAP, PI/PO müşterilerini bir geçiş değerlendirmesi ve sihirbaz tabanlı geçiş araçlarıyla birlikte gelen SAP Integration Suite'e yönlendiriyor.

Araçlar standart nesnelerde yardımcı olur. Hangi arayüzlerin hâlâ bir işe yaradığını söylemez ve özel eşleme mantığını yine de bir insanın okuması gerekir. Envanteri bir anketten değil, ara katman yazılımı yapılandırmasından, günlüklerden ve zamanlanmış işlerden çıkarın. Sonra ERP geçişini ve ara katman geçişini birlikte planlayın. Arka arkaya yapılırsa her arayüz iki kez test edilir.

Veri taşıma

Bir sistem dönüşümünde (system conversion) verileriniz sistemle birlikte taşınır, kalitesi de öyle. İlk çarpışma genellikle iş ortağı dönüşümünde yaşanır: mükerrer müşteriler, aynı zamanda müşteri olan tedarikçiler, serbest metin alanlarındaki adresler, yanlış yerdeki vergi numaraları. Bunların hepsinin dönüşüm sırasında değil, dönüşümden önce temizlenmesi gerekir.

Yeni bir kurulumda (new implementation) verileri çıkarır, temizler, dönüştürür ve yüklersiniz; zor kısım mutabakattır. Finans, yükleme işi bittiğinde değil, bakiyeler ve açık kalemler tuttuğunda onay verir. Taşımayı, giderek temizlenen veriler üzerinde onlarca kez çalıştırabileceğiniz ve her çalıştırmada sonuçları otomatik olarak karşılaştıran tekrarlanabilir bir kod olarak geliştirin.

Hangi yolu seçerseniz seçin, önce artık ihtiyaç duymadığınız verileri arşivleyin. Daha az veri, daha kısa dönüşüm süreleri ve daha kısa bir kesinti penceresi demektir.

Clean core uzantıları

Son tarihe göre yürüyen bir projede her modifikasyonu olduğu gibi taşıyıp sonra toparlamayı vaat etmek cazip gelir. O “sonra” hiç gelmez.

SAP'nin alternatife verdiği ad clean core: standart sistemi değiştirmeden bırakmak ve uzantıları, SAP'nin yayımladığı ve kararlı tuttuğu arayüzlere karşı, ya S/4HANA'nın içinde ya da yanında SAP Business Technology Platform üzerinde geliştirmek. Her şey ilk günden temiz olamaz. Gerçekten uygulayabileceğiniz kural daha basit: yeni hiçbir şey eski yöntemle geliştirilmez. Şimdi kaçındığınız her modifikasyon, gelecekteki her yükseltmede yeniden test etmeyeceğiniz bir modifikasyondur.

Bir Karar Çerçevesi

Gerçekçi üç yol var, bir de daha az ilgi gören dördüncüsü.

31 Aralık 2027'ye kadar S/4HANA'da canlıya geçmek. Bu, işe çoktan başlamış, büyük ölçüde standart bir sistem kullanan ve iş ortağıyla anlaşmış şirketlere uyar. Bugünden itibaren bu on beş ay demek ve çok az finans ekibi yıl sonu kapanışının ortasında bir geçişi kabul eder. Özel kod analiziniz yapılmadıysa bu büyük olasılıkla sizin yolunuz değil.

Genişletilmiş bakım için ödeme yapıp 2030'a kadar canlıya geçmek. Pazarın büyük kısmının yöneldiği yer burası. Maliyeti iki puanlık ek ücret; dönemin ortasında canlıya geçerseniz bunun nasıl uygulanacağını SAP ile teyit edin. Risk, 2030'a 2027'ye davranıldığı gibi davranmak: birden yaklaşana kadar uzak görmek.

2033'e kadar private edition transition option'ı kullanmak. Bu; bir RISE with SAP sözleşmesi, HANA, sisteminizin 31 Aralık 2030'dan önce SAP ERP, private edition'a taşınması, max success plan ve en az 2 TB şartı anlamına geliyor. Orta ölçekli bir şirket için zaman satın almanın en ucuz yolu nadiren budur.

SAP'den ayrılmak. Bazı orta ölçekli üreticiler ve distribütörler için daha küçük bir ERP gerçek bir seçenek. Arayüz ve veri işi küçülmez. Projenin büyük kısmını oluşturur.

Hangisini Seçerseniz Seçin, Önümüzdeki Altı Ay

Bugünden Mart 2027 sonuna kadar şunların hepsi her yolda karşılığını verir:

1. Başlangıç noktanızı teyit edin. Geliştirme paketi, veritabanı, bakım sözleşmesi. SAP müşteri ekibinizden size uygulanan genişletilmiş bakım koşullarını yazılı olarak isteyin.
2. Kullanım kaydını şimdi açın, böylece 2026 yıl sonu kapanışını da kapsasın.
3. Özel kod analizi yapın ve bir izlenimle değil, bir sayıyla çıkın: kaç nesne var, kaçı kullanılıyor, kaçı veri modelinin değişen kısımlarına dokunuyor.
4. Arayüz envanterini çıkarın, PI/PO üzerinden çalışan her şey dahil, her arayüz için bir sorumlu ve bir kararla.
5. Ana veri temizliğine başlayın, önce müşteriler ve tedarikçiler.
6. Modifikasyon eklemeyi bırakın. Yeni geliştirmeler bugünden itibaren clean core ilkesine uysun.
7. 2028 bakım artışını 2027 bütçesine koyun, sürpriz olarak değil, bilinen bir maliyet olarak.
8. Kapasiteyi şimdiden ayırın: iş ortağı, şirket içi SAP ekibiniz ve SAP'nin çevresindeki sistemlerle ilgilenen geliştiriciler. Nitelikli personel eksikliği, DSAG üyelerinin kayan takvimler için gösterdiği nedenlerden biri.

2030'da canlıya geçişten geriye doğru sayarsak: test döngüleri ve geçiş provaları 2030'da, geliştirme ve düzeltmeler 2029'da, tasarım ve veri temizliği 2028'de, analiz şimdi. Bu takvimde göründüğünden daha az boşluk var.

Nereden Destek Alabilirsiniz

Biz bir SAP fonksiyonel danışmanlık firması değiliz ve S/4HANA dönüşümlerini yürütmüyoruz; bunu yapan iş ortağının yanında, arayüz envanteri ve yeniden geliştirme, veri taşıma kodu ve mutabakatı ile ECC'nin çevresinde geliştirilmiş ve geçişten sağ çıkması gereken uygulamalar üzerinde çalışıyoruz. Bu çalışma ERP modernizasyonu sayfamızda anlatılıyor; eski sistem bakımı ise siz geçiş yapana kadar yerinde kalan sistemleri kapsıyor. Bir programa imza atmadan önce ERP'nizin çevresindeki sistemlerin sayılmasını istiyorsanız office@c9group.dev adresine yazın.