Eski Sistemleri Kesintisiz Değiştirme: Excel ve Access için Strangler Fig Yaklaşımı

Satış departmanın 12 yıllık bir Access veritabanıyla çalışıyor, muhasebe artık kimsenin anlamadığı forecast tablolarını güncelliyor ve çekmecede 2022'den beri kimsenin dokunmaya cesaret edemediği "büyük modernizasyon" teklifi duruyor. Legacy günlük hayatına hoş geldin. Eski sistemleri değiştirmek bir BT projesi değildir – bir risk yönetimi projesidir. Ve kesintisiz çalışan bir yol vardır: Strangler Fig yaklaşımı.

Hannover'deki Storyable ekibi olarak yıllardır Excel, Access ve SAP ada çözümlerini orta ölçekli işletmelerde migrate ediyoruz. Şunu öğrendik: en pahalı migrasyon geç başlayan değildir – fazla büyük tasarlanan migrasyondur. Bu cluster yazısı, Web Uygulaması Geliştirme Rehberimizi tamamlar ve günlük işin bir saat bile durmadan eski sistemden nasıl temiz çıkacağını gösterir.

Sorun: Şirketler Neden Yıllarca Tehlikeli Gölge BT ile Yaşıyor

Gölge BT öncelikle bir güvenlik sorunu değildir – bir algı sorunudur. Kimse merkezi Excel tablosunu "kritik iş uygulaması" olarak tanımlamaz. Sadece oradadır. Çalışır. Çalışmayana kadar.

Hannover'de görüştüğümüz her ikinci orta ölçekli işletmede aynı kalıbı görüyoruz:

• Sadece bir kişinin anladığı, 40+ bağlantısı olan bir Excel dosyası
• Masanın altındaki Windows sunucuda çalışan 2011 yapımı bir Access veritabanı
• E-posta ile muhasebede dolaşan manuel SAP CSV exportları
• Üç farklı araçtan oluşan, kimsenin resmi olarak bakım yapmadığı bir "ERP"

Sonuçlar ölçülebilir ve tehlikelidir:

• Uyumluluk riski: GoBD denetlemeye dayanıklı veri tutmayı şart koşar – Excel bunu yapamaz
• Kilit kişi riski: Mantığı bilen meslektaş tatilde. Ya da işten ayrıldı.
• Ölçeklenme freni: Sipariş hacmi iki katına çıkınca tablolar çöker
• Güvenlik kabusu: Eski Access runtime'ları fidye yazılımı saldırıları için bilinen bir giriş kapısıdır

Tam burada yapısal iç web uygulamaları ile süreç optimizasyonunun argümanı devreye girer: Sadece hız değil, dayanıklılık satın alıyorsun. Ve dürüst karşılaştırma sorusu olan Custom Code vs. hazır paket sorusu eski sistem değişimlerinde neredeyse her zaman Custom Code lehine sonuçlanır – çünkü hazır paketler büyümüş iş süreçlerinin özgünlüklerini yansıtamaz.

"Strangler Fig" Yaklaşımı: Big-Bang Yerine Aşamalı Değişim

Big-Bang migrasyonu demek: X tarihi, eski sistem kapalı, yeni sistem açık. Standish Group Chaos Report'ları yıllardır gösteriyor: bu projelerin %60'ından fazlası başarısız oluyor, bütçeyi aşıyor veya fonksiyon kaybediyor. Spesifikasyonda gözden kaçan tek bir edge case günlük işi günlerce felç edebilir.

Martin Fowler 2004'te zarif bir alternatif tanımladı: Strangler Fig deseni. Bir ağacı kırılma yaşatmadan saran ve yavaş yavaş değiştiren boğucu incirden ilham aldı.

Yazılıma uyarlandığında:

1. Eski sistem işlemeye devam eder. Kimse hemen geçişe zorlanmaz.
2. Yeni web uygulaması fonksiyonel olarak etrafında büyür. Modül modül eski sistemden kesilip yeni sistemde yeniden inşa edilir.
3. Yönlendirme istek bazında karar verir – API gateway, reverse proxy veya basit bir login switch ile.
4. Her fonksiyon değiştirildiğinde, eski sistem kapatılır – read-only snapshot olarak arşivlenir, asla doğrudan silinmez.

Temel avantaj: Her adım geri dönülebilir. Yeni web uygulamasının bir modülü kırılırsa yönlendirmeyi geri çevirirsin. Eski sistem düşmanın değil, emniyet ağındır.

Faz 1: Mevcut Süreçlerin Analizi ve Haritalanması

Tek bir kod satırı yazılmadan önce büyümüş gerçeği haritalarız. Organizasyon el kitabında yazanı değil – gerçekte olanı.

Faz 1'in Üç Aracı

