Başka Bir Web Hosting Sağlayıcısına Geçerken Nelere Dikkat Edilmeli

Bir web sitesini yeni bir hosting sağlayıcısına taşımak, bir site sahibinin üstlenebileceği en yüksek riskli altyapı operasyonlarından biridir. Doğru yapıldığında sıfır veri kaybı, ihmal edilebilir kesinti süresi ve ölçülebilir şekilde daha iyi performans sağlar. Dikkatsizce yapıldığında ise bozuk veritabanları, DNS hataları, SEO sıralama düşüşleri ve saatler süren acil kurtarma çalışmaları ortaya çıkar.

Bu kılavuz, bir hosting migrasyonunun her kritik aşamasını kapsamaktadır — migrasyon öncesi denetim ve uyumluluk doğrulamasından DNS geçiş mekaniklerine, migrasyon sonrası izlemeye kadar — olaysız bir şekilde yürütmek için gereken teknik derinlikle.

Aşama 1: Herhangi Bir Şeye Dokunmadan Önce Mevcut Hosting Ortamınızı Denetleyin

En yaygın migrasyon başarısızlığı, mevcut ortamın kapsamlı bir denetimini atlamaktan kaynaklanır. Yeni bir sağlayıcıyı değerlendirmeden önce, gerçekte ne çalıştırdığınızın kesin bir envanterini çıkarmanız gerekir.

Trafik ve Kaynak Profili Oluşturma

En az 90 günlük sunucu kaynak verisi çekin — yalnızca sayfa görüntüleme sayıları değil. Önemli olan metrikler şunlardır:

• Tepe eş zamanlı bağlantılar — ortalama trafik değil, sunucunuzun karşılaması gereken ani artış tavanı
• PHP worker veya uygulama işlemi başına bellek tüketimi
• Disk I/O kalıpları — özellikle WooCommerce veya özel bir CRM gibi veritabanı yoğun bir uygulama çalıştırıyorsanız önemlidir
• Bant genişliği kullanımı — aylık toplam transfer ile mevcut planınızın sınırı karşılaştırması

Mevcut hostinginiz cPanel veya Plesk sağlıyorsa, bu verilere kaynak kullanımı veya AWStats bölümlerinden erişilebilir. Bir Linux VPS üzerinde, temel bir anlık görüntü almak için aşağıdakini çalıştırın:

vmstat 1 10
iostat -x 1 5
free -m
df -h

Bu çıktı, darboğazınızın CPU, RAM veya disk olup olmadığını söyler — bu da doğrudan daha büyük bir paylaşımlı plan, bir VPS veya bir Dedicated Server ihtiyacınız olup olmadığını belirler.

Yazılım Yığını Envanteri

Yığınınızın her bileşenini tam sürüm numaralarıyla belgeleyin:

• PHP sürümü (örn. 8.1, 8.2) ve aktif uzantılar (mbstring, curl, gd, imagick, redis)
• MySQL veya MariaDB sürümü ve depolama motoru (InnoDB ile MyISAM, migrasyon araçları için önemlidir)
• Web sunucusu yazılımı: Apache, Nginx, LiteSpeed veya ters proxy kombinasyonu
• Derlenmiş modüller, özel .htaccess kuralları veya nginx.conf konum blokları
• Cron işleri — bunları crontab -l‘dan dışa aktarın ve ayrıca belgeleyin
• SSL sertifika türü ve yayıncısı (Let’s Encrypt, ticari CA, wildcard)

Hedef sunucuda tek bir PHP uzantısının eksik olması bile, yalnızca belirli kullanıcı eylemlerinde ortaya çıkan işlevselliği sessizce bozabilir — migrasyon sonrasında izlemesi son derece güç bir hata.

Aşama 2: Doğru Hosting Katmanını Değerlendirin ve Seçin

Yanlış hosting katmanını seçmek, aylarca içinde ikinci bir migrasyonu zorunlu kılan yapısal bir hatadır. Denetim bulgularınızı doğru altyapı sınıfıyla eşleştirin.

Hosting Katmanı Karşılaştırması

Temel karar kuralı: Uygulamanız belirli bir PHP-FPM havuz yapılandırması, Redis soket bağlantıları, özel Nginx yeniden yazmaları veya herhangi bir daemon süreci gerektiriyorsa, paylaşımlı hosting mimari olarak uyumsuzdur. En az root erişimine sahip bir VPS’e ihtiyacınız vardır.

