Birçok kurumda eski sistemler hâlâ işin omurgasını oluşturur. Sipariş akışı, stok hareketleri, muhasebe kayıtları, saha operasyonları ya da müşteri verisi yıllardır bu yapılarda yürür. Asıl sorun ise şudur: sistem çalışıyor gibi görünse bile bakım maliyeti yükselir, entegrasyon kabiliyeti zayıflar, güvenlik açıkları büyür ve yeni ürün geliştirme hızı gözle görülür biçimde yavaşlar. Legacy sistem modernizasyonu tam da burada gündeme gelir. En kritik soru da değişmez: Operasyon durmadan bu dönüşüm nasıl gerçekleştirilir?

Kısa cevap, “tek seferde büyük geçiş” yerine kontrollü ve ölçülebilir adımlarla ilerlemektir. Başarılı modernizasyon projelerinde genellikle 3 ila 6 aylık bir keşif ve hazırlık fazı bulunur; ardından modül bazlı geçiş, paralel çalışma dönemi ve geri dönüş planı devreye girer. Buradaki amaç sadece teknolojiyi yenilemek değildir; veri akışını, süreçleri ve kullanıcı deneyimini de güvenli şekilde iyileştirmektir.

Legacy sistem modernizasyonu neden ertelenmemeli?

Eski sistemler çoğu zaman “çalıştığı sürece dokunmayalım” yaklaşımıyla yönetilir. Bu refleks anlaşılabilir. Ancak bazı somut işaretler, modernizasyon ihtiyacını açıkça ortaya koyar. Örneğin bir değişikliğin canlıya alınması 1 gün yerine 2 hafta sürüyorsa, sistem birkaç kritik personele bağımlıysa ya da yeni bir API entegrasyonu için özel ara katmanlar yazmak gerekiyorsa, teknik borç artık operasyonel riske dönüşmüş demektir.

Bir diğer işaret de altyapı ve lisans bağımlılığıdır. Desteği sona ermiş işletim sistemi sürümleri, üretici tarafından güncellenmeyen veritabanları ve yalnızca şirket içi ağda çalışan monolitik uygulamalar kurumun çevikliğini sınırlar. Güvenlik tarafında da tablo ağırlaşır. Özellikle kimlik doğrulama, loglama, yetkilendirme ve yedekleme mekanizmaları güncel standartlar karşısında yetersiz kalabilir.

Buradaki hedef, yıllardır çalışan sistemi suçlamak değildir. O sistem çoğu zaman görevini yerine getirmiştir. Fakat bugünün beklentileri farklıdır: mobil erişim, anlık raporlama, üçüncü taraf servislerle entegrasyon, bulut ölçeklenebilirliği ve denetlenebilir veri akışı artık temel gereksinimler arasında yer alır.

İlk adım: mevcut sistemi envanter ve risk bazlı haritalamak

Modernizasyon, kod yazarak başlamaz. Öncelikle görünmeyen bağımlılıklar ortaya çıkarılır. Sağlıklı bir başlangıç için uygulama envanteri, veri envanteri ve entegrasyon envanteri birlikte hazırlanmalıdır. Bu çalışma çoğu orta ölçekli kurumda 2 ila 8 hafta sürer. Süre; sistem sayısına, dokümantasyon kalitesine ve ekiplere erişim düzeyine göre değişir.

Keşif aşamasında mutlaka netleştirilmesi gereken başlıklar

  • Hangi modül hangi işi yapıyor?
  • Hangi veri hangi tabloda, hangi formatta tutuluyor?
  • Uygulama hangi servisler, cihazlar veya dış sistemlerle konuşuyor?
  • Gün içinde kaç kullanıcı aktif, hangi saatlerde yük zirve yapıyor?
  • Bir hata durumunda kabul edilebilir kesinti süresi kaç dakika?

Bu aşamada teknik ekibin yanı sıra iş birimlerinin bilgisi de kritik önem taşır. Çünkü bazı kurallar kodun içinde değil, kullanıcı alışkanlıklarında yaşar. Örneğin mağaza iade sürecinde sistemde görünmeyen ama fiilen uygulanan bir onay zinciri olabilir. Bu bilgi yakalanmazsa yeni sistem teknik olarak doğru, operasyonel olarak ise eksik kalır.

Pratikte bu noktada bir bağımlılık matrisi hazırlanır. Örneğin “stok servisi kapandığında POS ekranı etkilenir mi?”, “ERP’deki fiyat güncellemesi e-ticaret tarafına kaç dakikada yansır?” gibi sorular tabloya işlenir. Bu tablo, hangi bileşenin önce ayrıştırılacağını belirlemede yol gösterir.

Big bang yerine kademeli geçiş modeli neden daha güvenlidir?

