Aydınlatma metni yükleniyor…
Kısa cevap: Teknik devir, önce mevcut sistemi ve sahiplikleri görünür hâle getirip tam yedeği almakla başlar. Yeni sağlayıcı gerekli erişimleri aldıktan sonra canlı sürümü, veri tabanını, DNS ve e-posta yapılarını, formları ve entegrasyonları kontrol eder. Eski sağlayıcının yetkileri ise yeni erişimler doğrulanıp sistemin temel işlevleri çalıştıktan sonra kaldırılır. Nihai geçiş müşteri onayıyla kesinleştirilir.
Bu sıra önemlidir. Eski erişimleri çok erken kapatmak geri dönüşü zorlaştırabilir; kontrol etmeden taşıma yapmak ise eksik veri tabanı, güncel olmayan kod veya çalışmayan entegrasyonlarla yeni bakım dönemine başlanmasına neden olabilir. Amaç “bir günde her şeyi değiştirmek” değil, kontrolü kaybetmeden sorumluluğu devretmektir.
Teknik Devir Neden Dosya Tesliminden İbaret Değildir?
Bir web sitesi yalnızca sunucudaki dosyalardan oluşmaz. Alan adı kayıt hesabı, DNS kayıtları, hosting veya sunucu, veri tabanı, medya dosyaları, e-posta hizmeti, SSL yapılandırması, yönetim paneli, kaynak kod deposu, analiz hesapları ve üçüncü taraf servisler birbirine bağlı çalışabilir.
Bu nedenle “dosyaları gönderdik” cümlesi teknik devrin tamamlandığını göstermez. Şu soruların ayrı ayrı cevaplanması gerekir:
- Canlıda çalışan kodun güncel kopyası hangisi?
- Veri tabanı yedeği aynı zaman noktasına mı ait?
- Alan adı ve DNS üzerinde yönetici yetkisi kimde?
- E-posta akışını etkileyen DNS kayıtları korunuyor mu?
- Formlar ve entegrasyonlar hangi servis hesaplarını kullanıyor?
- Analiz ve arama görünürlüğü hesaplarının gerçek sahibi kim?
- Sorun çıkarsa hangi yedeğe ve hangi sürüme dönülecek?
Bu sorular cevaplanmadığında yeni sağlayıcı sisteme erişebilir fakat sistemi güvenli ve sürdürülebilir biçimde yönetebilecek bütünlüğe sahip olmayabilir.
Devir Başlamadan Sorumluları ve Değişiklik Dondurma Aralığını Belirleyin
Teknik geçişten önce müşteri tarafında bir karar sorumlusu, eski sağlayıcı tarafında erişimleri ve dosyaları teslim edecek kişi, yeni sağlayıcı tarafında ise teknik kontrolü yönetecek ekip belirlenmelidir. Hangi talebin kime yöneltileceği ve nihai kabulü kimin vereceği yazılı olmalıdır.
Kumsal Ajans, mümkün olduğunda kısa süreli paralel çalışma tercih eder. Bu dönemde eski sistem erişilebilir kalırken yeni ekip varlıkları ve bağlantıları inceler. Kritik olmayan içerik ve kod değişiklikleri geçici olarak durdurulabilir. Böylece yedek alındıktan sonra sistemin fark edilmeden değişmesi ve “hangi sürüm devredildi?” sorusunun belirsiz kalması önlenmeye çalışılır.
Değişiklik dondurma her projede aynı süreyi veya tam duruşu gerektirmez. Yoğun içerik üreten, sipariş alan veya sürekli veri işleyen sistemlerde yeni kayıtların nasıl korunacağı ayrıca planlanmalıdır. Ama en azından başlangıç yedeğinin zamanı, canlı sürüm ve geçiş sırasında izin verilen değişiklikler kayıt altına alınmalıdır.
12 Alanlı Web Sitesi Teknik Devir Kaydı
Aşağıdaki kayıt, “teslim edildi” gibi genel ifadeleri doğrulanabilir alanlara ayırır. Her satır için mevcut sahip, yeni yetkili, teslim edilen erişim veya dosya, kontrol sonucu ve eksik işlem yazılmalıdır.
| Alan | Devirde doğrulanacak temel konu |
|---|---|
| 1. Alan adı | Kayıt hesabı, müşteri sahipliği, yönetici erişimi, yenileme ve iletişim bilgileri |
| 2. DNS | Yetkili DNS hizmeti, mevcut kayıtların dışa aktarımı, web ve e-posta kayıtları |
| 3. Hosting/sunucu | Yönetim paneli, FTP/SSH, sunucu kaynakları, çalışma zamanı ve erişim yöntemi |
| 4. Kaynak kod | Güncel depo veya paket, canlı sürümle eşleşme, kurulum ve yayın bilgisi |
| 5. Veri tabanı | Erişim, güncel yedek, karakter seti, bağlantı bilgisi ve veri bütünlüğü kontrolü |
| 6. E-posta | Hesapların sahibi, DNS bağımlılıkları, form bildirimleri ve gönderim hizmeti |
| 7. SSL | Sertifikanın yönetildiği yer, yenileme yöntemi ve alan adı kapsamı |
| 8. Yedekler ve medya | Site dosyaları, veri tabanı, yüklenen medya, tarih ve saklama yeri |
| 9. Lisanslar | Tema, kütüphane, servis veya ticari bileşen lisanslarının sahibi ve yenileme koşulu |
| 10. API ve gizli erişimler | Kullanılan anahtarlar, sorumlu hesap, aktarım ve gerektiğinde yenileme planı |
| 11. Yönetim ve analiz hesapları | Yönetim paneli, GA4, Search Console ve ilgili kullanıcı rolleri |
| 12. Entegrasyonlar | Ödeme, CRM, ERP, kargo, e-posta, webhook ve diğer dış servis bağlantıları |
Bu tablo her projede aynı ayrıntı düzeyinde doldurulmak zorunda değildir. Örneğin e-ticaret projesinde ödeme ve sipariş entegrasyonları kritik olabilirken, sade bir kurumsal sitede form ve e-posta akışı daha önemli olabilir. Gereksiz alanları doldurmak yerine “uygulanamaz” olarak işaretlemek ve nedenini yazmak daha doğrudur.
İlk proje teslimindeki daha geniş kabul kontrolleri için kurumsal web sitesi teslim kontrol listesinden yararlanabilirsiniz. K-018’deki fark, ilk teslimi değil mevcut sağlayıcıdan yeni sağlayıcıya geçişi yönetmesidir.
Alan Adı, DNS ve Analiz Hesaplarında Sahipliği Nasıl Doğrularız?
Alan adı yalnızca sitenin adresi değildir; DNS yönetimi üzerinden web sitesi ve e-posta trafiğini etkileyebilir. Bu nedenle yalnızca DNS paneline giriş yapılabildiğini görmek yeterli değildir. Kayıt hesabının kimin adına olduğu, yenileme ve iletişim bilgilerinin kimde bulunduğu, çok faktörlü doğrulamaya kimin eriştiği ve mevcut DNS kayıtlarının yedeğinin alınıp alınmadığı kontrol edilmelidir.
ICANN’ın alan adı kayıt hesaplarını koruma rehberi, kayıt hesabı kimlik bilgilerinin yetkisiz erişime karşı korunmasını ele alır. Teknik devirde bu konu, alan adını başka yere taşımak zorunluluğu anlamına gelmez. Öncelik, müşteri sahipliğini ve yetkili erişimi doğrulamak; yapılacak değişiklikleri kayıt altına almaktır.
GA4 ve Search Console gibi hesaplarda da “raporu görebilmek” ile gerçek yönetici veya sahip yetkisi aynı şey değildir. Google Analytics kullanıcı yönetimi dokümanı, kullanıcıların hesap veya mülk düzeyinde farklı rollerle eklenebildiğini ve erişimlerinin daha sonra düzenlenebildiğini açıklar.
Search Console sahiplik ve kullanıcı rehberi ise sahip, tam kullanıcı ve kısıtlı kullanıcı rollerini ayırır. Eski bir doğrulanmış sahibin yalnızca kullanıcı listesinden kaldırılması her zaman yeterli olmayabilir; Google, erişimin yeniden kazanılmasını sağlayabilecek doğrulama belirteçlerinin de kontrol edilmesini önerir. Bu nedenle devir kaydında yalnızca e-posta adresi değil rol, doğrulama yöntemi ve kaldırma sonucu da bulunmalıdır.
Erişimleri Devralmadan Eski Yetkiler Neden Kapatılmamalı?
Eski sağlayıcının erişimlerini ilişkinin bittiği anda kapatmak ilk bakışta güvenli görünebilir. Fakat yeni ekibin hosting, DNS, kaynak kod, veri tabanı veya servis hesaplarından birine henüz erişemediği sonradan anlaşılırsa geçiş kilitlenebilir.
Kumsal Ajans yaklaşımında sıra şöyledir:
- Teslim edilecek hesap ve varlık envanteri hazırlanır.
- Yeni yetkiler oluşturulur veya müşteri adına mevcut yetkiler doğrulanır.
- Tam yedek ve canlı sürüm kaydı alınır.
- Yeni ekip temel teknik kontrolleri gerçekleştirir.
- Eksik veya çalışmayan erişimler tamamlanır.
- Müşteri geçiş sonucunu onaylar.
- Artık gerekmeyen eski kullanıcılar ve gizli erişimler kaldırılır veya gerektiğinde yenilenir.
OWASP Secrets Management rehberi, artık gerekli olmayan gizli erişimlerin iptal edilmesini ve ihtiyaç ya da risk durumunda yenilenmesini yaşam döngüsünün parçası olarak ele alır. Bunun uygulaması her projede aynı değildir. Paylaşılan bir FTP parolasının değiştirilmesi, kişisel bir yönetici kullanıcısının kaldırılması ve üçüncü taraf API anahtarının yenilenmesi farklı işlemlerdir.
Parolaları makale, e-posta zinciri veya herkesin erişebildiği proje notu içinde toplamak doğru değildir. Hangi gizli bilginin kime, hangi güvenli kanaldan aktarıldığı ve aktarım sonrasında hangi eski erişimin kapatıldığı kayıt altına alınmalıdır; gizli değerin kendisi genel devir tablosuna yazılmamalıdır.
Yedek ve Canlı Sürüm Nasıl Sabitlenir?
Devir başlamadan önce site dosyaları, veri tabanı, yüklenen medya dosyaları ve mevcut canlı sürümün tam yedeği alınır. Kaynak kod deposu varsa canlıdaki sürümle eşleşip eşleşmediği kontrol edilir. Yalnızca “yedek var” demek yerine tarih, kapsam, dosya adı veya sürüm kimliği, saklama yeri ve geri dönüş sorumlusu kaydedilir.
Özellikle veri üreten sistemlerde dosya ve veri tabanı yedeklerinin farklı zamanlarda alınması tutarsızlık oluşturabilir. Sipariş, üyelik, form kaydı veya içerik girişi devam ediyorsa geçiş anındaki yeni verilerin nasıl ele alınacağı ayrıca planlanmalıdır. Kısa süreli değişiklik dondurma veya son eşitleme adımı bu nedenle kullanılır.
Yedek alınması, geri yüklemenin kesin olarak çalışacağı anlamına gelmez. Projenin riskine göre yedeğin açılabilirliği, veri tabanı bağlantısı ve temel işlevler ayrı ortamda kontrol edilebilir. Yedek ile geri yüklemenin doğrulanması ayrı kontroller olarak kaydedilmelidir.
Kaynak Kod, Veri Tabanı veya Kritik Erişim Eksikse Ne Yapılmalı?
Kritik bir varlık eksikse amaç her ne pahasına olursa olsun geçişi sürdürmek olmamalıdır. Eksikliğin etkisi kaydedilir ve tamamlanmadan hangi işlemlerin yapılamayacağı açıklanır.
Kumsal Ajans, kaynak kod, veri tabanı veya kritik erişimler eksikse canlı taşıma, geliştirme veya kapsamlı müdahaleye başlamaz. Önce eksiklerin tamamlanmasını ister. Bunun nedeni önceki sağlayıcı hakkında hüküm vermek değil, yeni ekibin hangi sistem üzerinde çalıştığını ve geri dönüş imkânını bilmeden riskli değişiklik yapmasını önlemektir.
Örneğin yönetim paneline erişmek, sunucu veya veri tabanı erişiminin de bulunduğu anlamına gelmez. Benzer şekilde kaynak kod arşivi mevcut olabilir fakat canlıdaki son değişiklikleri içermeyebilir. Her varlık “var/yok” yerine “alındı, açıldı, sürümü doğrulandı, canlıyla eşleşti” gibi sonuçlarla kontrol edilmelidir.
Geçiş Sonrasında Hangi Kontroller Yapılmalı?
Teknik devir, erişim bilgilerinin teslim edildiği gün değil, sistemin temel işlevleri yeni sorumluluk yapısı altında doğrulandığında tamamlanır. Kumsal Ajans proje kapsamına göre şu kontrolleri uygular:
- Türkçe ve varsa diğer dil sürümlerinde site erişimi
- Kritik sayfalar ve yönlendirmeler
- Formların gönderimi ve e-posta bildirimleri
- SSL sertifikası ve HTTPS erişimi
- DNS kayıtları ile web ve e-posta yönleri
- Veri tabanı bağlantısı ve temel veri görüntüleme/işleme akışları
- Yönetim paneli girişi ve gerekli kullanıcı rolleri
- Ödeme, CRM, ERP, webhook veya diğer projeye özel entegrasyonlar
- Mobil görünüm ve temel kullanıcı işlemleri
- Hata kayıtları ve gerekiyorsa geçiş sonrası yakın izleme
Kontrol listesi projenin işlevlerine göre uyarlanmalıdır. Sade kurumsal sitede gereksiz bir ödeme testi aranmaz; ödeme alan bir sistemde ise yalnızca ana sayfanın açılması yeterli kabul edilmez.
Teknik ekip sonuçları kaydettikten sonra nihai geçiş müşteri onayıyla kesinleştirilir. Bu onay; bütün gelecekteki sorunların bittiği veya yeni sağlayıcının önceki sistemdeki bütün bilinmeyenleri üstlendiği anlamına gelmez. Tespit edilen eksikler, kabul edilen riskler ve sonraki işler ayrıca yazılmalıdır.
Anonim Gerçek Bir Devir Örneği
Kumsal Ajansın devraldığı bir projede teslim edilen veri tabanının eksik, dosya yedeğinin ise canlı sistemin güncel sürümünü içermediği tespit edildi. Bu durumda geçişe devam edilmedi. Eksiklerin etkisi kaydedildi ve doğru veri tabanı ile güncel dosya yedeği talep edildi.
Doğru yedekler temin edildikten sonra erişimler ve temel sistem kontrolleri yeniden yapıldı; ardından geçiş tamamlandı. Bu örnekten çıkarılacak ders, her eksikliğin büyük bir arızaya dönüşeceği değildir. Asıl ders, teslim paketini açıp doğrulamadan taşıma veya geliştirme başlatmamanın önemidir.
Müşteri, sektör, eski sağlayıcı, tarih, süre, kullanılan altyapı ve sürüm gibi kimliği ortaya çıkarabilecek ayrıntılar paylaşılmamaktadır. Örnek; kesintisiz geçiş, belirli sürede tamamlama veya ölçülmüş performans sonucu iddiası içermez.
Müşteri, Eski Sağlayıcı ve Yeni Sağlayıcı Sorumlulukları Nasıl Ayrılır?
Müşteri, hesapların gerçek sahibi veya yetkili temsilcisi olarak geçiş kararını, ilgili kişileri ve nihai kabulü yönetir. Alan adı, hosting, e-posta ve üçüncü taraf servislerin mümkün olduğunca müşteri adına olması devir sırasında bağımlılığı azaltır; ancak gerçek sahiplik ve kullanım koşulları ilgili sözleşme ve hesaplardan doğrulanmalıdır.
Eski sağlayıcıdan, sözleşme ve teslim kapsamına göre güncel dosyalar, veri tabanı, erişimler, teknik notlar ve bilinen sınırlamalar istenir. Yeni sağlayıcı ise alınan varlıkları doğrular, eksikleri görünür hâle getirir, geçiş sırasını planlar ve üzerinde anlaşılan kontrolleri uygular.
Bu görev dağılımı, her teknik veya sözleşmesel sorunun otomatik olarak yeni sağlayıcının sorumluluğuna geçtiği anlamına gelmez. Bilinmeyen eski kod, süresi dolmuş lisans, üçüncü taraf servis kısıtı veya eksik dokümantasyon yeni kapsam ve risk olarak değerlendirilmelidir.
En Sık Yapılan Teknik Devir Hataları
- Yalnızca FTP erişimini alıp veri tabanı ve servis hesaplarını kontrol etmemek
- Alan adının müşteri hesabında olduğunu varsaymak
- DNS kayıtlarını dışa aktarmadan nameserver veya hosting değiştirmek
- E-posta kayıtlarını web sitesi kayıtlarıyla birlikte yanlışlıkla değiştirmek
- Kaynak kod arşivini canlı sürümle eşleştirmemek
- Tam yedek alınmadan kritik değişiklik başlatmak
- Yeni erişimler doğrulanmadan eski kullanıcıları kapatmak
- Paylaşılan parolaları ve API anahtarlarını herkesin erişebileceği notlarda tutmak
- Form, e-posta ve entegrasyonları yalnızca sayfaların açılmasına bakarak çalışıyor saymak
- Eksik teslimleri ve kabul edilen riskleri yazılı hâle getirmemek
Bu hataların tamamı her projede aynı sonucu doğurmaz. Kontrol listesinin amacı korku üretmek değil, hangi varlığın kimde olduğunu ve geçişin hangi adımda bulunduğunu görünür hâle getirmektir.
Sonuç: Önce Kontrolü Doğrulayın, Sonra Yetkiyi Devredin
Web sitesi bakım sağlayıcısını değiştirirken sağlıklı sıra; envanter, sahiplik kontrolü, tam yedek, yeni erişimlerin doğrulanması, teknik testler, müşteri kabulü ve eski yetkilerin kaldırılmasıdır. Bu sıra projeye göre uyarlanabilir; ancak kritik kod, veri veya erişim eksikken taşıma ve kapsamlı geliştirme başlatmak yerine eksikleri tamamlamak daha kontrollü bir yaklaşımdır.
12 Alanlı Web Sitesi Teknik Devir Kaydı, alan adı ve DNS’ten kaynak kod ve veri tabanına, e-posta ve SSL’den API ve analiz hesaplarına kadar bütün geçişi tek yerde takip etmeye yardımcı olur. Kayıt, kesintisiz geçiş garantisi vermez; kararların, eksiklerin ve sorumluların görünür olmasını sağlar.
Mevcut web sitenizi Kumsal Ajans’a devretmeyi planlıyorsanız, erişim paylaşmadan önce varlık envanterini ve eksik teslimleri birlikte değerlendirmek için teknik devir görüşmesi planlayabilirsiniz.