Web tasarım firması değişikliği, web sitesi dosyalarının yeni bir sunucuya kopyalanmasından daha kapsamlı bir devir sürecidir. Alan adı, DNS, hosting, kaynak kodu, veritabanı, e-posta, lisanslar, entegrasyonlar ve ölçüm hesapları birbirinden farklı sahipliklere ve teknik bağımlılıklara sahip olabilir. Geçiş plansız yürütüldüğünde erişim kaybı, hizmet kesintisi, veri eksikliği veya arama görünürlüğünün etkilenmesi gibi riskler ortaya çıkabilir. Bu nedenle mevcut ilişki sonlandırılmadan önce dijital varlık envanteri hazırlanmalı; yedekleme, teknik denetim, test, yayın, geri dönüş ve yetki kapatma adımları kurumsal bir proje olarak yönetilmelidir.

01

Web Tasarım Firması Değişikliği Neleri Kapsar?

Web tasarım firması değişikliği; teknik varlıkların, hesapların, kullanım haklarının, proje bilgisinin ve yayın sonrası sorumlulukların yeni hizmet sağlayıcıya kontrollü biçimde aktarılmasıdır. İletişim sorunları, yetersiz destek, değişen kurumsal ihtiyaçlar, teknik sınırlılıklar veya dokümantasyon eksikliği değişiklik gerekçesi olabilir. Karar, yalnızca mevcut memnuniyetsizliğe değil gelecekte beklenen hizmet kapsamına da dayanmalıdır.

Firma değişikliğine başlamadan önce ne planlanmalıdır?

Güvenli geçişin ilk adımı, taşınacak varlıklarla korunacak hizmetleri birbirinden ayıran yazılı bir plan hazırlamaktır. Web sitesi, e-posta, alan adı ve ölçüm araçları aynı firmada yönetilse bile teknik olarak farklı hizmetlerdir. Her varlık için mevcut sahip, erişim yetkilisi, yeni sorumlu, taşıma yöntemi, test kriteri ve başarısızlık durumundaki geri dönüş seçeneği belirlenmelidir.

  • Değişikliğin gerekçeleri ve yeni hizmetten beklenen sonuçlar tanımlanmalıdır.
  • Mevcut sözleşmenin fesih, teslim ve gizlilik hükümleri incelenmelidir.
  • Kritik hizmetler ve bu hizmetler arasındaki bağımlılıklar çıkarılmalıdır.
  • Eski ve yeni firmanın görevleri mümkün olduğunca yazılı belirlenmelidir.
  • Geçiş, test, yayın ve izleme aşamaları ayrı planlanmalıdır.
  • Riskli işlemler için uygulanabilir bir geri dönüş senaryosu hazırlanmalıdır.
Planlar değersizdir, fakat planlama her şeydir. - Dwight D. Eisenhower
02

Dijital Varlık ve Erişim Envanteri Nasıl Hazırlanır?

Dijital varlık envanteri, firma değişikliğinde devredilecek bütün hesapları, dosyaları, sistemleri ve sahiplik bilgilerini tek yerde gösterir. Alan adı kayıt hesabı, hosting paneli, sunucu, kaynak kodu deposu, yönetim paneli, e-posta hizmeti ve ölçüm araçları ayrı satırlarda değerlendirilmelidir. Bir hizmete erişilebilmesi, hesabın hukuken veya kurumsal olarak işletmeye ait olduğunu tek başına kanıtlamaz.

Hangi erişimler devirden önce doğrulanmalıdır?

Yalnızca kullanıcı adı ve parola listesi hazırlamak yeterli değildir. Hesabın kayıtlı sahibi, kurtarma adresi, iki faktörlü kimlik doğrulama yöntemi, fatura bilgileri ve yönetici rolleri de kontrol edilmelidir. Erişim bilgilerinin güvenli kanallarla aktarılması, kişisel çalışan hesapları yerine kurumsal hesapların kullanılması ve geçiş sonrasında kritik kimlik bilgilerinin yenilenmesi hizmet sürekliliğini güçlendirir.

  • Alan adı kayıt kuruluşu ve kayıtlı hesap sahibi doğrulanmalıdır.
  • Hosting, sunucu ve kontrol paneli yetkileri kayıt altına alınmalıdır.
  • FTP, SFTP, SSH ve yönetim paneli erişimleri ayrı gösterilmelidir.
  • Kaynak kodu deposu ile sürüm geçmişine erişim kontrol edilmelidir.
  • Analitik, arama ve etiket yönetimi hesaplarının yöneticileri belirlenmelidir.
  • Kurtarma adresleri ve kimlik doğrulama yöntemleri kurumsallaştırılmalıdır.
