Web Sitesi Hizmeti Sağlayıcısı Değiştirirken Kod, Erişim ve Barındırma Devri Nasıl Yönetilir?

Geçiş Öncesinde Hangi Dijital Varlıklar Belirlenmeli?

Sağlayıcı değişikliğinin ilk adımı, web sitesinin çalışması için gerekli bütün dijital varlıkları ve erişimleri tek bir envanterde toplamaktır. Sadece kaynak kodunu veya hosting hesabını almak yeterli olmayabilir; alan adı, veri tabanı, DNS, e-posta, CMS, analitik araçları, CDN, SSL, lisanslar ve harici servisler de aynı sistemin parçaları olabilir.

Teknik envanter neden geçiş planının temelidir?

Envanter hazırlanırken her varlığın nerede bulunduğu, hesabın kime ait olduğu, yönetici erişiminin kimde olduğu ve yeni sağlayıcıya hangi yöntemle aktarılabileceği kaydedilmelidir. Bu yaklaşım, web tasarım firması değişikliğinde değerlendirilmesi gereken kriterleri somut teknik varlıklara dönüştürür. Özellikle eski sağlayıcının kendi hesabı altında tuttuğu hizmetlerle doğrudan müşteri hesabında bulunan hizmetlerin ayrılması önemlidir.

• Alan adı kayıt ve DNS yönetim hesabı
• Hosting, sunucu, CDN ve SSL erişimleri
• Kaynak kodu, repository ve deployment dosyaları
• Veri tabanı ve güncel yedekler
• CMS yönetici ve teknik kullanıcı hesapları
• E-posta ve üçüncü taraf servis bağlantıları

“Planlar değersizdir, fakat planlama her şeydir.” - Dwight D. Eisenhower

Kaynak Kodu ve Kullanım Hakları Nasıl Kontrol Edilmeli?

Web sitesi kod devri değerlendirilirken kaynak dosyalarının teslim edilmesi ile kodun kullanım, değiştirme ve yeniden geliştirme hakları birbirinden ayrılmalıdır. Dosyalara erişebilmek tek başına bütün fikrî veya sözleşmesel hakların müşteriye geçtiği anlamına gelmez; geçerli sözleşmeler ve lisans koşulları ayrıca incelenmelidir.

Sözleşme ile teknik teslim aynı şey midir?

Hayır. Teknik teslim; repository, kaynak dosyaları, veritabanı yapısı, yapılandırma örnekleri ve gerekli dokümantasyonu kapsayabilir. Sözleşmesel haklar ise bu materyallerin hangi kapsamda kullanılabileceğini belirler. Bu nedenle web tasarım firmasıyla yapılan sözleşmede bulunması gereken hükümler ile fiilî teknik teslim birlikte değerlendirilmelidir. Üçüncü taraf tema, eklenti, font, API veya yazılım kütüphanelerinin lisansları da ayrıca kontrol edilmelidir.

• Kaynak kodunun teslim kapsamını doğrulayın
• Repository erişiminin devredilebilirliğini kontrol edin
• Kullanım ve değişiklik haklarını sözleşmede inceleyin
• Üçüncü taraf lisanslarını ayrı değerlendirin
• Özel geliştirmeler ile lisanslı bileşenleri ayırın
• Eksik teknik dokümantasyonu geçişten önce belirleyin

Alan Adı ve Barındırma Erişimleri Nasıl Yönetilmeli?

Alan adı ve barındırma erişimlerinin yönetim modeli, sağlayıcı değişikliğinin sürekliliğini doğrudan etkiler. Mümkün olan durumlarda işletmenin kritik dijital varlıklarının müşteri tarafından kontrol edilen hesaplarda tutulması, gelecekte yapılabilecek sağlayıcı değişikliklerinde bağımlılığı azaltır ve yetki yönetimini daha görünür hale getirir.

Hesap sahipliği ile teknik yönetim nasıl ayrılır?

