Eski özel yazılımla yapılmış siteyi yenilemek: veriyi kaybetmeden geçiş

Sitenizi on yıl kadar önce bir yazılım firması size özel geliştirdi. Ürün kataloğu, bayi girişi, teklif formu, belki küçük bir sipariş modülü var. Firma artık yok ya da projeyi yapan geliştirici ayrıldı. Site çalışıyor ama kimse dokunmaya cesaret edemiyor. Yenileme kararı verildiğinde ilk soru tasarım değil, şu olmalı: bu sistemin içindeki veriyi nasıl eksiksiz çıkaracağız?

Siteniz özel yazılım değil de WordPress üzerindeyse, WordPress'ten geçiş yazımız size daha yakın olacaktır.

Önce erişim: kaynak kod ve veritabanı elinizde mi?

Özel yazılımlarda her şey erişimle başlar. Yeni bir firmayla konuşmadan önce şunları netleştirin:

Bu sorulardan birinin cevabı "bilmiyoruz" ise, ilk iş o erişimi geri almaktır. Veritabanına erişim yoksa geriye yalnız canlı siteyi tarayarak içerik toplamak kalır; bu da üye, sipariş ve form kayıtlarının dışarıda kalması demektir.

Veri modelini çıkarmak neden şart?

Veri modeli, sistemin hangi bilgiyi hangi tabloda ve hangi ilişkilerle sakladığının haritasıdır. Eski özel yazılımlarda bu harita genellikle belgelenmemiştir; tablo adları kısaltmalıdır, bazı alanlar artık kullanılmıyordur, bazı bilgiler beklenmedik yerlerde durur.

Geçişlerde önce tabloları ve alanları tek tek listeliyoruz, ardından her birinin yeni sistemde nereye karşılık geleceğini yazıyoruz. Bu çalışma üç soruyu cevaplar:

1. Hangi veri taşınacak (ürünler, sayfalar, üyeler, siparişler)?
2. Hangi veri arşivlenip taşınmayacak (eski kampanyalar, test kayıtları)?
3. Hangi veri silinmeli (artık gerekmeyen kişisel veriler)?

Çok dilli içerik, ürün varyantları ve kategori ağaçları gibi ilişkili yapılar en çok dikkat isteyen kısımlardır. Bir ürünün İngilizce açıklaması ayrı bir tabloda duruyorsa ve bu ilişki gözden kaçarsa, yeni sitede o dil eksik açılır.

Dinamik adresler (?id=) nasıl yönlendirilir?

Eski özel yazılımlarda adresler çoğu zaman şöyle görünür: /urun.php?id=125 ya da /sayfa.asp?kat=3&id=48. Yeni sistemde ise aynı ürün /tr/urunler/celik-raf gibi okunabilir bir adreste olacaktır.

Bu adresler de arama sonuçlarında ve başka sitelerdeki bağlantılarda yaşar; her birinin yeni karşılığına 301 (kalıcı) yönlendirmeyle bağlanması gerekir. Burada veri modeli işe yarar: eski veritabanındaki kimlik numarasını (id=125) yeni sistemdeki kayda eşlerseniz, yüzlerce adresin yönlendirme tablosu otomatik üretilebilir.

Dikkat edilecek nokta, aynı sayfanın birden fazla adresle açılıyor olmasıdır: parametre sırası farklı, büyük-küçük harf farklı ya da gereksiz ek parametreli sürümler. Arama sonuçlarında ve geri bağlantılarda görünen sürümleri tespit edip tabloya ekleyin. Eşleme tablosu, zincirsiz yönlendirme ve lansman sonrası izleme adımlarını site taşıma ve 301 yönlendirme rehberimizde ayrıntılı anlattık.

Üye, sipariş ve form verisi: KVKK açısından nelere dikkat edilir?

Üye hesapları, sipariş geçmişi ve form gönderimleri kişisel veri içerir. Bu verileri taşımak, 6698 sayılı Kişisel Verilerin Korunması Kanunu açısından da bir veri işleme faaliyetidir. Kanunun genel ilkeleri geçiş planına doğrudan yansır:

• Ölçülülük: Kişisel veri, işlenme amacıyla bağlantılı, sınırlı ve ölçülü olmalıdır. Yıllardır kullanılmayan ve saklama gerekçesi kalmamış kayıtları yeni sisteme taşımak yerine, saklama ve imha politikanıza göre değerlendirin.
• Saklama süresi: Veri, mevzuatta öngörülen ya da işleme amacının gerektirdiği süre kadar tutulur. Sipariş ve fatura kayıtları ile pazarlama izinleri farklı sürelere tabi olabilir.
• Güvenlik: Veri sorumlusunun uygun güvenlik düzeyini sağlayacak teknik ve idari tedbirleri alması gerekir. Taşıma sırasında veritabanı dökümlerinin şifreli aktarılması, erişimin yalnız ilgili kişilerle sınırlandırılması ve geçici kopyaların iş bitince silinmesi bu kapsamdadır.
• Sunucunun yeri: Yeni sistem yurt dışındaki bir sunucuda çalışacaksa, kişisel verilerin yurt dışına aktarımına ilişkin koşullar devreye girebilir.

Bu bölüm bilgi amaçlıdır; kendi durumunuz için hukuk danışmanınızla teyit edin.

Üye parolaları için de bir not: iyi kurulmuş sistemlerde parolalar açık metin değil, özet (hash) olarak saklanır. Yeni sistem eski özet yöntemini destekliyorsa hesaplar sorunsuz taşınır; desteklemiyorsa kullanıcılardan ilk girişte parolalarını yenilemelerini istemek daha güvenli bir yoldur. Bunu lansmandan önce kullanıcılara duyurun.

Entegrasyonlar: ERP, CRM ve diğerleri

Eski site çoğu zaman yalnız değildir. Stok bilgisini ERP'den çekiyor, teklif formlarını CRM'e gönderiyor, siparişleri muhasebe yazılımına aktarıyor olabilir. Bu bağlantılar belgelenmemişse ancak bozulduklarında fark edilir.

Her entegrasyon için şunları yazıya dökün: hangi veri, hangi yönde, ne sıklıkla, hangi yöntemle (API, dosya aktarımı, doğrudan veritabanı bağlantısı) akıyor? Yeni sistemde bu akışın nasıl kurulacağını ve test ortamında gerçek verilerle nasıl deneneceğini planlayın.

Eski sistemin değeri ekranda değil, arka planda sessizce yaptığı işlerdedir.

Paralel çalıştırma ve kesinti planı

Sipariş ya da üye kaydı alan bir sitede geçiş tek bir anda olmaz. Önerdiğimiz yol, yeni sistemi bir süre eski sistemle paralel çalıştırmaktır:

1. Deneme aktarımı: Verinin tamamı test ortamına aktarılır, sayılar ve örnek kayıtlar eski sistemle karşılaştırılır.
2. Paralel dönem: Yeni sistem kapalı bir adreste çalışır; ekip gerçek senaryoları dener, entegrasyonlar test edilir.
3. Son aktarım: Geçiş günü eski sistem kısa bir süre yeni kayıt almaya kapatılır, son veriler aktarılır ve alan adı yeni sisteme yönlendirilir.

Kesinti penceresini trafiğin en düşük olduğu saate planlayın ve kullanıcılara önceden duyurun. Mümkünse büyük değişiklikleri sırayla yapın: altyapı, adres yapısı ve tasarım aynı gün değiştiğinde bir sorunun kaynağını bulmak zorlaşır.

Geri dönüş planı neden gerekli?

Her şey test edilmiş olsa da geçiş günü beklenmedik bir sorun çıkabilir. Geri dönüş planı, bu durumda ne yapılacağının önceden yazılmış hâlidir:

• Eski sistem ve veritabanı, geçişten sonra belirli bir süre dokunulmadan saklanır.
• DNS değişikliğinin nasıl geri alınacağı ve bunun ne kadar süreceği bilinir.
• Geçiş sonrası yeni sistemde oluşan kayıtların (yeni sipariş, yeni üye) geri dönüşte nasıl korunacağı kararlaştırılır.
• Geri dönüş kararını kimin, hangi koşulda vereceği bellidir.

Çoğu geçişte bu plan hiç kullanılmaz. Ama varlığı, geçiş gününün baskı altında değil, sakin bir şekilde yönetilmesini sağlar.

Sonuç

Eski bir özel yazılımı yenilemenin zor kısmı yeni siteyi yapmak değil, eskisinin içindeki veriyi ve bağlantıları eksiksiz anlamaktır. Erişimi güvenceye alın, veri modelini çıkarın, adresleri ve entegrasyonları listeleyin ve geçişi geri dönüş planıyla yapın. Yazılım ve entegrasyon projelerimizde eski sistemlerden veri taşımayı bu sırayla ele alıyoruz.