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

SaaS Sağlayıcısı Değiştirirken Veri Kaybı Nasıl Önlenir? - Yazdırılabilir Versiyon

+- Dataweb Forum (https://dataweb.com.tr/forum/yazilim-saas)
+--- Konu: SaaS Sağlayıcısı Değiştirirken Veri Kaybı Nasıl Önlenir? (/https://dataweb.com.tr/forum/saas-saglayicisi-degistirirken-veri-kaybi-nasil-onlenir-88)

SaaS Sağlayıcısı Değiştirirken Veri Kaybı Nasıl Önlenir? - Kadir - 09-12-2026

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:
müşteri
sipariş
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:
00 → Eski sistem export alındı
00 → Eski sisteme yeni müşteri eklendi
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:

Alıntı: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

Veri envanteri çıkarıldı mı?
Kayıt adetleri alındı mı?
Tam export var mı?
Dosyalar alındı mı?
Özel alanlar eşlendi mi?
ID ilişkileri korunuyor mu?
Tarih ve encoding test edildi mi?
Pilot migration yapıldı mı?
Entegrasyonlar listelendi mi?
Webhook'lar güncellendi mi?
Otomasyonlar yeniden kuruldu mu?
Roller oluşturuldu mu?
Cutover zamanı belirlendi mi?
Delta veri taşındı mı?
Kayıt adetleri karşılaştırıldı mı?
Kullanıcı kabul testi yapıldı mı?
Eski sistem yedeği alındı mı?
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.