Tüm sistemi tek bir hafta sonunda değiştirip pazartesi sabahı yeni yapıyla devam etmek kulağa hızlı gelebilir. Oysa gerçekte bu yöntem yüksek risk taşır. Özellikle üretim, perakende, lojistik ve finans süreçlerinde tek bir hata bile sipariş, fatura veya tahsilat akışını durdurabilir. Kademeli geçişte ise kritik fonksiyonlar korunur, yeni parçalar kontrollü biçimde devreye alınır.

En yaygın yaklaşımlardan biri strangler pattern olarak bilinir. Eski sistem bir süre daha yaşamaya devam eder. Yeni servisler kenardan eklenir ve trafik parça parça yeni yapılara yönlendirilir. Örneğin önce raporlama modülü ayrıştırılır, ardından müşteri kayıtları için yeni bir API katmanı kurulur, en son sipariş motoru taşınır. Her adımın öncesinde test, sonrasında ise izleme yapılır.

Somut bir senaryo düşünelim. 40 mağazalı bir perakende zincirinde eski ERP’nin doğrudan kasa sistemiyle haberleştiğini varsayalım. İlk aşamada ERP’yi değiştirmek yerine araya bir entegrasyon katmanı eklenir. Kasalar eski akışla çalışmayı sürdürürken yeni sipariş ve stok servisi bu katmandan veri alır. Birkaç mağazada pilot geçiş yapılır. 2 hafta boyunca hata oranı, senkronizasyon süresi ve kullanıcı geri bildirimi izlenir. Ardından kapsam genişletilir.

Operasyonu durdurmadan dönüşüm için teknik stratejiler

Kesintisiz modernizasyonun omurgasını birkaç temel teknik oluşturur. Her projede bunların tamamı kullanılmaz; seçim mevcut mimariye göre yapılır. Yine de bazı yöntemler sahada sıkça karşılık bulur.

1) API katmanı ile soyutlama

Eski sistem doğrudan dokunulamayacak kadar kritikse, önüne bir API katmanı yerleştirilir. Böylece yeni uygulamalar legacy veriye kontrollü biçimde erişebilir. Bu yaklaşım özellikle masaüstü uygulamadan web veya mobil uygulamaya geçişte etkili olur.

GET /api/v1/customers/{id}
POST /api/v1/orders
PUT /api/v1/inventory/{sku}

Bu basit örnekte de görüldüğü gibi yeni kanal, legacy veritabanına doğrudan bağlanmak yerine standart uç noktalar üzerinden çalışır. Yetkilendirme, loglama ve oran sınırlama gibi kontroller de merkezi hale gelir.

2) Paralel çalışma ve veri senkronizasyonu

Yeni sistem bir süre eski sistemle birlikte çalıştırılır. Buna parallel run denir. Özellikle bordro, finans, sipariş ve stok gibi hata toleransı düşük alanlarda fayda sağlar. Buradaki kritik nokta, çift yazım ve veri çakışması riskidir. Çözüm için olay tabanlı senkronizasyon, kuyruk yapıları veya zamanlanmış replikasyon tercih edilebilir. Senkron süresinin 5 saniye mi, 5 dakika mı olacağı iş ihtiyacına göre netleştirilmelidir.

3) Modül ayrıştırma

Monolitik yapıyı tek adımda mikroservise dönüştürmek çoğu zaman gereksizdir. Daha mantıklı yaklaşım, en çok değişen ya da en fazla sorun çıkaran modülü ayırmaktır. Sık kampanya yöneten bir şirkette fiyatlama motoru ilk aday olabilir. Servis seviyesi hedefleri ölçülebiliyorsa önceliklendirme de daha sağlıklı yapılır.

4) Canary ve blue-green dağıtım

Yeni sürüm önce kullanıcıların küçük bir bölümüne açılır. Örneğin trafiğin yüzde 5’i yeni servise yönlendirilir. Hata oranı kabul edilebilir seviyedeyse bu oran kademeli olarak artırılır. Daha sıkı kontrol gereken ortamlarda blue-green yaklaşımı devreye alınır; iki ayrı canlı ortam hazırlanır, trafik tek hamlede ama geri döndürülebilir biçimde diğer ortama aktarılır.

Veri taşıma: en çok hata burada çıkar

Legacy sistem modernizasyonu projelerinde en büyük kırılma noktası çoğu zaman veridir. Çünkü mesele yalnızca tablo taşımak değildir. Alan anlamları zaman içinde değişmiş olabilir, aynı müşteri birden fazla kayıtta tutuluyor olabilir, tarih formatları tutarsız olabilir. 10 yıllık veriyi tek seferde aktarmak yerine segment bazlı geçiş planı, çoğu durumda daha güvenli bir seçenek sunar.

