Web Geliştirme Firması Değiştirirken Kaynak Kod, Sunucu ve Analitik Hesapları Nasıl Devralınır?

Web Geliştirme Firması Değiştirirken İlk Kontrol Ne Olmalı?

Web geliştirme firması değiştirirken ilk kontrol, sitenin çalışması için gereken tüm dijital varlıkların ve hesapların kim tarafından yönetildiğini ortaya çıkarmaktır. Devir teslim envanteri kaynak kod, veritabanı, sunucu, domain, DNS, CDN, analitik ve üçüncü taraf servisleri tek listede toplamalıdır. Böylece yeni teknik ekibin hangi varlıklara erişeceği, hangi erişimlerin kurum adına devredileceği ve hangi servislerde eski sağlayıcıya bağımlılık bulunduğu geçiş başlamadan görünür hale gelir.

Önce sistem haritasını çıkarın, sonra erişimleri taşıyın

Mevcut ajansla ilişkinin sona ereceği tarih belirlenmeden önce teknik sistem haritası hazırlanmalıdır. Bu harita, web tasarım firması değiştirirken değerlendirilmesi gereken noktalar ile birlikte ele alındığında yalnızca yeni sağlayıcı seçimini değil, mevcut altyapının kayıpsız aktarımını da planlamayı kolaylaştırır. Yeni ekip ilk günden tüm şifreleri istemek yerine hangi hesapların kuruma ait olduğunu, hangi rollerin tanımlanacağını ve hangi servislerin yeniden yapılandırılması gerektiğini belirlemelidir.

• Kaynak kod deposu ve sürüm geçmişini envantere ekleyin.
• Sunucu, bulut, CDN, domain ve DNS hesaplarını listeleyin.
• Veritabanı, dosya depolama ve yedek konumlarını belirleyin.
• Analytics, Search Console ve Tag Manager erişimlerini doğrulayın.
• E-posta ve üçüncü taraf API servislerini kayıt altına alın.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. - Martin Fowler

Kaynak Kod ve Git Deposu Yeni Ekibe Nasıl Devredilmeli?

Kaynak kod devri, yalnızca güncel proje klasörünün paylaşılmasıyla tamamlanmamalıdır; yeni ekip mümkünse Git deposuna, sürüm geçmişine, branch yapısına ve dağıtım için kullanılan ilgili yapılandırmalara kontrollü erişim almalıdır. Sürüm geçmişinin korunması, hangi değişikliğin ne zaman yapıldığını anlamayı, hata durumunda geri izleme yapmayı ve mevcut geliştirme sürecini kesintisiz sürdürmeyi kolaylaştırır. Kurumun depo sahipliği veya yönetici erişimi bulunmuyorsa bu durum devir teslim öncesinde netleştirilmelidir.

Kodun çalıştırılabilir ve teslim edilebilir durumda olduğunu doğrulayın

Yeni firma depoyu aldıktan sonra projeyi kendi geliştirme veya test ortamında çalıştırabilmeli; bağımlılık dosyalarını, ortam değişkenlerini, build adımlarını ve dağıtım gereksinimlerini inceleyebilmelidir. Şifre, API anahtarı veya özel erişim bilgilerinin doğrudan kaynak kod içine gömülü olup olmadığı da kontrol edilmelidir. Kod tesliminde yalnızca dosyaların varlığı değil, projenin anlaşılabilirliği, dokümantasyonu ve mevcut üretim sürümüyle deponun gerçekten eşleşip eşleşmediği değerlendirilmelidir.

• Git deposunda kurum adına yönetici veya sahip erişimini doğrulayın.
• Üretimde çalışan sürümün hangi commit veya release olduğunu belirleyin.
• Bağımlılık ve build dosyalarının eksiksiz olduğundan emin olun.
• Gizli anahtarların kod içinde tutulup tutulmadığını kontrol edin.
• Kurulum ve yayınlama adımlarının dokümante edilmesini isteyin.

Sunucu ve DNS Devir Teslimi Hangi Sırayla Yapılmalı?

