Hosting Firması Değiştirirken DNS ve Domain Taşıma Kontrol Listesi

Hosting değiştirirken neden detaylı bir DNS ve domain planı şart?

Hosting firmanızı değiştirmek performans, maliyet ya da destek kalitesi açısından çok doğru bir karar olabilir. Ancak DNS ve domain tarafını doğru planlamazsanız bu geçiş süreci; açılmayan siteler, çalışmayan e‑postalar ve SEO kaybıyla sonuçlanabilir. Özellikle canlı bir e‑ticaret sitesi, SaaS ürünü veya yoğun trafikli blog işletiyorsanız, birkaç dakikalık kesinti bile doğrudan gelir kaybı ve itibar zedelenmesine dönüşebilir.

Biz DCHost tarafında en çok şu tabloyla karşılaşıyoruz: Yeni sunucu eksiksiz hazırlanıyor ama DNS ve domain planı son dakikaya bırakılıyor. TTL düşürme atlanıyor, MX kayıtları taşınmıyor, eski sunucudaki SPF ve DKIM ayarları unutuluyor. Sonuç; bir kısmı eski sunucuya, bir kısmı yeni sunucuya giden istekler, karışan cache kayıtları ve günlerce süren sorun takibi.

Bu yazıda, hosting firması değiştirirken DNS ve domain taşıma sürecini adım adım planlayabileceğiniz kapsamlı bir kontrol listesi hazırladık. Amacımız; realistik şekilde sıfıra yakın kesinti, minimum risk ve tamamen öngörülebilir bir geçiş akışı. Yazıyı, teknik ekibinizle beraber kullanabileceğiniz bir runbook gibi düşünebilirsiniz.

1. Adım: Mevcut durumu haritalandırın ve görünmeyen riskleri çıkarın

İyi bir taşıma planının ilk şartı, bugün neye sahip olduğunuzu tam olarak bilmektir. Çoğu kesinti, gözden kaçmış tek bir DNS kaydından ya da unutulan bir alt alan adından kaynaklanır.

1.1. Alan adı ve DNS envanteri çıkarın

Aşağıdaki sorulara net yanıtlar veremiyorsanız önce envanteri tamamlamalısınız:

• Hangi alan adları taşımanın parçası olacak? (com, net, com.tr vb.)
• Bu domainlere bağlı hangi alt alan adları var? (www, api, panel, mail, cdn vb.)
• Mevcut DNS sağlayıcınız kim? (domain kayıt firması, önceki hosting sağlayıcı ya da ayrı bir DNS hizmeti)
• Hangi DNS kayıtları tanımlı? A, AAAA, CNAME, MX, TXT, SRV, CAA vb.
• Hangi kayıtlar kritik işlevler için kullanılıyor? (web sitesi, e‑posta, API, entegrasyonlar, üçüncü parti servisler)

DNS kayıt türleri konusunda emin değilseniz, DNS kayıtları A’dan Z’ye rehberimizi mutlaka gözden geçirmenizi öneririz. Böylece taşıma sırasında hangi kaydı neden değiştirdiğinizi çok daha bilinçli yönetebilirsiniz.

1.2. E‑posta altyapısını özellikle ayırın

Çoğu işletme için web sitesinin birkaç dakika kapanması tolere edilebilirken, e‑postaların kaybolması ya da saatlerce teslim edilememesi çok daha büyük sorun yaratır. Bu yüzden:

• Hangi alan adlarının MX kayıtları eski hostinge işaret ediyor, netleştirin.
• SPF, DKIM ve DMARC kayıtlarını listeleyin.
• Webmail, POP3/IMAP ve SMTP bağlantı ayarlarını not edin.

Özellikle e‑posta taşıma tarafını derinlemesine görmek isterseniz, e‑posta altyapısını taşırken kesinti yaşamamak için hazırladığımız rehbere göz atabilirsiniz.

1.3. Teknik ve iş önceliklerini belirleyin