03

Kaynak Kodu, İçerik ve Lisanslar Nasıl İncelenir?

Kaynak kodu teslimi, yayındaki web sitesinden indirilen görünen dosyalarla sınırlı olmayabilir. Git deposu ve sürüm geçmişi, bağımlılık tanımları, yapılandırma örnekleri, derleme yöntemi, zamanlanmış görevler ve teknik dokümantasyon sürdürülebilir geliştirme için gerekli olabilir. Kaynak kodu sahipliği ve kullanım hakları mevcut sözleşmeye göre değişebileceğinden hukuki belirsizlikler gerektiğinde uzmanla değerlendirilmelidir.

Lisansların yeni firmaya aktarılması mümkün müdür?

Tema, eklenti, yazı tipi, stok görsel, özel yazılım veya üçüncü taraf servis lisanslarının aktarılabilirliği aynı değildir. Satın almayı yapan hesap, kullanım alanı, yenileme sorumluluğu ve devir koşulları ayrı ayrı kontrol edilmelidir. Lisans devredilemiyorsa yeni lisans ihtiyacı ve bunun teknik etkisi yayından önce belirlenmeli; lisanssız kullanım varsayımına dayanılmamalıdır.

  • Kaynak kodu ve çalışan sürümün birbiriyle uyumu doğrulanmalıdır.
  • Git deposu, dallar, sürüm etiketleri ve yayın notları teslim alınmalıdır.
  • İçerik, medya ve düzenlenebilir tasarım dosyaları envantere eklenmelidir.
  • Yazılım bağımlılıkları ve sunucu gereksinimleri belgelenmelidir.
  • Her lisansın sahibi, kapsamı ve yenileme koşulu incelenmelidir.
  • Eksik veya devredilemeyen bileşenler için çözüm planlanmalıdır.
04

Alan Adı, Hosting ve E-Posta Geçişi Nasıl Yapılır?

Alan adı transferi, nameserver değişikliği, DNS yönetimi ve hosting taşıma farklı işlemlerdir; firma değişikliğinde hepsinin birlikte yapılması gerekmeyebilir. Alan adı aynı kayıt kuruluşunda kalırken yalnızca DNS veya web sunucusu değiştirilebilir. Geçiş planı; web sitesi, e-posta, doğrulama kayıtları, alt alan adları ve üçüncü taraf servislerin hangi DNS kayıtlarına bağlı olduğunu göstermelidir.

Kurumsal e-posta neden ayrı bir geçiş planı gerektirir?

E-posta taşıma yalnızca yeni posta kutuları açmaktan oluşmaz. Kullanıcılar, mesajlar, klasörler, yönlendirmeler, takma adlar, otomatik yanıtlar, MX kayıtları ve gönderim doğrulama ayarları korunmalıdır. Web sitesi yeni hosting ortamına taşınırken e-posta aynı sağlayıcıda kalabilir. Bu nedenle DNS değişiklikleri yapılmadan önce mevcut kayıtlar eksiksiz belgelenmeli ve e-posta akışı ayrıca test edilmelidir.

  • Alan adı transferi ile DNS değişikliği birbirinden ayrılmalıdır.
  • Mevcut DNS kayıtlarının eksiksiz bir kopyası alınmalıdır.
  • Yeni hosting ortamının teknik uyumluluğu önceden doğrulanmalıdır.
  • SSL sertifikasının yeni ortamda nasıl çalışacağı planlanmalıdır.
  • E-posta kutuları, takma adlar ve yönlendirmeler envantere alınmalıdır.
  • Web ve e-posta hizmetleri yayından sonra ayrı ayrı izlenmelidir.
05

Dosya, Veritabanı ve Yedekler Nasıl Aktarılmalıdır?

Web sitesi taşıma sürecinde uygulama dosyaları, veritabanı, medya içerikleri ve sunucu yapılandırmaları ayrı bileşenler olarak ele alınmalıdır. WordPress, Laravel veya özel yazılım projelerinde gereksinimler; kullanılan sürümlere, bağımlılıklara, dosya izinlerine, zamanlanmış görevlere ve sunucu servislerine göre değişebilir. Yalnızca ana dizinin kopyalanması çalışan ve eksiksiz bir sistem elde edildiğini göstermez.

