SaaS Sağlayıcısı Değiştirirken Veri Kaybı Nasıl Önlenir?

[Kadir]

Bir SaaS sağlayıcısını değiştirmek yalnızca eski aboneliği kapatıp yeni hesabı açmak değildir. Müşteri kayıtları, dosyalar, kullanıcılar, otomasyonlar, entegrasyonlar, webhook'lar ve geçmiş hareketler eksik taşınırsa yeni sistem çalışıyor görünse bile önemli işletme verileri kaybolabilir.

Bu rehberde bir SaaS sisteminden başka bir sisteme geçerken veri kaybını önlemek için taşıma öncesi, taşıma sırası ve eski sistemi kapatmadan önce yapılması gereken kontrolleri adım adım inceleyeceğiz.


1. Önce taşınacak veri envanterini çıkarın

Eski sistemde hangi veri türlerinin bulunduğunu listeleyin.

Örneğin:

• Müşteriler
  
• Kullanıcılar
  
• Siparişler
  
• Teklifler
  
• Dosyalar
  
• Notlar
  
• Görevler
  
• Etiketler
  
• Özel alanlar
  
• Audit log
  

Yalnız ana tabloyu taşımak yeterli olmayabilir.


2. Veri miktarını ölçün

Taşıma öncesi adetleri kaydedin.

Örneğin:

Kod:

Müşteri: 12.480 Sipariş: 88.310 Dosya: 24.512 Aktif kullanıcı: 37

Taşıma sonrası aynı sayıları karşılaştırabilirsiniz.


3. Tam export alın

Eski sağlayıcı destekliyorsa:

• CSV
  
• Excel
  
• JSON
  
• API export
  
• Dosya arşivi
  

alın.

Tek export yöntemine güvenmeden kritik verilerin ayrı yedeğini değerlendirin.


4. Dosya eklerini unutmayın

CSV içerisinde müşteri kayıtları olabilir ancak:

• PDF
  
• Fatura
  
• Fotoğraf
  
• Sözleşme
  
• Dosya eki
  

bulunmayabilir.

Export'un ek dosyaları kapsayıp kapsamadığını kontrol edin.


5. Özel alanları eşleştirin

Eski sistemde:

Kod:

customer_type sales_region contract_end

gibi özel alanlar olabilir.

Yeni sistemde bunların hangi alanlara taşınacağını önceden belirleyin.


6. ID ilişkilerini koruyun

Örneğin:

Kod:

Müşteri 105 ↓ Sipariş 992 ↓ Fatura 7001

ilişkisi bozulmamalıdır.

Yeni sistem farklı ID üretecekse eski ID'yi ayrı bir referans alanında tutmak faydalı olabilir.


7. Tarih ve saat formatlarını kontrol edin

Eski sistem:

Kod:

2026-09-12 15:30 Europe/Istanbul

kullanırken yeni sistem UTC saklıyor olabilir.

Taşıma sonrası kayıt tarihleri birkaç saat kayabilir.

Timezone dönüşümünü önceden test edin.


8. Karakter kodlamasını test edin

Türkçe verilerde özellikle:

Kod:

İ ı Ş ş Ğ ğ Ç ç Ö ö Ü ü

karakterlerinin doğru taşındığını kontrol edin.

CSV encoding hataları isim ve adresleri bozabilir.


9. Önce küçük bir pilot taşıma yapın

Bütün veriyi tek seferde taşımadan önce örneğin:

Kod:

50 müşteri 100 sipariş 20 dosya

ile test yapın.

Kontrol edin:

• Alanlar doğru mu?
  
• Türkçe karakterler doğru mu?
  
• Dosyalar açılıyor mu?
  
• İlişkiler korunuyor mu?
  

10. Entegrasyonları envantere alın

Eski SaaS şu sistemlere bağlı olabilir:

• Web sitesi
  
• Muhasebe
  
• Ödeme sistemi
  
• CRM
  
• E-posta
  