Alan adı müşterinin hesabında bulunurken DNS veya sunucu yönetimi teknik sağlayıcıya yetkilendirilebilir. Benzer şekilde hosting hesabının mülkiyeti ile günlük sistem yönetimi aynı tarafta olmak zorunda değildir. bulut ve sunucu yönetiminin nasıl yapılandırıldığını anlamak, yeni sağlayıcının hangi erişim seviyesine ihtiyaç duyacağını belirlemeyi kolaylaştırır. Önemli olan hesap sahibi, faturalama sorumlusu ve teknik yöneticinin açık biçimde tanımlanmasıdır.

• Alan adı hesabının sahibini doğrulayın
• Registrar ve DNS erişimlerini ayrı kaydedin
• Hosting hesabının kimin adına olduğunu belirleyin
• Sunucu yönetici erişimlerini kontrol edin
• Faturalama ve yenileme sorumluluklarını belgeleyin
• Eski kullanıcıların kaldırılması için plan oluşturun

Yeni Sağlayıcı Geçişten Önce Neleri İncelemeli?

Yeni sağlayıcı, taşıma teklifi vermeden önce mevcut web sitesinin mimarisini ve bağımlılıklarını teknik olarak incelemelidir. Kullanılan yazılım dili, framework, CMS, sunucu sürümleri, veri tabanı, entegrasyonlar, zamanlanmış görevler, dosya depolama yöntemi ve güvenlik yapılandırmaları bilinmeden sağlıklı bir geçiş kapsamı oluşturmak güçleşir.

Teknik keşif hangi riskleri görünür hale getirir?

Teknik keşif yalnızca hataları aramak için yapılmaz. Yeni ekibin mevcut sistemi sürdürebilip sürdüremeyeceğini, hangi bileşenlerin taşınacağını ve hangi bileşenlerin yeniden yapılandırılması gerektiğini ortaya koyar. web tasarım firmasının teknik yeterliliğini değerlendirirken aday sağlayıcının mevcut sistemi anlamak için sorduğu sorular, kullandığı kontrol yöntemi ve riskleri nasıl sınıflandırdığı önemli göstergelerdir.

• Uygulama ve framework sürümlerini inceleyin
• Sunucu gereksinimlerini ve bağımlılıkları belirleyin
• Veri tabanı boyutunu ve yapısını kontrol edin
• API ve üçüncü taraf entegrasyonlarını listeleyin
• Güvenlik ve erişim modelini değerlendirin
• Yedeklerin gerçekten geri yüklenebilir olduğunu doğrulayın

Web Sitesi Taşıma Planı Nasıl Aşamalandırılmalı?

Sağlayıcı değişikliği site taşıma süreci, dosyaların bir sunucudan diğerine kopyalanmasından daha kapsamlı planlanmalıdır. Sağlıklı bir web sitesi teknik devir planı; erişim toplama, yedekleme, hedef ortam hazırlama, veri aktarımı, yapılandırma, doğrulama, DNS geçişi ve geçiş sonrası gözlem adımlarını birbirinden ayırır.

Canlı siteye geçiş ne zaman yapılmalı?

Yeni ortam mümkün olduğunca canlı trafik yönlendirilmeden önce test edilmelidir. Veri güncellemelerinin devam ettiği sistemlerde son senkronizasyon yöntemi ayrıca planlanmalıdır. DNS değişiklikleri, e-posta kayıtları, SSL sertifikaları, yönlendirmeler ve zamanlanmış görevler geçiş planının parçası olmalıdır. Böylece geçiş anında hangi ekibin hangi işlemi yapacağı önceden bilinir ve beklenmeyen durumda geri dönüş seçeneği korunabilir.

• Güncel ve doğrulanmış yedek oluşturun
• Yeni barındırma ortamını önceden hazırlayın
• Test ortamında uygulamayı çalıştırın
• Veri senkronizasyon yöntemini belirleyin
• DNS ve SSL geçiş adımlarını planlayın
• Geri dönüş senaryosunu yazılı hale getirin

Hosting Taşıma Teklifinde Hangi İşler Ayrılmalı?

Hosting taşıma teklifi yalnızca “site taşıma” şeklinde tek bir kalem olarak sunulmamalıdır. Mevcut sistemin teknik keşfi, erişimlerin toplanması, yedekleme, hedef ortam kurulumu, veri taşıma, test, DNS değişikliği ve geçiş sonrası destek farklı iş yükleri oluşturabilir. Teklif kapsamının bu ayrımı göstermesi karşılaştırmayı kolaylaştırır.