Sunucu ve DNS devir teslimi, önce erişim ve yedeklerin güvence altına alınması, ardından yeni ekibin mevcut yapılandırmayı incelemesi ve ancak doğrulama sonrasında değişiklik yapılması sırasıyla ilerlemelidir. DNS değişikliğini geçişin başlangıcı olarak görmek risklidir; uygulama, veritabanı, SSL, CDN, cron görevleri, dosya depolama ve e-posta bağımlılıkları anlaşılmadan yapılan altyapı değişikliği kesintiye veya işlev kaybına neden olabilir.

Altyapıyı taşımadan önce mevcut çalışma biçimini belgeleyin

Yeni sağlayıcı, bulut ve sunucu yönetimi kapsamındaki mevcut kaynakları, servisleri ve erişim modelini incelemelidir. Domain registrar hesabı ile DNS sağlayıcısının aynı hizmet olmayabileceği; CDN, SSL veya e-posta kayıtlarının ayrı platformlarda yönetilebileceği dikkate alınmalıdır. Geçiş öncesinde DNS kayıtlarının, sunucu yapılandırmasının ve kritik zamanlanmış görevlerin kopyası alınmalı, geri dönüş için hangi eski yapılandırmanın korunacağı belirlenmelidir.

• Domain sahipliği ile DNS yönetim erişimini ayrı ayrı doğrulayın.
• Sunucu veya bulut hesabında kurumun yetkili kullanıcılarını tanımlayın.
• SSL, CDN, cron ve depolama bağımlılıklarını belgeleyin.
• Mevcut DNS kayıtlarının geçiş öncesi kopyasını alın.
• Altyapı değişikliği öncesinde geri dönüş senaryosu hazırlayın.

Veritabanı ve Yedekler Devir Öncesinde Nasıl Kontrol Edilmeli?

Veritabanı ve yedekler devir öncesinde, güncellik, bütünlük, geri yüklenebilirlik ve erişim yetkileri açısından kontrol edilmelidir. Yedeğin var olması tek başına yeterli değildir; hangi veritabanının üretimde kullanıldığı, dosya yüklemelerinin nerede tutulduğu ve son yedeğin gerçekten geri alınabilir durumda olup olmadığı bilinmelidir. Özellikle içerik, müşteri kaydı, form verisi veya uygulama içi işlemler sürekli değişiyorsa geçiş anına yakın alınacak son yedek ayrıca planlanmalıdır.

Dosya sistemi ile veritabanını aynı kurtarma planında düşünün

Web sitesi devralma sürecinde veritabanı dökümü ile medya, kullanıcı yüklemeleri ve uygulamanın diğer kalıcı dosyaları birbirinden ayrı konumlarda bulunabilir. Yeni ekip, test ortamında geri yükleme yaparak verinin uygulamayla uyumlu açıldığını doğrulamalıdır. Yedeklerin yalnızca eski ajansın kontrolündeki bir hesapta tutulması yerine kurumun erişebildiği veya yeni sağlayıcıyla ortak yönettiği güvenli bir konuma alınması, sağlayıcı değişikliğinden sonra da operasyonel sürekliliği korur.

• Üretimde kullanılan veritabanını ve sürümünü doğrulayın.
• Medya ve kullanıcı dosyalarının depolama konumunu belirleyin.
• Geçiş öncesinde güncel tam yedek alınmasını planlayın.
• Yedeği test ortamında geri yükleyerek kullanılabilirliğini kontrol edin.
• Yedek erişiminin kurumda da bulunmasını sağlayın.

Analytics ve Search Console Sahipliği Nasıl Devredilmeli?

Analytics ve Search Console sahipliği, mevcut kullanıcının şifresini paylaşmak yerine kurumun kontrol ettiği kullanıcı hesaplarına uygun yetkiler verilerek devredilmelidir. Hesap sahipliği kişisel erişimden ayrılmalıdır; Google Analytics, Search Console, Tag Manager ve benzeri ölçümleme araçlarında kurumun en az bir yönetim yetkisine sahip kullanıcısı bulunmalı, yeni ajansa ise görevini yerine getirecek seviyede erişim tanımlanmalıdır. Böylece sağlayıcı değişse bile geçmiş veri, yapılandırma ve ölçümleme sürekliliği korunur.

Ölçümleme hesabını yalnızca giriş yapabilmek açısından değerlendirmeyin