İyi bir veri geçiş planında en az şu adımlar yer alır: veri profilleme, eşleştirme kuralları, temizleme kriterleri, test migrasyonu, doğrulama raporu, geri dönüş prosedürü. Test migrasyonu en az 2 kez yapılmadan canlı geçişe çıkmak risklidir. Özellikle finansal kayıtlar, stok miktarları ve sözleşmesel veriler için mutabakat raporları hazırlanmalıdır.

Bir örnek verelim. Eski sistemde ürün kodu 8 karakter, yeni sistemde ise 12 karakter olabilir. Eski yapıda boş bırakılan zorunlu alanlar yeni modelde hata üretir. Bu tür farklar proje sonunda değil, keşif aşamasında görünmelidir. Aksi halde yazılım tarafı hazır olsa bile geçiş tarihi ertelenir.

İnsan, süreç ve yönetişim boyutu

Teknoloji doğru seçilse bile kullanıcı adaptasyonu zayıfsa modernizasyon beklenen faydayı üretmez. Bu nedenle dönüşüm yalnızca BT projesi olarak ele alınmamalıdır. Süreç sahipleri, operasyon yöneticileri, güvenlik ekipleri ve son kullanıcılar erken aşamada sürece dahil edilmelidir.

İşleyen bir modelde haftalık karar ritmi kurulur. Hangi modül pilotta, hangi hata kritik, hangi veri seti doğrulandı gibi başlıklar net bir kurulda değerlendirilir. Kararların e-posta zincirlerinde kaybolmaması önemlidir. Jira, Azure DevOps ya da benzeri araçlarla görev, risk ve bağımlılık görünür halde tutulabilir.

Eğitim de proje sonuna bırakılmamalıdır. Örneğin saha ekipleri için 45 dakikalık görev bazlı mini oturumlar, yüzlerce sayfalık tek seferlik eğitim dokümanından daha etkili olur. Kullanıcıların yeni akışları pilot aşamada denemesi, canlı geçiş günündeki stresi azaltır.

Doğru başarı kriterleri nasıl tanımlanır?

“Sistemi yeniledik” ifadesi tek başına bir başarı ölçüsü değildir. Teknik ve operasyonel KPI’lar en başta tanımlanmalıdır. Örnek olarak sürüm alma süresinin 10 günden 1 güne inmesi, rapor üretim süresinin 30 dakikadan 3 dakikaya düşmesi, entegrasyon geliştirme süresinin haftalar yerine saatler düzeyine yaklaşması izlenebilir hedefler arasında sayılabilir.

Aynı şekilde hata oranı, kesinti süresi, destek talebi hacmi ve kullanıcı memnuniyeti de takip edilmelidir. İlk 30 gün, ilk 90 gün ve ilk 6 ay için ayrı değerlendirme çerçeveleri oluşturmak fayda sağlar. Çünkü bazı kazanımlar hemen görünür, bazıları ise süreç oturduktan sonra ortaya çıkar.

Hangi durumda yeniden yazım, hangi durumda refactor?

Her legacy sistemin tamamen sıfırdan yazılması gerekmez. Bazen çekirdek iş kuralları değerlidir ve korunmalıdır. Bazı durumlarda ise kod tabanı öylesine kırılgandır ki parça parça düzeltmek, yeniden inşa etmekten daha maliyetli hale gelir. Karar verirken birkaç ölçüt kullanılabilir: test edilebilirlik, bağımlılık yoğunluğu, güvenlik açıklarının kapsamı, lisans kısıtları ve iş kurallarının dokümantasyon seviyesi.

Eğer kod değişikliği sonrası regresyon riski aşırı yüksekse, sistem yalnızca birkaç kişiye bağımlıysa ve teknoloji üretici desteğini kaybetmişse yeniden yazım daha anlamlı olabilir. Buna karşılık veri modeli güçlü, iş kuralları net ve kullanım alanı stabilse önce refactor, ardından modül ayrıştırma daha ekonomik bir yol sunar.

Sonuç: kesintisiz modernizasyon plan ister, acele değil

Legacy sistem modernizasyonu, eskiyi kapatıp yeniyi açma işi değildir. Asıl mesele, kurumun değer üreten süreçlerini korurken teknolojik esnekliği yeniden kazanmaktır. Bunun için envanter çıkarılır, riskler puanlanır, modüller önceliklendirilir, veri geçişi prova edilir ve yeni yapı kontrollü biçimde devreye alınır. Operasyonu durdurmadan dönüşüm mümkündür; ancak bunun yolu kestirmelerden değil, ölçülebilir adımlardan geçer.

Kuruma özel doğru strateji; mevcut mimariye, veri kalitesine, entegrasyon yoğunluğuna ve iş sürekliliği beklentisine göre şekillenir. İyi tasarlanmış bir geçiş planı yalnızca bugünün sorunlarını çözmekle kalmaz. Yeni ürün geliştirme hızını, entegrasyon kapasitesini ve operasyonel dayanıklılığı da güçlendirir.