Yedeğin kullanılabilir olduğu nasıl doğrulanır?

Dosya yedeği, veritabanı yedeği ve tam sistem yedeği farklı kapsamlar sunar. Taşıma öncesinde güncel kopyalar alınmalı ve mümkünse kontrollü bir test ortamında geri yüklenmelidir. Böylece eksik tablolar, bozuk arşivler, unutulan medya dosyaları veya ortam bağımlılıkları yayından önce görülebilir. Kişisel veri içeren yedeklere erişim, saklama ve silme kuralları da tanımlanmalıdır.

  • Dosya, veritabanı ve yapılandırma yedekleri ayrı doğrulanmalıdır.
  • Medya dizinleri ve yönetim panelindeki içerikler karşılaştırılmalıdır.
  • Yazılım sürümleri ile sunucu bağımlılıkları kayıt altına alınmalıdır.
  • Zamanlanmış görevler ve arka plan işlemleri yeni ortama kurulmalıdır.
  • Yedeklerin geri yüklenebilirliği test ortamında sınanmalıdır.
  • Eski ve yeni sistemdeki veri farkları yayın öncesinde uzlaştırılmalıdır.
06

Entegrasyonlar ve Ölçüm Araçları Nasıl Devredilir?

CRM, ERP, ödeme, form, e-posta gönderimi veya başka bir API entegrasyonu yalnızca web sitesi kodundan oluşmaz; harici hesaplar, erişim anahtarları, geri dönüş adresleri ve yetkilendirmeler de sürecin parçasıdır. Yeni firma her entegrasyonun sahibini, veri yönünü, test yöntemini ve hata davranışını incelemelidir. Üretim kimlik bilgileri güvenli aktarılmalı ve geçiş tamamlandıktan sonra yenilenmelidir.

Analytics ve arama verilerinin geçmişi nasıl korunur?

Google Analytics, Search Console ve Tag Manager için yeni hesap açmak mevcut geçmişi otomatik olarak taşımaz. İşletmenin mevcut mülklere kurumsal yönetici erişimi alması, diğer kullanıcıların rollerini denetlemesi ve ölçüm kimliklerini koruması tercih edilmelidir. Dönüşümler, reklam bağlantıları, onay yönetimi ve etiketler test edilmeli; eski firmanın yetkileri doğrulama tamamlandıktan sonra kaldırılmalıdır.

  • Her entegrasyonun hesabı, sahibi ve teknik sorumlusu belirlenmelidir.
  • API erişimleri ile geri dönüş adresleri yeni ortama uyarlanmalıdır.
  • Ödeme ve form bildirimleri kontrollü senaryolarla test edilmelidir.
  • Analytics ve Search Console yönetici erişimleri kuruma verilmelidir.
  • Tag Manager etiketleri ile dönüşüm tanımları doğrulanmalıdır.
  • Eski anahtarlar ve gereksiz kullanıcı yetkileri geçiş sonrasında kapatılmalıdır.
07

Firma Değişikliğinde SEO Görünürlüğü Nasıl Korunur?

Firma değişikliği SEO görünürlüğünü zorunlu olarak kaybettirmez; ancak URL, içerik, sunucu davranışı veya indeksleme ayarları kontrolsüz değişirse risk oluşturabilir. Taşıma öncesinde taranabilir URL envanteri, başlıklar, içerikler, canonical tercihleri, site haritası, robots.txt, yapılandırılmış veriler ve çok dilli eşleştirmeler kaydedilmelidir. Mümkün olan yerlerde mevcut adres ve içerik devamlılığı korunmalıdır.

URL değişikliklerinde yönlendirme planı nasıl hazırlanır?