Her proje için kritik bileşenler farklıdır. Örneğin:

• Bir içerik sitesi için SEO ve cache süreleri kritik olabilir.
• Bir e‑ticaret sitesi için sepet ve ödeme akışının kesintisizliği önceliklidir.
• Bir SaaS ürünü için API ve veritabanı bağlantı sürekliliği kritiktir.

Taşıma planını bu önceliklere göre tasarlarsanız, hangi sistem için ne kadar risk alabileceğinizi baştan netleştirmiş olursunuz.

2. Adım: Yeni hosting altyapısını DCHost üzerinde paralel hazırlayın

DNS değişikliklerine dokunmadan önce, yeni hosting ortamının mümkün olduğunca hazır hale gelmesi gerekir. DCHost üzerinde ister paylaşımlı hosting, ister VPS, ister dedicated ya da colocation kullanın, mantık aynıdır: Önce aynayı kurun, sonra trafiği taşıyın.

2.1. Yeni sunucuyu yapılandırın

• Gerekirse PHP sürümü, veritabanı motoru ve versiyonunu mevcut ortama yakın seçin.
• Gerekli eklenti ve modülleri kurun (örneğin PHP eklentileri, cache modülleri, web sunucusu ayarları).
• SSL sertifikası için temel hazırlığı yapın. Let’s Encrypt ya da kurumsal SSL hangi modeli kullanacaksanız planlayın.
• Güvenlik tarafında temel sertleştirme adımlarını uygulayın (SSH ayarları, firewall, panel güvenliği).

Paylaşımlı hostingden DCHost VPS altyapısına yükseliyorsanız, performans ve kaynak planlaması açısından paylaşımlı hostingden VPS’e sorunsuz geçiş rehberimizden de yararlanabilirsiniz.

2.2. Web dosyalarını ve veritabanlarını yeni ortama kopyalayın

Bu aşamada henüz DNS’i değiştirmeden, sitenin bir kopyasını yeni sunucuya alırsınız:

• Eski hostingte tam dosya yedeği alın (public_html, uygulama dizini, yapılandırma dosyaları).
• Veritabanlarını SQL dump olarak dışa aktarın.
• Yeni sunucuda veritabanı oluşturup dump dosyalarını içe aktarın.
• Gerekliyse yapılandırma dosyalarında (örneğin WordPress wp-config.php, Laravel .env) veritabanı bağlantı ayarlarını güncelleyin.

cPanel kullanıyorsanız, cPanel’de tüm siteyi yedekleme ve geri yükleme rehberimiz bu adımları pratikleştirmenize yardımcı olur.

2.3. Panelden panele otomatik taşıma imkanı varsa kullanın

Eski ve yeni sunucu ikisi de cPanel ise, DCHost tarafında WHM transfer araçlarıyla neredeyse birebir kopya oluşturabilirsiniz. Bu durumda:

• Eski sunucunun root ya da transfer için yetkili hesabına erişim alın.
• WHM üstünden hesap transferini başlatın.
• Oluşan hesaplar üzerinde örnek site ve e‑posta kutularını test edin.

Bu senaryo için, cPanel’den cPanel’e canlı taşıma rehberimizde sıfıra yakın kesinti için TTL ve incremental rsync stratejilerini detaylı anlattık.

3. Adım: DNS stratejisi ve TTL planı olmadan hamle yapmayın

DNS tarafı, taşımanın kaderini belirleyen en kritik katmandır. Yanlış zamanda yapılan küçük bir değişiklik, saatlerce sürecek sorunlara dönüşebilir. Buradaki ana kavram, TTL değeridir.

3.1. TTL nedir ve neden düşürmelisiniz?

TTL, bir DNS kaydının internet üzerindeki cache’lerde ne kadar süre saklanacağını belirleyen saniye cinsinden bir süredir. Örneğin A kaydınızın TTL’i 14400 ise, yapılan değişikliklerin küresel olarak tam oturması 4 saate yakın sürebilir.