• Slack
  
• ERP
  

Veriyi taşımak bu entegrasyonları otomatik taşımaz.

Yeni sağlayıcıya geçişte API yapısı değişiyorsa bağlantıları yeniden test edin. 401, 403, 429 veya 500 hataları için API Bağlantısı Çalışmıyor rehberindeki kontrol sırasını uygulayabilirsiniz.

11. API anahtarlarını yeni sistem için yeniden yapılandırın

Eski SaaS'a ait:

Kod:

API key Access token Client secret

yeni sistemde çalışmaz.

Bağlantıları ayrı ayrı güncelleyin.


12. Webhook URL ve event'lerini yeniden kontrol edin

Eski sistem:

Kod:

order.created

gönderirken yeni sistem farklı event adı kullanabilir.

Webhook entegrasyonlarını gerçek test event'i ile doğrulayın.

Yeni sistemde webhook teslimatları ulaşmıyorsa URL, event, signature ve retry kontrollerini Webhook Çalışmıyor: Olaylar Neden Ulaşmıyor ve Nasıl Test Edilir? rehberine göre yapabilirsiniz.

13. Otomasyonları belgeleyin

Eski SaaS içerisinde:

Kod:

Yeni lead ↓ Satışçı ata ↓ E-posta gönder ↓ 3 gün sonra görev aç

gibi otomasyonlar olabilir.

Veri export'u bu iş akışlarını taşımayabilir.

Her otomasyonu ayrı listeleyin.


14. Kullanıcı rollerini yeniden oluşturun

Eski sistemde:

Kod:

Admin Satış Destek Finans

rolleri bulunabilir.

Yeni sistemde benzer yetkilendirmeyi kurmadan kullanıcıları davet etmeyin.


15. Aynı anda iki sistemin yazmasını dikkatli yönetin

Taşıma sırasında eski ve yeni sistem ikisi de aktifse veriler bölünebilir.

Örneğin:

Kod:

09:00 → Eski sistem export alındı 11:00 → Eski sisteme yeni müşteri eklendi 13:00 → Yeni sistem açıldı

11:00'de eklenen müşteri ilk export'ta yoktur.

Bu nedenle delta migration veya kısa bir veri dondurma penceresi gerekebilir.


16. Cutover zamanı belirleyin

Net bir geçiş zamanı seçin.

Örneğin:

Kod:

Cumartesi 23:00 Eski sistem salt okunur Son delta export Yeni sisteme import Kontrol Yeni sistem aktif

gibi plan oluşturulabilir.


17. Taşıma sonrası kayıt adetlerini karşılaştırın

Eski:

Kod:

12.480 müşteri

Yeni:

Kod:

12.201 müşteri

ise:

Kod:

279 kayıt

neden eksik araştırılmalıdır.

Sadece:

Panel açılıyor, taşıma tamam.

demeyin.


18. Rastgele örnek kayıtları manuel kontrol edin

Sadece toplam sayı yetmez.

Eski ve yeni sistemde farklı tarihlerden örnek kayıtları karşılaştırın.

Kontrol edin:

• İsim
  
• E-posta
  
• Telefon
  
• Tarih
  
• Dosya
  
• Notlar
  
• İlişkili kayıtlar
  

19. Kullanıcılarla gerçek kabul testi yapın

Satış personeli:

Kod:

Müşteri bulabiliyor mu?

Finans:

Kod:

Rapor alabiliyor mu?

Destek:

Kod:

Geçmiş ticket'ı görebiliyor mu?

gibi gerçek kullanım testleri yapmalıdır.


20. Eski sistemi hemen iptal etmeyin

Yeni sistem ilk gün çalışıyor diye eski SaaS aboneliğini anında kapatmayın.

Belirli süre:

salt okunur referans

olarak tutmak faydalı olabilir.

Süre işletmenin veri hassasiyetine ve sözleşmeye göre belirlenmelidir.


21. Eski sistem kapanmadan son export alın