URL değişmesi gerekiyorsa eski ve yeni adreslerin birebir eşleştirildiği bir yönlendirme haritası hazırlanmalıdır. Kalıcı olarak taşınan sayfalarda uygun 301 yönlendirmeleri kullanılmalı; ilgisiz sayfaların tamamı ana sayfaya yönlendirilmemelidir. Dahili bağlantılar, canonical adresleri ve site haritası yeni yapıya göre güncellenmeli; tarama, indeksleme ve organik performans yayın sonrasında düzenli izlenmelidir.

  • Mevcut URL ve içerik envanteri taşıma öncesinde çıkarılmalıdır.
  • Başarılı sayfaların adresleri mümkün olduğunda korunmalıdır.
  • Değişen URL’ler için birebir yönlendirme haritası hazırlanmalıdır.
  • Robots.txt ve indeksleme engelleri yayın öncesinde kontrol edilmelidir.
  • Canonical, çok dilli etiketler ve yapılandırılmış veriler doğrulanmalıdır.
  • Tarama hataları ile organik görünürlük yayın sonrasında izlenmelidir.
08

Güvenli Yayın ve Geri Dönüş Planı Nasıl Hazırlanır?

Güvenli yayına geçiş; yeni ortamın üretimden önce test edilmesini, değişikliklerin sıralanmasını, sorumluların belirlenmesini ve eski sisteme dönüş seçeneğinin korunmasını gerektirir. Test ortamında sayfalar, formlar, yönetim paneli, e-posta bildirimleri, entegrasyonlar, performans, erişilebilirlik ve güvenlik kontrolleri yapılmalıdır. Ana sayfanın açılması tek başına başarılı taşıma anlamına gelmez.

KVKK ve erişim güvenliği nasıl korunmalıdır?

Kişisel veriler yedeklenirken, aktarılırken ve yeni ortamda saklanırken yalnızca yetkili kişiler tarafından erişilebilir olmalıdır. Eski firmanın erişimleri geçiş tamamlanmadan kapatılırsa gerekli bilgi veya dosyalara ulaşmak zorlaşabilir; geçiş sonrasında açık bırakılırsa güvenlik riski doğabilir. Kabul tamamlandıktan sonra şifreler, API anahtarları ve kurtarma yöntemleri yenilenmeli, gereksiz hesaplar kaldırılmalıdır.

  • Yeni sistem üretimden önce kapalı test ortamında doğrulanmalıdır.
  • Yayın adımları, sorumlular ve kontrol sırası yazılı hâle getirilmelidir.
  • Geçiş öncesinde güncel ve doğrulanmış yedek alınmalıdır.
  • Başarısızlık durumundaki geri dönüş ölçütleri belirlenmelidir.
  • Kişisel veriler güvenli aktarım ve erişim yöntemleriyle korunmalıdır.
  • Yayın sonrasında şifreler, anahtarlar ve kullanıcı yetkileri yenilenmelidir.
09

Devir Teslim ve Yeni Firma Seçimi Nasıl Tamamlanır?

Teknik devir teslim, aktarılan dosya ve hesapların yazılı envanterle doğrulanması ve kurumun gerekli erişimleri teslim almasıyla tamamlanır. Devir tutanağında alan adı, hosting, kaynak kodu, veritabanı, e-posta, lisanslar, entegrasyonlar, ölçüm araçları, yedekler ve dokümantasyon bulunmalıdır. Eski firmanın erişimleri, yeni sistemin kabulü tamamlandıktan sonra kontrollü biçimde kaldırılmalıdır.

Yeni web tasarım firması hangi kriterlerle seçilmelidir?

Yeni firma yalnızca taşıma fiyatı üzerinden değil; teknik denetim yaklaşımı, benzer geçiş deneyimi, güvenlik uygulamaları, SEO sürekliliği, dokümantasyon ve yayın sonrası destek kapasitesiyle değerlendirilmelidir. Teklif, hangi varlıkların taşınacağını ve hangi hizmetlerin kapsam dışında kaldığını göstermelidir. Veri hacmi, altyapı, e-posta, entegrasyon, test ve destek ihtiyaçları proje maliyetini etkileyebilir.

  • Devir edilen bütün varlıklar yazılı kontrol listesiyle doğrulanmalıdır.
  • Kurum, kritik hesaplarda sahip veya tam yetkili yönetici olmalıdır.
  • Yeni firmanın taşıma ve geri dönüş yaklaşımı incelenmelidir.
  • SEO, güvenlik ve e-posta sorumlulukları teklifte ayrı gösterilmelidir.
  • Bakım, teknik destek ve sürekli geliştirme kapsamı açıklanmalıdır.
  • Eski erişimler kabul tamamlandıktan sonra kontrollü kapatılmalıdır.
  • Sözleşme ve hak sahipliği belirsizlikleri gerektiğinde hukuk uzmanına incelenmelidir.