1. Process Walking: Bir gün her power-user'ın yanına oturuyoruz. Neyin tıklandığını, kopyalandığını, export edildiğini izliyoruz. Gerçek mantığın %80'i hiçbir yerde belgelenmemiştir.
2. Veri akış diyagramı: Hangi tablo hangisini besliyor? Bağlantı nerede kırılıyor? Hangi çalışan tek kırılma noktası?
3. Edge case envanteri: İptaller, özel fiyatlar, özel anlaşmalı müşteriler, çeyrek kapanışları, GoBD exportları. "Aslında bu biraz farklı" denilen her özel durum.

Faz 1 Sonunda Ortaya Çıkan

Bu faz sıkça hafife alınır – ve tam bu yüzden migrasyonların raydan çıkmasının en yaygın sebebidir. Burada kestirme yapan, aynı kaosu daha güzel bir arayüzde yeniden inşa eder.

Faz 2: Paralel İşletim – Yeni Web Uygulaması Eski Sistemin Yanında Çalışır

Faz 2'de paydaşların çoğunu önce endişelendiren şey başlar: iki sistem aynı anda. Çift iş gibi gelir – ama Big-Bang riskinin tam tersidir.

Paralel İşletimin Üç Sütunu

1. Yönlendirme & API Gateway: Bir reverse proxy (Nginx, Traefik, Cloudflare Workers) istek başına hangi sistemin yanıt vereceğine karar verir. Örnek: "Yeni sipariş kaydı" → yeni web uygulaması. "Stok bakiyeleri" → hâlâ eski sistem. Çalışan tek bir URL görür.

2. Tek Doğru Kaynaklı Dual Write'lar: Bir modül migrate edilirken, yeni web uygulaması paralel olarak eski sisteme de yazar – ya da tersi. İki veri kaynağından biri ana kaynaktır, diğeri sürekli karşılaştırılır. Avantajı: Reporting araçları, SAP arayüzleri veya mali müşavir exportları kimse onları uyarlamadan çalışmaya devam eder.

3. Gölge Doğrulama: Yeni web uygulamasındaki her istek paralel olarak eski sistemde de çalıştırılır – sadece karşılaştırma için, yazma için değil. Sonuçlar iki hafta boyunca %100 örtüşüyorsa modül migrate olmaya hazırdır. CTO veriye dayanarak karar verir, içgüdüye değil.

Tipik Modül Değişim Sırası