Teklifleri karşılaştırırken hangi kapsam aranmalı?

İki sağlayıcının aynı hizmet adını kullanması aynı işi sundukları anlamına gelmeyebilir. Bir teklif yalnızca dosya ve veri tabanı aktarımını kapsarken diğeri performans kontrolü, yönlendirme doğrulaması, entegrasyon testi ve belirli bir geçiş sonrası destek kapsamını içerebilir. web sitesi tekliflerini karşılaştırırken kullanılan kapsam kriterleri taşıma projelerinde de iş paketlerinin ve sorumlulukların netleştirilmesine yardımcı olur.

• Teknik keşif ve mevcut sistem analizi
• Erişim toplama ve hesap kontrolü
• Yedekleme ve geri yükleme doğrulaması
• Hosting ve uygulama taşıma işlemleri
• DNS, SSL ve yönlendirme düzenlemeleri
• Test ve geçiş sonrası teknik destek

Taşıma Sonrasında Hangi Testler Tamamlanmalı?

Web sitesi geçiş desteği, sitenin yeni sunucuda ana sayfasının açılmasıyla tamamlanmış sayılmamalıdır. Taşıma sonrasında sayfalar, formlar, kullanıcı oturumları, yönetim paneli, e-posta gönderimleri, API bağlantıları, yönlendirmeler, dosya yüklemeleri ve zamanlanmış görevler gibi kritik fonksiyonlar kontrollü biçimde test edilmelidir.

Kabul kontrolü neden teklifin parçası olmalıdır?

Test kapsamı önceden tanımlandığında hem müşteri hem de yeni sağlayıcı teslimin hangi koşullarda tamamlandığını bilir. Özellikle dinamik sitelerde yalnızca görsel kontrol yeterli değildir. CMS yönetici erişimi, veri yazma işlemleri, form bildirimleri, entegrasyonlar ve güvenlik ayarları işlevsel olarak doğrulanmalıdır. Sorunların hangilerinin taşıma kaynaklı, hangilerinin önceden var olan teknik borç olduğu da mümkün olduğunca ayrıştırılmalıdır.

• Kritik sayfaları ve kullanıcı akışlarını test edin
• Form ve e-posta gönderimlerini doğrulayın
• CMS yönetici işlemlerini kontrol edin
• API ve üçüncü taraf servisleri sınayın
• Yönlendirme ve SSL yapılandırmasını inceleyin
• Yedekleme ve zamanlanmış görevleri doğrulayın

Sağlayıcı Değişikliğinde Sorumluluklar Nasıl Netleştirilir?

Başarılı bir web sitesi hizmeti sağlayıcısı değiştirme sürecinde teknik görevler kadar sorumluluk sınırları da açık olmalıdır. Eski sağlayıcının hangi verileri teslim edeceği, müşterinin hangi hesapları sağlayacağı, yeni sağlayıcının hangi kontrolleri yapacağı ve geçiş sonrasında hangi desteği sunacağı yazılı bir sorumluluk listesinde tanımlanmalıdır.

Yeni sağlayıcıdan hangi devir planı istenmeli?

Aday sağlayıcıdan erişim envanteri, teknik inceleme kapsamı, taşıma sırası, test kriterleri, geçiş sorumluları ve geçiş sonrası destek yaklaşımını içeren uygulanabilir bir plan istenebilir. İyi tanımlanmış devir kapsamı, sağlayıcının yalnızca yeni site geliştirme becerisini değil, mevcut bir sistemi kontrollü biçimde devralma yaklaşımını da görmenizi sağlar. Teklif değerlendirmesinde belirsiz “taşıma dahil” ifadeleri yerine hangi işin kim tarafından ve hangi kabul kriteriyle tamamlanacağı sorgulanmalıdır.

• Eski sağlayıcının teslim sorumluluklarını belirleyin
• Müşteri tarafından sağlanacak erişimleri listeleyin
• Yeni sağlayıcının teknik görevlerini tanımlayın
• Test ve kabul kriterlerini yazılı hale getirin
• Geçiş sonrası destek kapsamını netleştirin
• Yetki kaldırma ve kapanış adımlarını planlayın