Bulut ve SaaS çıkış planı; sözleşmenin bitmesi, fiyat artışı, hizmet bozulması, güvenlik olayı, birleşme veya sağlayıcı iflası gibi durumlarda veriyi, uygulamayı, entegrasyonları, kimlikleri ve operasyonu kabul edilebilir süre ve maliyetle başka ortama taşıma yöntemidir. Çıkış yapılabilirliği yalnız “veri dışa aktarımı var” beyanıyla değil, format, süre, bütünlük, bağımlılık, paralel çalışma ve silme testiyle doğrulanmalıdır.
Çıkış planı satın alma kararının bir parçasıdır
Tedarikçiden çıkış; yalnız sözleşmeyi feshetmek değildir. Veriyi eksiksiz almak, iş mantığını yeniden kurmak, kullanıcıları taşımak, entegrasyonları değiştirmek, kayıt ve kanıtları korumak, eski erişimleri kapatmak ve hizmet kesintisini yönetmek gerekir. Bu işlemlerin maliyeti ve süresi seçim aşamasında görünür değilse toplam sahip olma maliyeti eksik hesaplanır.
AB Data Act, veri işleme hizmetleri arasında geçişi kolaylaştırmayı ve bulut pazarında kilitlenmeyi azaltmayı hedefleyen kurallar getirir. Bu düzenleme bütün kurumlara aynı hukuki yükümlülüğü getirmese bile, iyi bir sözleşme ve teknik tasarım için güçlü bir taşınabilirlik referansıdır.
Çıkışın tetikleyicileri de önceden sınıflandırılmalıdır. Planlı sözleşme yenilememe, aşırı fiyat artışı, stratejik platform değişimi ve birleşme gibi durumlarda uzun geçiş takvimi kurulabilir. Kritik güvenlik olayı, iflas, yaptırım, veri erişiminin kaybı veya sürekli hizmet kesintisinde ise hızlandırılmış çıkış gerekebilir. İki senaryo aynı personel, onay ve kesinti toleransıyla yönetilemez. Bu nedenle normal geçiş, hızlandırılmış geçiş ve acil izolasyon için ayrı karar sahipleri, asgari veri kopyaları, iletişim kanalları ve kabul edilebilir hizmet kaybı tanımlanmalıdır.
Önce bağımlılık envanteri çıkarılmalıdır
| Bağımlılık | Sorulacak soru | Çıkış kanıtı | Risk |
|---|---|---|---|
| Veri | Hangi kayıt, dosya, log ve metadata tutuluyor? | Örnek tam ihracat ve veri sözlüğü. | Eksik veya kapalı format. |
| İş mantığı | Hangi kural ve otomasyon sağlayıcıya özgü? | Konfigürasyon ve süreç dokümantasyonu. | Gizli/taşınamaz iş akışı. |
| Entegrasyon | Hangi API, webhook ve kimlik bağlantısı var? | Entegrasyon envanteri ve test hesabı. | Kesinti ve veri kaybı. |
| Kimlik | Hangi kullanıcı, rol ve servis hesabı bağlı? | Hesap ve anahtar kapanış listesi. | Yetkisiz erişimin sürmesi. |
| Rapor/kanıt | Hangi audit, finansal veya uyum kaydı gerekli? | Okunabilir arşiv ve saklama planı. | Denetim kanıtının kaybı. |
| İnsan | Hangi uzmanlık yalnız sağlayıcı veya danışmanda? | Bilgi transferi ve operasyon kitabı. | Anahtar kişiye bağımlılık. |
Veri taşınabilirliği format, bütünlük ve zaman meselesidir
- Kapsam: Ana kayıtlar, ekler, geçmiş sürümler, yorumlar, loglar, ilişkiler ve konfigürasyon.
- Format: Makine-okunur, belgelenmiş ve yeni sisteme aktarılabilir yapı.
- Bütünlük: Kayıt sayısı, hash, ilişki ve zorunlu alan kontrolü.
- Süre: İlk ihracat, artımlı senkronizasyon ve son kesim takvimi.
- Erişim: Sözleşme sona erdikten sonra geçici okuma veya yeniden indirme süresi.
- Maliyet: API, egress, profesyonel hizmet ve veri hazırlama ücretleri.
- Gizlilik: Aktarım sırasında şifreleme, erişim ve geçici kopya yönetimi.
İhracat dosyasının açılması yeterli değildir. Yeni sistemde temel iş süreçleri ve raporlar aynı veriyle yeniden üretilebilmeli, kayıt kaybı ve ilişki bozulması ölçülmelidir.
Uygulama ve entegrasyon taşınabilirliği ayrıca tasarlanmalıdır
Özel geliştirme
Script, fonksiyon, iş akışı ve düşük kodlu uygulamaların sahipliği ve ihracı belirlenir.
Bağlantılar
Endpoint, kapsam, rate limit, webhook ve hata yönetimi dokümante edilir.
SSO ve roller
Kimlik sağlayıcı, grup, rol ve servis hesabı eşlemeleri taşınır.
İşletim bilgisi
Alarm, iş takvimi, destek prosedürü ve manuel istisnalar kaydedilir.
Sağlayıcıya özgü özellikler kullanım değerini artırabilir; ancak her kritik özellik için alternatif, yeniden geliştirme maliyeti veya bilinçli kabul kararı bulunmalıdır.
Kimlik, anahtar ve güvenlik kontrolleri kapanışın merkezindedir
- Kullanıcı ve yönetici hesaplarının devre dışı bırakılması.
- API anahtarı, token, sertifika ve webhook sırlarının iptali.
- Sağlayıcının kurum sistemlerindeki uygulama yetkilerinin kaldırılması.
- VPN, IP izin listesi ve destek erişimlerinin kapatılması.
- Eski ajan, connector veya senkronizasyon işlerinin durdurulması.
- Olay ve audit kayıtlarının gerekli saklama ortamına alınması.
- Geçiş sırasında çift yetki ve ayrıcalıklı hesapların izlenmesi.
Sözleşmede ölçülebilir geçiş ve çıkış şartları bulunmalıdır
| Konu | Güçlü ifade | Zayıf ifade |
|---|---|---|
| Geçiş desteği | Kapsam, süre, sorumlu, saat ve ücret açık. | “Makul destek sağlanır.” |
| Veri ihracı | Format, kapsam, API, sıklık ve teslim süresi tanımlı. | Yalnız genel dışa aktarma hakkı. |
| İş sürekliliği | Fesih ve geçiş boyunca hizmet seviyesi ve güvenlik korunur. | Fesih bildirimiyle hizmet hemen kısıtlanabilir. |
| Silme | Aktif veri, yedek, log ve alt işleyen süreleri ile teyit. | “Veriler silinir.” |
| Maliyet | Egress, ihracat ve profesyonel hizmet tarifesi sınırlandırılmış. | Çıkış ücretleri sağlayıcının güncel tarifesine bağlı. |
| Alt işleyen | Geçiş ve silme yükümlülüğü alt zincire uygulanır. | Alt işleyenler kapsam dışı. |
Geçiş planı iş sürekliliği planıyla birleşmelidir
Büyük geçişlerde tek gün kesim yerine keşif, veri provası, paralel çalışma, artımlı senkronizasyon, kullanıcı kabulü ve son kesim aşamaları gerekir. Her aşama için geri dönüş noktası ve kabul ölçütü tanımlanmalıdır.
- Hazırlık: Kapsam, sahiplik, veri ve bağımlılıklar dondurulur.
- Prova: Tam veri ihracı ve yeni ortama yükleme test edilir.
- Paralel dönem: Kritik işlemler iki sistemde karşılaştırılır.
- Kesim: Değişiklik penceresi, son senkronizasyon ve kullanıcı geçişi yapılır.
- Stabilizasyon: Hata, performans ve veri bütünlüğü izlenir.
- Kapanış: Eski sistem erişimleri kaldırılır ve silme kanıtı alınır.
Silme beyanı kapsam ve kanıt taşımalıdır
Aktif veri tabanından silinen kayıt; yedek, log, analitik, destek sistemi veya alt sağlayıcıda kalabilir. Silme planı; hangi veri sınıfının hangi ortamda ne kadar süre tutulacağını, yasal saklama istisnalarını, anonimleştirme yöntemini ve tamamlanma kanıtını tanımlamalıdır.
Çıkış planı tatbikatla doğrulanmalıdır
- Yılda en az bir örnek veri ihracı ve yeniden yükleme.
- Kritik API ve kimlik entegrasyonlarının envanter karşılaştırması.
- RTO/RPO ve kabul edilebilir kesinti hedefi testi.
- Hesap, anahtar ve destek erişimi kapanış simülasyonu.
- Sağlayıcı yanıt vermezse kullanılacak alternatif iletişim ve eskalasyon.
- Geçiş maliyeti, insan kaynağı ve takvim tahmininin güncellenmesi.
- Tatbikat bulgularının sözleşme yenileme ve tedarikçi puanına yansıtılması.
Kaynaklar ve gözden geçirme notu
Bu rehberde değişebilir veya teknik iddialar için öncelikle resmî kurum, ürün geliştiricisi ve birincil araştırma kaynakları kullanılmıştır. Bağlantılar 27 Temmuz 2026 tarihinde gözden geçirilmiştir.
- 01European Commission — Data Act
Veri işleme hizmetleri arasında geçişi kolaylaştıran Data Act çerçevesini ve 12 Eylül 2025 uygulama tarihini açıklar.
- 02EUR-Lex — Regulation (EU) 2023/2854, Data Act
Veri işleme hizmetleri arasında geçiş, birlikte çalışabilirlik ve sözleşmesel yükümlülüklerin resmî düzenleme metnidir.
- 03European Commission — Data Act explained
Bulut ve edge hizmetleri arasında geçiş yükümlülüklerini uygulama bağlamında açıklar.
- 04European Commission — Draft model contractual terms and cloud SCCs
Switching & Exit, Termination ve Security & Business Continuity için önerilen sözleşme maddelerini sunar.
- 05NIST — Contingency Planning Guide for Federal Information Systems
Bilgi sistemleri için süreklilik, kurtarma, test ve plan bakımını açıklayan temel resmî rehber.