İptal öncesinde mümkün olan en güncel:

• Veritabanı export
  
• Dosya arşivi
  
• Kullanıcı listesi
  
• Rapor
  

yedeklerini alın.


22. Veri saklama politikasını öğrenin

Abonelik iptal edildiğinde sağlayıcı verilerinizi:

Kod:

hemen 30 gün sonra 90 gün sonra

silebilir.

Bu süreyi varsaymayın.

Sözleşme ve sağlayıcı dokümantasyonundan doğrulayın.


23. Eski API ve kullanıcı erişimlerini kapatın

Taşıma tamamlandıktan sonra:

• Eski kullanıcılar
  
• API anahtarları
  
• OAuth uygulamaları
  
• Webhook endpoint'leri
  

gereksiz yere açık kalmamalıdır.

Geçiş tamamlandıktan sonra eski hesapları yalnız pasifleştirmekle yetinmeyin. Kullanıcı rolleri, 2FA, eski API anahtarları ve harici uygulama erişimlerini SaaS Güvenliği kontrol listesiyle yeniden denetleyin.

24. Yeni sistemin yedeğini de alın

Taşıma tamamlandıktan sonra yeni SaaS'ın export imkanlarını kullanarak ilk doğrulanmış veri setinin bir kopyasını saklayın.

Böylece:

taşıma sonrası temiz başlangıç noktası

oluşturabilirsiniz.


25. Yeni SaaS'ı seçerken çıkış planını baştan düşünün

Bir sonraki sağlayıcı seçiminde:

• Export
  
• API
  
• Veri sahipliği
  
• Dosya indirme
  
• İptal sonrası saklama süresi
  

kriterlerini satın alma öncesinde değerlendirin.


SaaS taşıma hızlı kontrol listesi

1. Veri envanteri çıkarıldı mı?
   
2. Kayıt adetleri alındı mı?
   
3. Tam export var mı?
   
4. Dosyalar alındı mı?
   
5. Özel alanlar eşlendi mi?
   
6. ID ilişkileri korunuyor mu?
   
7. Tarih ve encoding test edildi mi?
   
8. Pilot migration yapıldı mı?
   
9. Entegrasyonlar listelendi mi?
   
10. Webhook'lar güncellendi mi?
    
11. Otomasyonlar yeniden kuruldu mu?
    
12. Roller oluşturuldu mu?
    
13. Cutover zamanı belirlendi mi?
    
14. Delta veri taşındı mı?
    
15. Kayıt adetleri karşılaştırıldı mı?
    
16. Kullanıcı kabul testi yapıldı mı?
    
17. Eski sistem yedeği alındı mı?
    
18. Eski sistem ancak doğrulamadan sonra kapatıldı mı?
    

SaaS maliyetini taşıma kararına dahil edin

Bir sistemi yalnız aylık ücreti yükseldi diye değiştirmek de her zaman ekonomik olmayabilir.

Taşımanın:

• Geliştirme
  
• Eğitim
  
• Veri temizleme
  
• Entegrasyon
  
• Operasyon kesintisi
  

maliyetleri vardır.

Mevcut aboneliklerin gerçek şirket maliyetini SaaS Abonelikleri Şirket Giderini Sessizce Nasıl Büyütüyor? konusunda ayrıca değerlendirebilirsiniz.


Sonuç

SaaS sağlayıcısı değiştirirken güvenli geçiş:

Envanter → yedek → pilot → eşleştirme → entegrasyon → final taşıma → doğrulama → eski sistemi kapatma

sırasıyla yapılmalıdır.

En kritik hata eski sistemi çok erken iptal etmektir.

Yeni SaaS'ta verilerin yalnızca görünmesi yeterli değildir; kayıt sayılarının, ilişkilerin, dosyaların, kullanıcı yetkilerinin ve otomasyonların gerçek iş sürecinde doğru çalıştığı doğrulanmadan eski sistemi kalıcı olarak kapatmayın.