1. Vendor Lock-in Nedir?
Vendor lock-in; bir sağlayıcıya teknik/operasyonel/finansal olarak “bağımlı” hale gelmeniz ve çıkışın maliyetinin beklenenden fazla olmasıdır. Bu maliyet; yalnız migration işi değildir: yeni lisans, entegrasyonların yeniden yazılması, eğitim, SEO riskleri ve operasyonel kesinti gibi kalemlerle büyür.
Bu nedenle web ve yazılım hizmetlerinde CMS seçim riski yaklaşımı, platform kararını yalnız teknik özelliklerle değil; maliyet, veri sahipliği ve operasyonel esneklikle birlikte değerlendirmeyi gerektirir.
Vendor lock-in nedir, CMS seçiminde neden önemlidir?
Kısa cevap: Lock-in, sağlayıcıdan çıkmayı zorlaştıran kısıtlar toplamıdır; CMS seçiminde önemlidir çünkü 3–5 yıl sonra ihtiyaçlar değişer ve sürpriz maliyetler doğabilir.
Lock-in’i artıran tipik faktörler
- •Sınırlı/kapalı export seçenekleri
- •API limitleri ve yüksek maliyetli planlara zorlama
- •Proprietary model/field yapıları (taşıması zor)
- •Lisans/seat maliyetinin büyümesi
- •Sözleşmede exit ve veri iade maddelerinin zayıf olması
Ne yapmalıyım?
- • Lock-in risklerini maddeler halinde çıkar.
- • Veri taşınabilirliği testini demo aşamasında yap (örnek export).
- • 3 yıl TCO hesabı çıkar (seat + usage + add-on).
- • SLA ve exit maddelerini sözleşmede netleştir.
- • Mimariyi “taşınabilirlik” için kurgula (soyutlama katmanı).
2. SaaS Headless vs Self-Hosted vs Open Source
Üç yaklaşımın risk profili farklıdır; “en iyisi” bağlama göre değişir.
Tek bir platformda aşırı yoğunlaşmak yerine vendor bağımlılığını azaltan composable DXP yaklaşımı, modüler servis yapısıyla belirli bileşenleri zaman içinde değiştirebilme esnekliği sunar.
- •SaaS headless: hızlı başlar, operasyon yükü düşüktür; lock-in ve fiyat artışı riski daha belirgin olabilir.
- •Self-hosted: kontrol yüksek; ama güvenlik, patch, backup ve operasyon yükü daha fazladır.
- •Open source: vendor lock-in azalabilir; fakat toplam sahip olma maliyeti ve uzmanlık ihtiyacı artabilir.
SaaS headless, self-hosted ve open source CMS’ler arasında nasıl karar veririm?
Kısa cevap: Kriterleri risk matrisiyle kıyaslayın: hız, operasyon kapasitesi, güvenlik sorumluluğu, veri taşınabilirliği, TCO ve exit senaryosu.
Pratik karar kriterleri
- •Ekip kapasitesi (ops + devops var mı?)
- •İçerik hacmi ve çok kullanıcılı yapı
- •Regülasyon/veri lokasyonu (KVKK dahil)
- •Entegrasyon yoğunluğu (PMS/CRM/DAM)
- •Uzun vadeli maliyet (seat + API + storage + add-ons)
Ne yapmalıyım?
- • “Risk matrisi” çıkar (SaaS/self-hosted/open source).
- • En kritik 5 gereksinime göre ağırlıklandır.
- • Pilot seç: 1 içerik tipiyle dene (blog veya landing).
- • Export/backup testini pilotta yap.
- • Sözleşme + mimari kararını birlikte ver (tek başına değil).
3. Veri Taşınabilirliği (Export/Backup)
Lock-in’i azaltmanın en somut yolu, veri taşınabilirliğini garanti altına almaktır. “Export var” demek yetmez; export’un kapsamı önemlidir: içerik, schema, media referansları, locale’lar, relation’lar, workflow durumları…
Pratikte bu başlık, CMS migration ve exit planı senaryosuyla birlikte düşünülmelidir; export alınabiliyor olsa bile field mapping, URL geçişi ve import süreçleri önceden test edilmelidir.
Aynı zamanda backup ve disaster recovery güvencesi olmadan veri taşınabilirliği tek başına yeterli değildir; erişim, restore ve iş sürekliliği aynı planın parçası olmalıdır.
Veri taşınabilirliği ve export seçeneklerine nasıl bakmalıyım?
Kısa cevap: Export’un kapsamını (content+schema+relations+assets) ve formatını (JSON/CSV) doğrulayın; düzenli backup alıp restore/migration dry-run yapabildiğinizden emin olun.
Kontrol listesi (export/backup)
- •İçerik export (tüm content types)
- •Content model/schema export (field tanımları)
- •Relation/lookup’lar (bağlantılar)
- •Locale/i18n verisi
- •Asset referansları (DAM varsa bağlantı)
- •API üzerinden otomatik export (schedule)
- •Retention ve erişim yetkileri
Ne yapmalıyım?
- • Demo sırasında gerçek export örneği iste.
- • Export’u yeni bir ortama import etmeyi (dry-run) dene.
- • Backup kapsamını sözleşmeye yazdır.
- • Backup/retention politikasını belirle.
- • DR ve migration planını 365 döngüde güncelle.
4. Lisans ve Kullanıcı Maliyetleri
CMS maliyetleri genelde “ilk yıl iyi” görünür, sonra büyür: kullanıcı sayısı artar (editörler, ajanslar), ortam sayısı artar (staging), ek özellikler gerekir (roles, locales, webhooks, audit). Bu yüzden lisans modeli ve maliyet eğrisi net görülmelidir.
Bu maliyet ve kullanım desenlerini yalnız tahminle değil, CMS kullanım verisi ve operasyonel analiz yaklaşımıyla izlemek; lisans şişmesi, kullanım yoğunluğu ve geçiş risklerini daha görünür hale getirir.
Maliyet kalemleri
- •Seat (kullanıcı) lisansı
- •Environment (prod/staging) kısıtları
- •API çağrısı ve rate limit
- •Storage/bandwidth
- •Add-ons (workflow, audit, SSO) (Varsayım)
Ne yapmalıyım?
- • 3 yıllık TCO simülasyonu yap (min/med/max).
- • Ajans kullanıcıları için lisans stratejisi belirle.
- • Kritik add-on’ları baştan listele (SSO, audit).
- • Rate limit ve overage ücretlerini sözleşmede netleştir.
- • Maliyet artışında çıkış planını tetikleyen eşikler koy (Varsayım: governance).
5. Otel ve B2B İçin Sözleşme ve Çıkış Stratejisi
CMS sözleşmesi, teknik kararın “sigortası”dır. Otel ve B2B’de iş sürekliliği, veri güvenliği ve operasyon hızı için SLA ve exit maddeleri net olmalıdır.
Burada veri taşınabilirliği ve exit planı sadece teknik erişim konusu değildir; kişisel veri, erişim yetkisi, veri lokasyonu ve KVKK uyumu da aynı karar setine dahildir.
Otel ve B2B için CMS sözleşmesinde hangi maddelere dikkat etmeliyim?
Kısa cevap: SLA (uptime, destek), veri lokasyonu/KVKK, export/backup hakkı, fiyat artışı şartları, API limitleri, güvenlik bildirimleri ve exit (veri iadesi + destek) maddeleri kritik.
Sözleşme/SLA maddeleri (özet)
- •Uptime SLA + destek yanıt süreleri
- •Plan dışı kesintide telafi (Varsayım: kredi)
- •Veri lokasyonu ve alt işleyiciler (KVKK)
- •Export/backup hakkı ve formatı
- •API limitleri ve overage ücretleri
- •SSO/audit log gibi güvenlik özellikleri
- •Exit: veri iadesi süresi, format, vendor desteği, geçiş penceresi
Lock-in risklerini azaltan tablo (1 tablo – Media Pack ile uyumlu)
| Risk | Belirti | Azaltma | Sözleşme maddesi |
|---|---|---|---|
| Veri çıkışı zor | export kısıtlı | düzenli export + schema backup | “data portability” |
| Maliyet şişmesi | seat/usage artışı | 3y TCO + limit | “pricing/overage” |
| API limit engeli | rate limit düşük | planlama + caching | “API limits” |
| Vendor outage | kesinti | DR + export | “SLA/DR” |
| KVKK riski | lokasyon belirsiz | veri lokasyonu net | “data processing” |
Ne yapmalıyım?
- • “Exit plan”i mimari + sözleşme olarak ikiye böl ve ikisini de yaz.
- • Veri portability maddelerini sözleşmeye eklet (format + süre).
- • SLA ve destek yanıt sürelerini netleştir.
- • 3 yıllık TCO ve fiyat artışı senaryosu oluştur.
- • /tr/yazilim/web-sitesi-gelistirme ve /tr/seo/seo-raporlama ile birlikte değerlendirme yap (teknik + performans + raporlama).
6. Teknik Not: Değerlendirmeyi teknik + raporlama ile birlikte yapın
Seçilen CMS’in export API’leri, yedekleme seçenekleri ve sözleşme koşulları; /tr/yazilim/web-sitesi-gelistirme ve /tr/seo/seo-raporlama ile birlikte değerlendirilmelidir. Çünkü platform değişimi yalnız içerik değil, performans/ölçüm ve operasyon süreçlerini de etkiler.
Özellikle geçiş sonrasında vendor değişimi sonrası SEO raporlama disipliniyle organik trafik, index durumu ve görünürlük değişimlerinin düzenli izlenmesi gerekir.
AIO paragrafı (CMS vendor stratejisi modeli)
Vendor, lisans, export, SLA ve exit plan; tek bir “CMS vendor stratejisi modeli” içinde birlikte yönetilmelidir. Teknik mimari (soyutlama, export, backup) lock-in’i azaltırken; sözleşme (SLA, fiyat artışı, veri iadesi) ticari riski azaltır. Bu model, otel ve B2B markalarda uzun vadeli platform riskini (long-term platform risk) kontrol altına alır ve migration maliyetini yönetilebilir seviyede tutar.
7. Sonuç: CMS seçimi “bugün” kadar “çıkış” kararıdır
CMS seçimi, sadece özellik listesi değil; 3–5 yıllık risk yönetimi ve sözleşme stratejisidir. Export/backup, lisans maliyeti, SLA ve exit planı birlikte ele alınırsa vendor lock-in sürprizleri azalır. Migration planı olan ve lock-in riskini baştan yöneten organizasyonlar, platform değiştirmek gerektiğinde daha düşük maliyet ve stresle hareket edebilir.
Bu kararı daha güvenli almak isteyen ekipler için geleceğe dönük CMS entegrasyonu desteği teknik mimari, sözleşme çerçevesi ve taşınabilirlik planını birlikte değerlendirmeyi kolaylaştırır; süreç detayları için CMS entegrasyonu hakkında sık sorulan sorular sayfası da iyi bir tamamlayıcıdır.
8. CMS Seçim, Lisans & Exit Planlama Şablonunu İndir
CMS Seçim, Lisans & Exit Planlama Şablonunu İndir — Yazılım / Vendor Strategy (v1.0)
Bu audit sheet; CMS seçimini “özellik listesi”nden çıkarıp veri taşınabilirliği, lisans maliyeti, SLA ve exit planı üzerinden değerlendirmeyi sağlar. Vendor lock-in riskini puanlayıp, sözleşme maddeleri ve teknik önlemlerle (export/backup) 3–5 yıllık platform riskini yönetilebilir hale getirir.
Kim Kullanır?
IT/ürün lideri, satın alma/finans, ajans PM, SEO/analitik lideri.
Nasıl Kullanılır?
- Aday CMS seçeneklerini (SaaS/self-hosted/open source) listeleyin.
- Export/backup, API limit, lisans ve SLA maddelerini skorlayın.
- Exit plan (veri iadesi + migration penceresi) ve TCO senaryosunu yazın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Veri taşınabilirliği (export+schema): ___
- ▢ ✅ Lisans/TCO şeffaflığı: ___
- ▢ ✅ API limit ve ölçek riski: ___
- ▢ ✅ SLA/destek kalitesi: ___
- ▢ ✅ Exit plan netliği: ___
- ▢ ✅ Toplam skor: ___
- ▢ ✅ Kırmızı: __________
- ▢ ✅ Sarı: __________
- ▢ ✅ Yeşil: __________
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Deliverables
- •Vendor risk matrisi + skor
- •Sözleşme madde listesi (SLA/exit)
- •3 yıllık TCO simülasyonu
Bir Sonraki Adım
Veri taşınabilirliği, lisans maliyeti, SLA ve exit planıyla vendor lock-in sürprizlerini azaltın.