1. Önce okuma erişimleri (raporlar, dashboard'lar) – düşük risk, yüksek fayda
2. Kayıt iş akışları (sipariş girişi, ana veri bakımı) – orta risk, çok yüksek fayda
3. Muhasebe modülleri en son – en yüksek uyumluluk riski, bu yüzden tam gölge doğrulama ile en sona

Bu fazın UX'i kabul için belirleyicidir – web uygulamalarında UX tasarımı ve müşteri sadakati cluster yazımızda detaylı işliyoruz. Yeni aracı tehdit değil yardım olarak gören çalışanlar her migrasyonu haftalarca hızlandırır.

Faz 3: Veri Kaybı Olmadan Veri Migrasyonu (Excel, Access, SAP Exportları için Stratejiler)

Faz 3, migrasyonların devrildiği noktadır. Teknik yüzünden değil – yıllarca kimsenin görmek istemediği kirli veri yüzünden. Mükerrer müşteriler, kirli veri tipleri, "açıklamaya bak" yazılı alanlar, üç farklı Excel versiyonundan gelen kopyalar.

ETL Pipeline (Extract, Transform, Load)

[Eski sistem]  →  Extract  →  Validate  →  Transform  →  Load  →  [Yeni web app]
   Excel          CSV /         Şema          Mapping       DB
   Access         SQL Query     kontrolü      temizlik      API
   SAP            BAPI / IDoc   Constraints   normalize

Her adım versiyonlanır ve tekrar üretilebilir kurulur. Import kırılırsa rollback yapılır. Asla "bunu bir kerelik elle düzelteceğiz" denmez – her el düzeltmesi, gelecekteki bir tutarsızlıktır.

Kaynağa Özel Stratejiler

Excel:

• Kaynakları önce read-only snapshot'ta dondur
• İlk temizlik için Power Query veya Python Pandas
• Sütun mapping'lerini belgele (eski ad → yeni alan → veri tipi → constraint)
• Formülleri asla kontrolsüz devralma – çoğu zaman yanlış veya güncel değildir

Access:

• ODBC üzerinden SQL şemalarını export et
• İlişki tablolarını tanımla (Access ilişkiseldir – kullanıcıların çoğu bunu bilmez)
• VBA modüllerini ayrı belgele – gerçek iş mantığını içerirler

SAP / DATEV / ERP exportları:

• CSV sihrinin yerine BAPI veya OData arayüzleri
• Master data SAP'ta ana kaynaktır, transactional veriler taşınır – bu sırayı tersine çevirme
• GoBD uyumluluğu için mali müşaviri erken dahil et

Cutover Öncesi Emniyet Ağı

1. Eski sistemin read-only snapshot'ı backup storage'da – her zaman erişilebilir, asla silinmez
2. Reverse migration yolu hazır: yeni modül devrildiğinde 24 saat içinde nasıl geri dönülür
3. Migrate edilen her kayıt için audit log – kim ne zaman nereden nereye migrate edildi, hash checksum ile

Burada temiz çalışan sadece veri güvenliği değil, E-E-A-T güven sinyallerini de kazanır – mali denetçiler ve ISO denetimcileri denetlenebilir migrasyon yollarına bayılır.

Gerçek Vaka: Bir Orta Ölçekli İşletmenin Sipariş Kaydını Modernize Edişi

Hannover merkezli bir toptancı (40 çalışan, ay başına 8.000 sipariş) bize şu durumla geldi: 2013 yılından kalma bir Access veritabanında sipariş kaydı, dört ayrı Excel sheet'inde stok, manuel olarak SAP'tan export edilip yeniden girilen sevkiyat etiketleri. Üç tam zamanlı çalışan vaktinin %60'ını veri bakımıyla geçiriyordu.

6 Ayda Yol (Özet)

Ay 1 – Faz 1 (Discovery):

• 4 gün process walking, power-user başına 1 gün
• 38 edge case tanımlandı (iskontolu iptaller, sezonsal fiyatlar, B2B özel anlaşmalar dahil)
• Veri modeli: 4 Excel sheet yerine 17 tablo planlandı

Ay 2–3 – Faz 2 (Paralel işletim başlar):

• Reverse proxy üzerinden login switch
• Modül 1: Ana veri bakımı yeni web uygulamasında canlı – Access ana kaynak, dual write
• 4 hafta gölge doğrulama, %99,98 veri özdeşliği

Ay 4 – Modül 2: Sipariş kaydı:

• Yeni web uygulaması ana kaynak, Access read-only
• Yapay zekâ destekli mantık kontrolü (yapay zekâ otomasyonu ile destek maliyetlerini düşürme cluster mantığı üzerinden bağlandı)
• Sipariş başına kayıt süresi: 4:30 dakikadan 1:10 dakikaya

Ay 5 – Modül 3: Stok ve SAP senkronu:

• SAP'a OData arayüzü, artık CSV gidip gelmesi yok
• Excel sheet'ler read-only snapshot olarak arşivlendi

Ay 6 – Cutover ve devre dışı bırakma:

• Access sunucusu kapatıldı, snapshot soğuk depoda
• Eğitim, dokümantasyon, devir teslim

6 Ay Sonrası Ölçülebilir Sonuçlar

Bu detay seviyesini her Hannover web uygulaması projemize entegre ediyoruz – güzel göründüğü için değil, bir migrasyonun parasını ettiğini kanıtlayan tek dürüst yöntem ölçülebilir KPI olduğu için.

Maliyet Hesabı: Bir Değişim Gerçekte Ne Tutar – Durağanlık Ne Tutar

Duyduğumuz en pahalı soru: "Bu bize ne tutar?". Doğru soru şu: "Hiçbir şey yapmamak bize ne tutar?".

Örnek Hesaplama Orta Ölçekli İşletme (40–80 çalışan)

Strangler Fig migrasyon yatırımı:

Yıllık durağanlık maliyeti (mevcut durum):

Break-Even: 60.000 € yatırım ve yıllık ~250.000 € tasarruf ile break-even noktası tam işletime geçişten 4 aydan kısa süre sonra ulaşılır. %80 gerçekleşme oranıyla bile proje ilk yılında kendini amorti eder.

Sonuç: Eski Sistemleri Değiştirmek Risk Azaltmaktır, BT Modernize Etmek Değil

Eski sistemleri değiştirmek bir teknoloji fetişi değildir. Risk yönetiminin en dürüst halidir – ve Big-Bang'den ölçülebilir derecede daha iyi çalışır. Strangler Fig yaklaşımı, başka hiçbir migrasyonun veremeyeceği dört şey sunar: kesintisizlik, her an geri dönülebilirlik, veri güvenliği, çalışan dostluğu. Bu metodolojik bir dogma değil, on yılı aşkın orta ölçekli işletme deneyiminin sonucudur.

Bir sonraki adım RFP yazmak veya şartname basmak değil. Bir sonraki adım, daha önce bu tür düzinelerce migrasyonu temiz tamamlamış biriyle dürüst bir Discovery fazıdır. Arka plandaki mimari nasıl nefes aldığını görmek istersen Custom Code vs. hazır paket karşılaştırmamızı oku – ve stratejik çerçeveyi arıyorsan en iyisi Web Uygulaması Geliştirme Rehberimizden başla.

Cagri Ersöz

Gölge BT'ni kesintisiz değiştirmeye hazır mısın?

2 hafta içinde Excel, Access ve ERP ada çözümlerini haritalayıp ilk üç migre edilebilir modülü tanımlıyoruz ve sana iş senaryosu dahil bir Strangler Fig yol haritası kuruyoruz. Pragmatik, Hannover'den, vendor lock-in olmadan.

Migrasyon Discovery Talep Et