Orta düzey trafiğe sahip WordPress veya Joomla siteleri için, cPanel’li VPS, sanal makinenin izolasyon ve performansını korurken tanıdık kontrol paneli arayüzü sağlar.

Sağlayıcı Değerlendirme Kriterleri

Pazarlama iddialarının ötesinde, sağlayıcıları şu doğrulanabilir teknik faktörlere göre değerlendirin:

• Mali ceza maddeli uptime SLA — tazminatsız %99.9 SLA anlamsızdır
• Veri merkezi katman derecelendirmesi (üretim iş yükleri için Tier III veya Tier IV)
• Ağ yedekliliği — BGP çoklu bağlantı, birden fazla upstream sağlayıcı
• Depolama türü — NVMe SSD ile SATA SSD ile dönen disk karşılaştırması (gecikme farkları önemlidir)
• Yedekleme politikası — sıklık, saklama süresi, yedeklemelerin site dışında depolanıp depolanmadığı
• Destek yanıt süresi SLA — ilk yanıt süresi ile çözüm süresi arasındaki farkı gözetin

Aşama 3: Eksiksiz Bir Yedek Oluşturun ve Doğrulayın

Hiçbir migrasyon, doğrulanmış ve geri yüklenebilir bir yedek olmadan başlamamalıdır. “Doğrulanmış”, geri yüklemeyi gerçekten test ettiğiniz anlamına gelir — yalnızca bir yedek dosyasının var olduğunu onaylamak değil.

Eksiksiz Bir Yedeğin İçermesi Gerekenler

• Web kök dosyaları — .htaccess ve .env gibi gizli dosyalar dahil tüm belge kökü
• Tüm veritabanları — veritabanı dizininin dosya kopyası değil, .sql dökümleri olarak dışa aktarılmış
• E-posta verileri — alan adınıza bağlı E-posta Hosting kullanıyorsanız, herhangi bir DNS değişikliğinden önce posta kutularını dışa aktarın
• Cron işleri — crontab -l > crontab_backup.txt
• SSL sertifikaları ve özel anahtarlar — ticari sertifika kullanıyorsanız, tam zinciri dışa aktarın
• Sunucu yapılandırma dosyaları — /etc/nginx/, /etc/apache2/, /etc/php/, özel my.cnf ayarları

Veritabanı Dışa Aktarma İşlemi

MySQL/MariaDB için, tam doğruluğu koruyan seçeneklerle mysqldump kullanın:

mysqldump 
  --single-transaction 
  --routines 
  --triggers 
  --events 
  --set-gtid-purged=OFF 
  -u root -p your_database_name > database_backup_$(date +%F).sql

--single-transaction bayrağı InnoDB tabloları için kritiktir — tabloları kilitlemeden tutarlı bir anlık görüntü alır; bu da döküm sırasında canlı sitenizin istekleri sunmaya devam ettiği anlamına gelir.

Yedek Bütünlüğünü Doğrulama

# Check the SQL dump is not truncated
tail -5 database_backup_2024-01-15.sql

# Verify file count in web root backup
tar -tzf webroot_backup.tar.gz | wc -l

# Test restoration to a local or staging environment
mysql -u root -p test_restore_db < database_backup_2024-01-15.sql

Geri yüklemeyi test etmediğiniz bir yedek, yedek değildir — yanlış bir güvenlik hissidir.

Aşama 4: Hedef Sunucuda Uyumluluğu Doğrulayın

Üretim verilerini aktarmadan önce, yeni ortamı başlatın ve bir staging yaklaşımı kullanarak uyumluluğu doğrulayın.

PHP Sürümü ve Uzantı Doğrulaması

# On the destination server
php -v
php -m | grep -E 'mbstring|curl|gd|imagick|redis|zip|intl|opcache'

Bu çıktıyı Aşama 1’deki envanterinizle karşılaştırın. Eksik uzantılar, migrasyondan sonra değil, önce yüklenmelidir.

Veritabanı Uyumluluk Kontrolü

MySQL 5.7’den MySQL 8.0’a geçiş yapıyorsanız (yaygın bir senaryo), şu kırıcı değişikliklere dikkat edin:

• utf8mb3 karakter seti kullanımdan kaldırılmıştır; sütunların açık karakter seti bildirimine ihtiyacı olabilir
• GROUP BY davranışı değişti — 5.7’de çalışan sorgular, ONLY_FULL_GROUP_BY modu ayarlaması olmadan 8.0’da başarısız olabilir
• NO_ZERO_DATE katı modda varsayılan olarak etkindir; bu da 0000-00-00 içeren tarih alanlarını reddeder

Üretim trafiğini geçirmeden önce SQL dökümünüzü hedef MySQL sürümüne karşı test edin.

Web Sunucusu Yapılandırma Dönüşümü

Apache’den Nginx’e geçiş yapıyorsanız (performans optimize edilmiş bir VPS’e geçerken sık karşılaşılan bir senaryo), .htaccess kurallarınız otomatik olarak dönüşmez. Yaygın dönüşümler:

Apache .htaccess yönlendirmesi:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

server bloğundaki Nginx eşdeğeri:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Bu dönüşümün atlanması, migrasyon sonrası 404 hatalarının ve yönlendirme döngülerinin en yaygın nedenlerinden biridir.

Aşama 5: Migrasyonu Kesinti Süresini En Aza İndirerek Gerçekleştirin

Migrasyon Penceresini Stratejik Olarak Seçin

En düşük trafik pencerenizi belirlemek için Google Analytics veya sunucu günlüklerinizi analiz edin — genellikle birincil kitlenizin saat dilimine göre Salı veya Çarşamba günleri 02:00 ile 05:00 arasıdır. Cuma günlerinden kaçının; bir şeyler ters giderse, hafta sonu destek seçenekleriniz önemli ölçüde daralır.

Önce Staging Migrasyon İş Akışı

1. Yeni sunucuya bir alt alan adı yönlendirin (örn. staging.example.com) bir A kaydı kullanarak, üretim DNS’ine dokunmadan
2. Tüm dosyaları ve veritabanlarını yeni sunucuya aktarın
3. Uygulamanın veritabanı bağlantı dizesini yeni veritabanına işaret edecek şekilde güncelleyin
4. Yerel /etc/hosts dosyanızı değiştirin — üretim alan adını yeni sunucunun IP’sine çözümleyecek şekilde — bu, canlı kullanıcıları etkilemeden tam üretim yapılandırmasını test etmenizi sağlar:

# Add to /etc/hosts on your local machine
203.0.113.50  example.com www.example.com

1. Tam işlevsel test çalıştırın — her form, ödeme akışı, giriş sistemi, API uç noktası ve medya yükleme
2. ab (Apache Benchmark) veya wrk kullanarak performans kıyaslamaları çalıştırın:

ab -n 1000 -c 50 https://example.com/

1. Yalnızca tüm testleri geçtikten sonra DNS geçişine devam edin

SSL Sertifika Yapılandırması

DNS geçişinden önce SSL sertifikanızın yeni sunucuya yüklendiğinden ve doğrulandığından emin olun. Let’s Encrypt kullanıyorsanız:

certbot --nginx -d example.com -d www.example.com

SSL Sertifikaları aracılığıyla sağlanan gibi ticari bir sertifika kullanıyorsanız, eski istemcilerde zincir doğrulama hatalarını önlemek için tam sertifika zincirini (sertifika + ara CA + kök CA) yükleyin.

Aşama 6: DNS Geçişi — En Teknik Açıdan Hassas Adım

DNS yayılımı yaygın olarak yanlış anlaşılmaktadır. 48 saatlik rakam, tipik bir süre değil, en kötü durum tavanıdır. Pratikte, çoğu çözümleyici değiştirilen kaydın TTL değerine uyar.

Geçiş Öncesi TTL Azaltma

Migrasyon penceresinden en az 24–48 saat önce, A kayıtlarınız ve CNAME kayıtlarınızdaki TTL’yi 300 saniyeye (5 dakika) düşürün:

example.com.    300  IN  A  203.0.113.50
www.example.com. 300 IN  A  203.0.113.50

Bu, kaydı yeni IP’ye güncellediğinizde, eski önbelleğe alınmış değerin çoğu çözümleyici için 48 saat değil, 5 dakika içinde sona ereceği anlamına gelir. Bu, DNS yayılım penceresini en aza indirmek için tek en etkili tekniktir.

Name Server ile A Kaydı Güncellemeleri

İki farklı DNS geçiş yaklaşımı vardır:

• Yalnızca A kayıtlarını değiştirin (aynı yetkili ad sunucularını korurken): Yayılım, kaydın TTL’sini takip eder. Alan adı kayıt şirketiniz doğrudan kayıt yönetimine izin veriyorsa en hızlı yaklaşım.
• Ad sunucularını değiştirin (yeni hostingin DNS’ine yönlendirin): Ad sunucusu TTL’leri genellikle 24–48 saattir ve doğrudan kontrolünüz altında değildir. Bu yaklaşım daha uzun sürer.

Mümkün olduğunda A kaydı güncellemelerini tercih edin. Doğrudan kayıt düzeyinde kontrol için alan adınızın DNS’ini Alan Adı Kaydı kontrol paneli aracılığıyla yönetin.

Yayılım Süresince Eski Sunucuyu Aktif Tutma

DNS geçişinin hemen ardından eski hosting planını iptal etmeyin veya kapatmayın. En az 72 saat boyunca çalışır durumda tutun. Yayılım sırasında, kullanıcılarınızın bir kısmı hâlâ eski IP’ye çözümlenecektir — bu isteklerin sunulmaya devam etmesi gerekir. Eski sunucuyu erken kapatmak, bu kullanıcılar için gerçek bir kesintiye yol açar.

Aşama 7: Migrasyon Sonrası İzleme ve Doğrulama

Uptime ve Performans İzleme

Yayılımın tamamlandığını düşündükten sonra değil, DNS geçişinin hemen ardından harici uptime izlemeyi yapılandırın. Kullanılacak araçlar:

• UptimeRobot veya Better Uptime — birden fazla coğrafi konumdan her 1–5 dakikada bir HTTP(S) kontrolleri
• Google Search Console — migrasyon sonrası 7 gün boyunca Kapsam ve Core Web Vitals raporlarındaki anormallikleri izleyin
• New Relic veya Datadog — uygulamanız gerektiriyorsa uygulama düzeyinde performans izleme

Migrasyon Sonrası Hataları Belirleme ve Çözme

Screaming Frog veya bir wget mirror kullanarak yeni sitenin taramasını hemen çalıştırın:

wget --spider --recursive --no-verbose --output-file=crawl_log.txt https://example.com
grep -i "broken|404|error" crawl_log.txt

Yaygın migrasyon sonrası sorunlar ve nedenleri:

WordPress Veritabanlarındaki Sabit Kodlanmış URL’leri Düzeltme

Sık karşılaşılan ve ince bir sorun: WordPress site URL’sini veritabanında saklar ve birçok tema ve eklenti, serileştirilmiş verilerde mutlak URL’ler depolar. Yeni bir alan adına veya protokole geçişten sonra şunu çalıştırın:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' 
  --all-tables 
  --precise 
  --report-changed-only

--precise bayrağı, PHP serileştirilmiş verileri doğru şekilde işler; basit dize değiştirme bunu bozar.

Aşama 8: Eski Hosting Planını İptal Edin

Eski planı yalnızca aşağıdaki koşulların tamamı doğrulandıktan sonra iptal edin:

• DNS yayılımı tamamlandı (birden fazla konumdan dig +trace example.com ile doğrulayın)
• Uptime izleme, en az 72 ardışık saat boyunca %100 kullanılabilirlik gösteriyor
• Tarama günlüklerinde 404 hatası veya bozuk bağlantı tespit edilmedi
• E-posta teslimi yeni sunucuda doğru şekilde çalışıyor
• Analitikler, anormal düşüş olmaksızın normal trafik kalıpları gösteriyor
• Her iki hosting sağlayıcısından bağımsız olarak tüm yedek dosyaların yerel kopyasına sahipsiniz

Teknik Temel Çıkarım Kontrol Listesi

Bunu migrasyon uygulama kontrol listeniz olarak kullanın:

Migrasyon Öncesi

• [ ] 90 günlük kaynak kullanımı temeli dışa aktarıldı (CPU, RAM, I/O, bant genişliği)
• [ ] Tam yazılım yığını tam sürüm numaralarıyla belgelendi
• [ ] DNS TTL, geçişten en az 24 saat önce 300 saniyeye düşürüldü
• [ ] Tam yedek oluşturuldu ve test edildi (dosyalar + veritabanları + cron işleri + e-posta)
• [ ] Hedef sunucuda PHP sürümü ve gerekli tüm uzantılar doğrulandı
• [ ] Web sunucusu değiştiriliyorsa .htaccess kuralları Nginx formatına dönüştürüldü
• [ ] DNS değişikliğinden önce yeni sunucuya SSL sertifikası yüklendi ve doğrulandı