Yeni ekip, property ve container erişimlerinin yanında dönüşüm tanımlarını, event yapılarını, etiketleri, filtreleri ve ilgili site doğrulamalarını da gözden geçirmelidir. Eski ajansın kişisel hesabına bağlı kritik yapılandırmalar varsa kurum hesabına kontrollü geçiş planlanmalıdır. Bu aşama, yeni sağlayıcının geçmiş raporlamayı anlayabilmesi ve devir sonrasında veri kopukluğu yaşanmaması için önemlidir; erişim değişikliğinden önce mevcut ayarların ekran görüntüsü veya yapılandırma kaydı alınması da karşılaştırma açısından yararlı olabilir.

• Kurum adına yetkili Analytics kullanıcılarını doğrulayın.
• Search Console sahiplik ve kullanıcı rollerini gözden geçirin.
• Tag Manager hesap ve container yetkilerini ayrı kontrol edin.
• Dönüşüm, event ve etiket yapılandırmalarını kayıt altına alın.
• Eski sağlayıcının erişimini yeni ekip doğrulama yaptıktan sonra kaldırın.

Yeni Firma Hangi Teknik Auditleri Öncelikle Yapmalı?

Yeni firma, değişiklik yapmadan önce kod sağlığı, güvenlik, performans, bağımlılıklar, altyapı ve üçüncü taraf entegrasyonlarını kapsayan bir teknik audit gerçekleştirmelidir. Audit devralınan sistemin başlangıç fotoğrafını oluşturur; hangi sorunların eski yapıdan geldiğini, hangi risklerin acil olduğunu ve hangi geliştirmelerin planlı biçimde ele alınabileceğini ayırmaya yardımcı olur. Bu inceleme olmadan doğrudan özellik geliştirmeye başlamak, görünmeyen teknik borçların yeni değişikliklerle birleşmesine neden olabilir.

Audit sonucunu önceliklendirilmiş geçiş planına dönüştürün

mevcut web sitesinde teknik analiz ve taşıma kriterleri, yeni ekibin kodu yalnızca çalışıyor veya çalışmıyor biçiminde değerlendirmemesi gerektiğini gösteren yararlı bir çerçeve sunar. Güvenlik açısından ise kurumsal web sitesi güvenliği için alınması gereken önlemler erişim, güncelleme ve operasyon sorumluluklarının yeniden incelenmesini destekler. Audit çıktısı kritik, kısa vadeli ve planlı iyileştirmeler şeklinde sınıflandırılmalıdır.

• Kod standardı, bağımlılık ve sürüm durumunu inceleyin.
• Güvenlik açıkları ile erişim yetkilerini ayrı değerlendirin.
• Performans darboğazlarını uygulama ve altyapı düzeyinde kontrol edin.
• Üçüncü taraf API ve servis bağımlılıklarını doğrulayın.
• Audit bulgularını risk ve iş etkisine göre önceliklendirin.

Üçüncü Taraf Servis ve API Hesapları Nasıl Devralınmalı?

Üçüncü taraf servis ve API hesapları, hangi işlevi destekledikleri ve kimin adına kayıtlı oldukları belirlenerek kontrollü biçimde devralınmalıdır. E-posta gönderimi, SMS, ödeme, harita, doğrulama, depolama, CDN veya başka harici servisler uygulamanın görünmeyen bağımlılıklarını oluşturabilir. API anahtarını bilmek hesap sahipliği anlamına gelmez; faturalandırma, yönetici erişimi, kota, domain doğrulaması ve anahtar yenileme yetkisi de kurum tarafından görünür olmalıdır.

Eski anahtarları hemen iptal etmek yerine bağımlılıkları doğrulayın

Yeni ekip önce hangi servis anahtarının hangi ortamda ve hangi özellik için kullanıldığını eşleştirmelidir. Daha sonra gerekiyorsa kurum hesabında yeni anahtar üretilip test ortamında doğrulanmalı, canlı geçiş kontrollü yapılmalı ve eski erişimler ancak sistemin sorunsuz çalıştığı görüldükten sonra kapatılmalıdır. Bu yaklaşım, özellikle eski ajansın kişisel veya kurumsal hesabında bulunan servislerin aceleyle sonlandırılması nedeniyle form, bildirim, ödeme ya da entegrasyon fonksiyonlarının beklenmedik biçimde durması riskini azaltır.