Hosting değişimi öncesinde hedefiniz şu olmalıdır:

• Kritik kayıtların TTL değerlerini geçici olarak ciddi şekilde düşürmek (örneğin 14400 yerine 300 ya da 120 saniye).
• Geçiş tamamlandıktan ve her şey stabil olduktan sonra TTL değerlerini tekrar yükseltmek.

DNS yayılımının nasıl çalıştığını ve neden 24 saate kadar sürebildiğini anlamak için DNS yayılım süresi rehberimize bakabilirsiniz.

3.2. Zero-downtime için önerilen TTL zaman çizelgesi

DCHost olarak gerçek projelerde çoğu zaman aşağıdaki akışı uyguluyoruz:

• Taşıma gününden 48–72 saat önce: Alan adınızın A, AAAA, MX ve kritik CNAME kayıtlarının TTL değerlerini 300 saniyeye (veya 120) düşürün.
• Taşıma gününe kadar: Bu kayıtları değiştirmeyin, sadece yeni sunucu hazırlığına odaklanın.
• Taşıma anında: A, AAAA ve gerekiyorsa MX kayıtlarını yeni sunucuya işaret edecek şekilde güncelleyin.
• Her şeyin stabil olduğundan emin olduktan sonra: TTL değerlerini yeniden daha yüksek bir değere alın (örneğin 3600 veya 7200).

Bu konuyu daha detaylı teknik örneklerle görmek istiyorsanız, zero‑downtime taşıma için TTL stratejileri yazımız tam olarak bu sorunu ele alıyor.

3.3. Nameserver mi değiştireceksiniz, yoksa sadece A kaydı mı?

Hosting firması değiştirirken iki temel yaklaşımınız var:

1. Mevcut DNS sağlayıcısını koruyup sadece A ve ilgili kayıtları yeni IP’ye yönlendirmek.
2. Nameserver’ları tamamen DCHost DNS altyapısına taşıyıp tüm kayıt yönetimini burada yapmak.

Risk açısından bakarsak, adım adım ilerlemek genellikle daha güvenlidir. Örneğin ilk adımda sadece web trafiğini A kaydıyla yeni IP’ye yönlendirip, nameserver değişikliğini daha sonra ayrı bir bakıma bırakabilirsiniz. Böylece aynı gün hem hosting hem DNS sağlayıcısını değiştirmemiş olursunuz.

4. Adım: Web sitesi ve uygulamaları yeni sunucuda test edin

DNS’i çevirmeden önce mutlaka yeni ortamda kapsamlı test yapmalısınız. Bunun için üretim domainini kullanmak zorunda değilsiniz.

4.1. Hosts dosyasıyla lokal yönlendirme

Bilgisayarınızdaki hosts dosyasını kullanarak, sadece kendi makinenizden giden istekleri yeni IP’ye yönlendirebilirsiniz. Böylece gerçek domain adıyla, DNS’i küresel olarak değiştirmeden test imkanı bulursunuz.

• Hosts dosyasına yeni sunucu IP’si ve alan adını ekleyin.
• Tarayıcı önbelleğini temizleyin.
• Siteyi son kullanıcı gözüyle gezerek formlar, ödeme adımları, giriş‑çıkış gibi kritik akışları test edin.

4.2. Özel alt alan adıyla staging ortamı

Alternatif olarak staging ya da test alt alanı tanımlayabilirsiniz. Örneğin staging.ornekalanadi.com gibi bir subdomaini doğrudan yeni sunucuya yönlendirip, taşıma öncesinde burada test yapabilirsiniz. Bu model, özellikle devam eden geliştirmeleriniz varsa çok işe yarar.

4.3. Performans ve log kontrolleri

Yeni sunucuya geçtiğinizde sadece sitenin açılması yeterli değildir. Aşağıdakileri de kontrol edin:

• PHP hata loglarında uyarı ya da kritik hata var mı?
• Veritabanı bağlantı süreleri ve sorgu performansı kabul edilebilir seviyede mi?
• Önbellekleme (page cache, object cache) düzgün çalışıyor mu?

Daha teknik performans optimizasyonu ihtiyaçlarınız varsa, DCHost blogumuzdaki WordPress, Laravel ve veritabanı odaklı performans rehberlerinden yararlanabilirsiniz.

5. Adım: DNS cutover – trafiği yeni sunucuya çevirme anı

Artık en kritik adıma geldiniz: DNS cutover. Bu an, gerçek kullanıcı trafiğinin eski sunucudan yeni sunucuya yönlendirildiği andır.

5.1. Ön kesit kontrol listesi

DNS kayıtlarını değiştirmeden hemen önce aşağıdakileri kontrol edin:

• Yeni sunucudaki site içeriği güncel mi ve son verilerle senkronize mi?
• Veritabanı son kez senkronize edildi mi? (özellikle sık güncellenen siteler için kritik)
• SSL sertifikası yeni sunucuda düzgün tanımlı mı ve tarayıcıda güvenli olarak görünüyor mu?
• E‑posta için gerekli MX, SPF, DKIM ve gerekliyse DMARC kayıtları yeni DNS tarafında hazır mı?

5.2. A ve AAAA kayıtlarını yeni IP’ye güncelleyin

İlk adım olarak genellikle sadece A ve varsa AAAA kayıtları güncellenir:

• www alt alanı için A kaydını yeni sunucu IP’sine çevirin.
• Kök alan adınız (example.com) A kaydını da yeni IP’ye çevirin.
• IPv6 kullanıyorsanız, AAAA kayıtlarını da yeni sunucudaki IPv6 adreslerine yönlendirin.

TTL değerleri önceden düşürüldüyse, bu değişiklikler birkaç dakika içinde büyük oranda etkisini göstermeye başlar.

5.3. E‑posta MX, SPF ve DKIM ayarlarını senkron tutun

Web trafiğiyle birlikte e‑posta altyapısını da taşıyorsanız, MX ve ilgili TXT kayıtlarını aynı bakım penceresinde güncelleyin:

• MX kayıtlarını yeni e‑posta sunucularına işaret edecek şekilde düzenleyin.
• SPF kaydına yeni gönderen IP ya da hostname bilgilerini ekleyin.
• DKIM için yeni sunucuda oluşturulan public key’e uygun TXT kaydını tanımlayın.

SPF, DKIM ve DMARC tarafını sıfırdan kurgulamanız gerekiyorsa, SPF, DKIM ve DMARC rehberimiz size teknik olarak adım adım yol gösterecektir.

5.4. Eski sunucuyu hemen kapatmayın

DNS yayılımı hiçbir zaman tüm dünyada aynı anda gerçekleşmez. Bu yüzden:

• Eski sunucuyu en az 24–48 saat daha yayında tutun.
• Mümkünse kritik uygulamalar için eski ve yeni veritabanlarını kısa süre paralel senkronize edin.
• Logları takip ederek eski sunucuya hâlâ trafik gelip gelmediğini gözlemleyin.

Bu yaklaşım, özellikle yavaş DNS cache güncelleyen ağlar ya da kurumsal proxy’ler yüzünden oluşabilecek sorunları büyük ölçüde azaltır.

6. Adım: Domain transferini ne zaman yapmalısınız?

Hosting firması değiştirirken domaini de başka bir kayıt kuruluşuna taşımak isteyebilirsiniz. Ancak aynı anda hem hosting hem domain transferi yapmak karmaşıklığı artırır.

6.1. Domain transferini hosting taşımasından ayırmak genellikle daha güvenli

Pratikte en az riskli senaryo şudur:

1. Önce hosting taşınır ve DNS kayıtları yeni sunucuya yönlendirilir.
2. Her şeyin stabil olduğundan emin olunur.
3. Domain transferi için ayrıca bir bakım penceresi planlanır.