Migrasyon Sırasında

• [ ] Dosyalar sağlama toplamı doğrulamasıyla rsync kullanılarak aktarıldı (rsync -avz --checksum)
• [ ] Veritabanı içe aktarıldı ve satır sayılarının kaynakla eşleştiği doğrulandı
• [ ] DNS değişikliğinden önce /etc/hosts geçersiz kılma yoluyla tam site işlevselliği test edildi
• [ ] Uygulama yapılandırma dosyaları güncellendi (veritabanı hostu, kimlik bilgileri, site URL’si)

Migrasyon Sonrası

• [ ] DNS geçişinin 5 dakikası içinde harici uptime izleme aktif
• [ ] Eski sunucu, geçişten sonra en az 72 saat boyunca çalışır durumda tutuldu
• [ ] Tam site taraması tamamlandı; tüm 404’ler ve bozuk bağlantılar çözüldü
• [ ] Veritabanındaki sabit kodlanmış URL’ler düzeltildi (özellikle WordPress için)
• [ ] Google Search Console, migrasyon sonrası 7 gün boyunca izlendi
• [ ] Eski hosting planı yalnızca yukarıdaki tüm maddeler doğrulandıktan sonra iptal edildi

Sıkça Sorulan Sorular

DNS yayılımı gerçekte ne kadar sürer ve hızlandırabilir miyim?

DNS yayılım süresi, sabit bir 48 saatlik pencere değil, değiştirilen kaydın TTL değeriyle belirlenir. A kaydı TTL’nizi migrasyondan en az 24 saat önce 300 saniyeye düşürürseniz, çoğu çözümleyici değişiklikten sonraki 5–10 dakika içinde yeni IP’yi alır. 48 saatlik rakam, kontrolünüz dışındaki TTL’lere sahip ad sunucusu delegasyon değişiklikleri için geçerlidir.

Yeni bir hosta geçmek Google arama sıralamalarımı etkiler mi?

Kesinti süresi olmadan, korunmuş URL yapısıyla ve geçerli SSL ile doğru şekilde gerçekleştirilen bir migrasyon, olumsuz SEO etkisi yaratmaz. Yeni sunucu daha yavaşsa, URL’ler uygun 301 yönlendirmeleri olmadan değişirse veya tarama sırasında siteye erişilemezse sıralamalar geçici olarak düşebilir. Migrasyon sonrası 14 gün boyunca Google Search Console’un Kapsam ve Core Web Vitals raporlarını izleyin.

Büyük veritabanlarını veri bozmadan aktarmanın en güvenli yolu nedir?

Tablo kilitleri olmadan tutarlı bir anlık görüntü sağlamak için InnoDB tabloları için --single-transaction bayrağıyla mysqldump kullanın. Büyük veritabanlarında sessiz kırpmalara neden olan dosya boyutu sınırları ve zaman aşımı kısıtlamalarına sahip phpMyAdmin yerine, döküm dosyasını SSH üzerinden scp veya rsync kullanarak aktarın.

Geçiş yaptıktan sonra SSL sertifikamı yeniden yüklemem gerekiyor mu?

Evet. SSL sertifikaları, orijinal sunucuda bulunan sunucunun özel anahtarına bağlıdır. Yeni sunucuda sertifikayı yeniden yayınlamanız (Let’s Encrypt için ücretsiz) ya da özel anahtarı ve sertifika zincirini eski sunucudan dışa aktarıp yeni sunucuya yüklemeniz gerekir. DNS’i güncellemeden önce sertifikanın tam olarak doğrulandığından emin olun; böylece geçişin hemen ardından HTTPS çalışır durumda olur.

Eski planı iptal etmeden önce migrasyonumun tamamlandığını nasıl doğrularım?

Hem Google hem de Cloudflare çözümleyicilerinin yeni sunucunun IP’sini döndürdüğünü doğrulamak için dig +trace example.com @8.8.8.8 ve dig +trace example.com @1.1.1.1 çalıştırın. 72 ardışık saat boyunca temiz yanıtlar için uptime izlemeyi kontrol edin. 404 hataları için siteyi tarayın ve e-posta teslimatını doğrulayın. Bunların tamamı geçtikten sonra eski hosting hesabını sonlandırmak güvenlidir.