• Tüm üçüncü taraf servisleri işlevleriyle birlikte listeleyin.
• Hesap sahipliği, faturalandırma ve yönetici rollerini doğrulayın.
• API anahtarlarının hangi ortamda kullanıldığını eşleştirin.
• Yeni anahtarları mümkünse önce test ortamında doğrulayın.
• Eski erişimleri canlı sistem kontrolünden sonra sonlandırın.

Web Sitesi Geçişinde Kesinti Riski Nasıl Azaltılabilir?

Web sitesi geçişinde kesinti riski, değişikliklerin tek seferde ve belgesiz yapılması yerine yedek, test, geri dönüş ve sorumluluk planıyla aşamalı yönetilerek azaltılabilir. Kritik değişikliklerden önce geri dönüş noktası oluşturmak, yeni yapılandırmada beklenmeyen sorun çıkarsa çalışan eski duruma dönme seçeneğini korur. Geçiş tarihi belirlenirken yoğun trafik veya kritik kampanya dönemlerinden kaçınmak ve teknik ekiplerin aynı zaman aralığında erişilebilir olmasını sağlamak da operasyonel riski düşürür.

Canlı değişiklikten önce test ve geri dönüş senaryosunu onaylayın

Yeni ekibin staging veya benzeri güvenli bir ortamda uygulamayı çalıştırması, entegrasyonları test etmesi ve gerekli altyapı ayarlarını doğrulaması tercih edilmelidir. DNS veya sunucu değişikliği gerekiyorsa değişiklik sırası, sorumlu kişiler ve kontrol listesi önceden yazılmalıdır. Geçiş sonrasında temel sayfalar, formlar, oturumlar, entegrasyonlar, analitik etiketleri ve hata kayıtları kontrol edilmelidir. Böylece “site açılıyor” kontrolünün ötesinde gerçek işlevlerin ve ölçümleme sürekliliğinin korunup korunmadığı anlaşılır.

• Geçiş öncesi tam yedek ve geri dönüş noktası oluşturun.
• Değişiklikleri mümkünse önce test ortamında doğrulayın.
• DNS, sunucu ve uygulama adımlarını sıralı kontrol listesine bağlayın.
• Canlı geçiş sonrası kritik işlevleri tek tek test edin.
• Eski altyapıyı yeni sistem doğrulanana kadar kontrollü biçimde koruyun.

Yeni Web Bakım Firmasıyla Süreklilik Nasıl Güvenceye Alınır?

Yeni web bakım firmasıyla süreklilik, devir teslim tamamlandıktan sonra erişim sahipliği, dokümantasyon, bakım sorumlulukları ve değişiklik yönetiminin sözleşmede açık biçimde tanımlanmasıyla güvenceye alınır. Yeni sağlayıcıya bağımlılık yeniden üretilmemelidir; kaynak kod, domain, altyapı ve analitik hesaplarında kurumun yönetim erişimi korunmalı, hangi varlıkların müşteriye ait olduğu ve sözleşme sona erdiğinde nasıl teslim edileceği baştan belirlenmelidir.

Audit sonucunu bakım ve geliştirme teklifinin temeline dönüştürün

Yeni firma teknik audit sonrasında acil riskleri, bakım gereksinimlerini ve devam eden geliştirme işlerini ayrı kalemler halinde planlamalıdır. web tasarım firmasıyla yapılan sözleşmede bulunması gereken unsurlar incelenerek erişim, kaynak kod, destek, devir teslim ve sorumluluk sınırları daha açık hale getirilebilir. Böylece geçiş projesi yalnızca eski ajansın erişimlerini kapatan kısa bir işlem olmaktan çıkar; kurumun gelecekte sağlayıcı değiştirebilmesini de koruyan sürdürülebilir bir teknik yönetim modeline dönüşür.

• Kurumun yönetici erişimlerini sözleşme boyunca koruyun.
• Bakım, yeni geliştirme ve acil müdahale kapsamlarını ayırın.
• Dokümantasyonun güncel tutulmasından kimin sorumlu olduğunu belirleyin.
• Kaynak kod ve hesap devir şartlarını sözleşmede açıkça tanımlayın.
• Düzenli yedek, güvenlik ve performans kontrollerini çalışma planına ekleyin.