Bu sırada nameserver’lar sabit tutulabilir, sadece domainin kayıt kuruluşu değişir. Böylece bir saat içinde hem nameserver hem kayıt kuruluşu hem de hosting firması değişmiyor olur.

6.2. Domain transferi öncesi dikkat edilmesi gerekenler

Taşıma öncesi mutlaka şu kontrolleri yapın:

• Domain transfer kilidini (transfer lock) kaldırdınız mı?
• Güncel whois e‑posta adresiniz erişilebilir ve doğru mu?
• EPP/transfer kodunu aldınız mı?
• Domain süresi bitiş tarihi çok yakın mı? (Transfer öncesi yenilemek mantıklı olabilir.)

Adım adım domain transfer sürecini merak ediyorsanız, alan adı transferi nasıl yapılır rehberimizde süreci sakin ve detaylı şekilde anlattık.

6.3. Domain transferi e‑postayı etkiler mi?

Domain transferi sırasında nameserver’ları değiştirmez ve MX kayıtlarına dokunmazsanız, teoride e‑posta hizmetiniz etkilenmez. Ancak:

• Kayıt firması değiştiğinde DNS paneli de değişiyorsa, kayıtların birebir kopyalandığından emin olmanız gerekir.
• Taşıma esnasında nameserver değiştirecekseniz, e‑posta kesintisini önlemek için yukarıda anlattığımız TTL ve paralel yayın stratejilerini uygulamalısınız.

Bu konu için ayrıca, alan adı taşırken e‑posta kesintisini önlemek rehberimizi de inceleyebilirsiniz.

7. Adım: SEO, SSL ve güvenlik için son kontroller

Taşıma tamamlandığında siteniz açılıyor olabilir, ancak SEO ve güvenlik tarafında yapmanız gereken son dokunuşlar vardır.

7.1. SSL ve HTTPS kontrolleri

• Yeni sunucuda SSL sertifikası doğru alan adlarını kapsıyor mu?
• HTTP’den HTTPS’e 301 yönlendirmeleri düzgün çalışıyor mu?
• Mixed content uyarılarına yol açan HTTP içerikler kaldı mı?

HTTPS geçişi ve 301 yönlendirmeleri konusunda derinlemesine bilgi için, HTTP’den HTTPS’e geçiş rehberimizi inceleyebilirsiniz.

7.2. robots.txt, sitemap ve SEO sinyalleri

Taşıma sonrası arama motorlarının sitenizi sorunsuz taramaya devam etmesi gerekir:

• robots.txt dosyanız yeni sunucuda doğru konumda ve doğru içerikte mi?
• sitemap.xml dosyanız güncel ve erişilebilir mi?
• Önemli sayfalarda beklenmedik 404, 500 gibi durum kodları oluşuyor mu?

Bu kontrolleri otomatize etmek için log analizi ve uptime izleme araçlarını da devreye alabilirsiniz.

7.3. Güvenlik ve yedekleme stratejisini güncelleyin

Yeni sunucuya geçtikten sonra güvenlik ve yedekleme politikalarınızı da yeni altyapınıza göre güncellemelisiniz:

• Güncel firewall ve brute‑force koruma ayarlarını uygulayın.
• Otomatik yedekleme planını yeni sunucuda aktifleştirin.
• Yedekleri mutlaka farklı bir lokasyonda ya da object storage üzerinde saklayın.

3‑2‑1 yedekleme stratejisini nasıl kurabileceğinizi merak ediyorsanız, DCHost blogumuzda bu konuda detaylı bir rehber bulabilirsiniz.

8. Adım: Özet kontrol listesi – hosting firması değiştirirken adım adım

Tüm yazıyı uygulamada hızlı kullanabilmeniz için, kritik adımları kompakt bir kontrol listesi halinde toparlayalım.

8.1. Taşıma öncesi hazırlık

