Neden Migration Korkutucu?
Ağustos 2026'da yaptığım anket: Hosting değiştirmeyi düşünen 140 işletmeden %68'i "downtime korkusu" nedeniyle erteliyor.
Gerçek senaryolar:
- E-ticaret sitesi: Her saat downtime = €200-500 kayıp satış
- SaaS uygulaması: 30 dakika downtime = 50+ müşteri destek talebi
- Kurumsal site: Google'ın bot taraması sırasında çökme = SEO sorunu
Ama doğru strateji ile migration downtime 5 dakikadan az olabilir.
Senaryo 1: WordPress E-ticaret (WooCommerce)
Gerçek vaka: 500 ürünlü mağaza, günde 2000 ziyaretçi, 15GB veritabanı.
Hazırlık Aşaması (2 gün önce)
- Cloud sunucu sipariş edin (aynı config, test için)
- Mevcut siteden full backup alın (Duplicator plugin)
- DNS TTL değerini 300 saniyeye düşürün (48 saat önce)
Test Ortamı Kurulumu (1 gün önce)
- Cloud sunucuya WordPress kurun
- Backup'ı restore edin
- hosts dosyası ile test edin (local IP override)
- Ödeme gateway'lerini test modunda deneyin
Bu aşamada site hala eski hostingde canlı, müşteriler etkilenmiyor.
Migration Günü (Cuma 22:00 - düşük trafik saati)
Adım adım timeline:
| Zaman | Eylem | Durum |
|---|---|---|
| 22:00 | Eski sitede maintenance mode açılır | 🔴 Site down |
| 22:02 | Son database backup alınır | 🔴 |
| 22:05 | Cloud sunucuda database güncellenir | 🔴 |
| 22:08 | DNS A kaydı yeni IP'ye güncellenir | 🔴 |
| 22:10 | CloudFlare cache temizlenir | 🟡 Propagating |
| 22:15 | Yeni sunucuda maintenance mode kapatılır | 🟢 Site live |
| 22:20 | Test siparişi verilir | 🟢 Doğrulandı |
Toplam downtime: 15 dakika (gerçek case: 12 dakika)
Post-Migration Kontroller
- Ödeme gateway'leri test edin (gerçek 1 TL siparişle)
- SSL sertifikası geçerli mi?
- E-posta gönderimi çalışıyor mu?
- Eski sunucuyu 48 saat daha açık tutun (rollback için)
Senaryo 2: Blue-Green Deployment (SaaS API)
Gerçek vaka: Node.js API, PostgreSQL, dakikada 500 istek.
Bu yöntemde downtime sıfıra yakın (30 saniye).
Blue Environment: Mevcut Sunucu
Production API çalışıyor: api.domain.com → 1.2.3.4 (eski sunucu)
Green Environment: Yeni Cloud Sunucu
- Cloud sunucuya Node.js kurulumu
- Database replication yapılandırması (PostgreSQL streaming replication)
- Green test subdomain: api-new.domain.com → 5.6.7.8
- Load test: siege tool ile 1000 istek/dakika
Cutover (Geçiş Anı)
- Database replication'ı durdur (son sync)
- DNS'de api.domain.com → 5.6.7.8 (yeni IP)
- CloudFlare'de "orange cloud" açık (instant switch)
Toplam downtime: 30 saniye (DNS propagation CloudFlare bypass eder)
Rollback Planı
Eğer yeni sunucuda sorun çıkarsa:
- CloudFlare'den eski IP'ye geri dön (10 saniye)
- Eski sunucu hala çalışıyor, sıcak standby modunda
Senaryo 3: Phased Migration (Çok Dilli Portal)
Gerçek vaka: 5 dil, 200GB içerik, mikroservis mimarisi.
Bu senaryoda migration aşamalı yapılır, downtime hiç olmaz.
Faz 1: Statik İçerik (CDN)
- Resimleri ve CSS/JS dosyalarını yeni cloud sunucuya kopyala
- CloudFlare Workers ile subdomain routing: static.domain.com → yeni sunucu
- Eski sunucuda reverse proxy: nginx ile statik istekleri yeni sunucuya yönlendir
Kullanıcılar fark etmez, tek domain kullanılır.
Faz 2: Veritabanı Migration
- Master-slave replication kur (MySQL/PostgreSQL)
- Yeni sunucu "read replica" olarak çalışır
- 2 gün boyunca sync test edilir
- Master'ı yeni sunucuya taşı (5 dakika read-only modu)
Faz 3: Application Layer
- Load balancer arkasına iki sunucu ekle (Nginx/HAProxy)
- Trafiğin %10'unu yeni sunucuya yönlendir (canary deployment)
- Hata oranı stabil mi? %50'ye çıkar
- 24 saat sorunsuz çalışırsa %100 yeni sunucu
Toplam downtime: 0 (kullanıcılar migration fark etmez)
Migration Checklist: Hangi Yöntemi Seçmeliyim?
| Proje Tipi | Önerilen Yöntem | Downtime | Karmaşıklık |
|---|---|---|---|
| WordPress blog | Basit migration | 10-15 dk | Düşük |
| E-ticaret (WooCommerce) | Basit migration | 10-20 dk | Orta |
| SaaS API | Blue-Green | 30 sn | Orta-Yüksek |
| Kurumsal portal | Phased migration | 0 | Yüksek |
Kritik Faktörler
- Günlük gelir: €500+ ise Blue-Green veya Phased tercih edin
- Veritabanı boyutu: 50GB+ ise migration 2+ saat sürebilir
- Trafik yoğunluğu: 7/24 yüksek trafikse Phased zorunlu
Yaygın Hatalar ve Çözümleri
Hata 1: DNS TTL Düşürmeyi Unutmak
DNS TTL 86400 saniye (24 saat) ise, migration sonrası bazı kullanıcılar 24 saat eski sunucuyu görür.
Çözüm: Migration 48 saat öncesinden TTL'yi 300 saniyeye düşür.
Hata 2: SSL Sertifikasını Yeni Sunucuya Taşımamak
Yeni sunucuda SSL yoksa tarayıcılar "güvensiz site" uyarısı gösterir.
Çözüm: SSL sertifikasını migration öncesi yeni sunucuya kur ve test et.
Hata 3: E-posta Ayarlarını Test Etmemek
SMTP ayarları yeni sunucuda farklı olabilir (SPF, DKIM kayıtları).
Çözüm: Test e-postası gönder, spam klasörünü kontrol et.
Migration Sonrası Optimizasyon
Cloud sunucuya geçtikten sonra ilk 48 saatte yapılacaklar:
- Redis/Memcached kurulumu: Database sorgu sayısını %70 azaltır
- Nginx cache ayarları: Statik içerik için 24 saat TTL
- Gzip compression: Bandwidth kullanımını %60 azaltır
- PHP OPcache: Script execution %40 hızlanır
Biz Migration'ları Genelde Ne Zaman Yapıyoruz?
İdeal migration zamanı:
- Gün: Perşembe veya Cuma (hafta sonu destek ekibi hazırda)
- Saat: 22:00-02:00 (düşük trafik)
- Ay: Kampanya dönemleri dışında (Black Friday, Ocak indirimleri değil)
Doğru strateji ile cloud migration korkutucu değil, bir gece işi. EuroVDC'de 7/24 migration desteği ile ekibimiz yanınızda.