• Tüm domain ve alt alan adlarının listesini çıkarın.
• Mevcut DNS sağlayıcınızı ve tüm kayıtları (A, AAAA, CNAME, MX, TXT, SRV, CAA) export edin veya manuel kaydedin.
• E‑posta altyapısını ayrı başlık olarak planlayın (MX, SPF, DKIM, webmail, IMAP/SMTP ayarları).
• Domain transferi de yapacaksanız, bunu hosting taşımasından ayrıştırın.

8.2. Yeni sunucuyu hazırlama

• DCHost üzerinde ihtiyaçlarınıza uygun hosting, VPS ya da dedicated sunucu planını netleştirin.
• Gerekli yazılım sürümlerini (PHP, veritabanı vb.) eski ortama mümkün olduğunca yakın seçin.
• Web dosyalarını ve veritabanlarını yeni ortama aktarın.
• cPanel kullanıyorsanız, panelden panele otomatik transfer imkanlarını değerlendirin.

8.3. DNS ve TTL planı

• Taşıma gününden 48–72 saat önce kritik kayıtların TTL değerlerini 300 saniyeye düşürün.
• Nameserver değiştirmeden sadece A/AAAA kayıtlarıyla geçiş mi, yoksa nameserver taşıması mı yapacağınıza karar verin.
• DNS değişikliklerini tek bir bakım penceresinde planlayın.

8.4. Taşıma ve cutover

• Yeni sunucuyu hosts dosyası ya da staging alt alanıyla test edin.
• Son içerik ve veritabanı senkronizasyonunu yapın.
• A, AAAA ve gerekiyorsa MX kayıtlarını yeni IP’lere yönlendirin.
• SPF, DKIM ve diğer TXT kayıtlarını güncelleyin.
• Eski sunucuyu en az 24–48 saat daha yayında, mümkünse sadece okuma modunda tutun.

8.5. Taşıma sonrası kontroller

• Önemli sayfalar, formlar ve ödeme akışlarını canlı ortamda test edin.
• SSL, HTTPS yönlendirmeleri ve mixed content hatalarını kontrol edin.
• robots.txt ve sitemap.xml dosyalarının erişilebilir olduğundan emin olun.
• Logları takip edip 4xx ve 5xx hata oranlarını izleyin.
• Her şey stabil olduğunda TTL değerlerini yeniden yükseltin.

DCHost ile sıfıra yakın kesintiyle hosting değişimi nasıl görünür?

Doğru planlandığında hosting firması değiştirmek, son kullanıcının fark etmeyeceği kadar pürüzsüz bir süreç olabilir. DCHost tarafında, yeni müşterilerimizin büyük kısmında benzer bir oyun planı uyguluyoruz: Önce ayrıntılı DNS ve domain envanteri çıkarılıyor, ardından yeni sunucu paralel olarak hazırlanıyor, TTL stratejisiyle desteklenen kontrollü bir DNS cutover yapılıyor ve son olarak SEO ile güvenlik kontrolleri tamamlanıyor.

Paylaşımlı hosting, VPS, dedicated sunucu ya da colocation fark etmeksizin, altyapınızı DCHost üzerinde kurgularken bu yazıdaki kontrol listesini doğrudan bir runbook olarak kullanabilirsiniz. Taşıma planı kafanızda netleştikten sonra teknik detaylarda desteğe ihtiyaç duyarsanız, DCHost ekibi olarak DNS, domain transferi ve sunucu taşıma süreçlerinde yanınızda olmaktan memnuniyet duyarız.

Özetle; aceleyle yapılmış, plansız bir taşıma günlerce sürecek bir yangına dönüşebilir. Buna karşılık, doğru TTL ayarları, paralel sunucu hazırlığı ve iyi yazılmış bir kontrol listesiyle, hosting firmanızı değiştirmek sadece birkaç saatlik kontrollü bir operasyon olarak kalır. Şimdi bu yazıyı ekibinizle paylaşın, kendinize uygun bir bakım penceresi seçin ve bir sonraki taşıma operasyonunuzu çok daha öngörülebilir hale getirin.