Bayi Hosting Taşıma: Çok Sayıda Müşteri Sitesi İçin Geçiş Planı

Çok sayıda müşteri sitesini yeni bir bayi hesabına taşımanın güvenli yolu, hepsini tek gecede değil, envantere dayalı dalgalar hâlinde taşımaktır. Önce her hesabın diskini, e-posta ve veritabanı sayısını, PHP sürümünü ve DNS'inin nerede yönetildiğini bir tabloya dökün. Ardından hedef paketin toplam kapasitesini ve sürüm uyumunu doğrulayın, düşük riskli bir hesapla deneme taşıması yapın. Hesapları kritikliğe göre gruplayın, TTL değerlerini önceden düşürerek her dalgada DNS'i ayrı ayrı çevirin ve eski sunucuyu son dalgadan sonra da bir süre açık tutun.

Bu yazı bayi ölçeğindeki planlamayı anlatır. Tek bir hesabın yedeklenip yeni sunucuda açılması için başka firmadan cPanel hosting taşıma rehberine bakın.

Hesap envanteri

Plan eksiksiz bir listeyle başlar. Taşıma sırasında çıkan sorunların çoğu listede olmayan bir alan adından, unutulmuş bir e-posta yönlendirmesinden ya da DNS'i başka bir firmada duran bir müşteriden kaynaklanır.

Hesap listesini WHM'deki List Accounts (hesap listesi) ekranından alabilirsiniz. Her hesabın ayrıntısı için cPanel ana sayfasındaki Statistics (istatistikler) bölümü disk kullanımını (Disk Usage), dosya sayısını (File Usage, yani inode), e-posta hesabı ve veritabanı sayısını gösterir. File Usage satırının görünmesi sağlayıcının ayarına bağlıdır; görünmüyorsa bu değeri sağlayıcınızdan isteyin.

Envanter tablosu şablonu

Örnek satırlar varsayımsaldır; tabloyu kendi hesaplarınızla doldurun.

Kritikliği üç düzeyde tanımlamak yeterlidir:

• Yüksek: Sipariş, rezervasyon veya ödeme alan siteler; e-postası kesildiğinde işi duran müşteriler.
• Orta: Düzenli güncellenen kurumsal siteler ve aktif kullanılan e-posta hesapları.
• Düşük: Nadiren değişen tanıtım siteleri, e-postası az kullanılan hesaplar.

Tabloya şu sütunları da eklemek geçiş gecesindeki sürprizleri azaltır: SSL sertifikasının türü (otomatik mi, satın alınmış mı), cron görevleri, siteden e-posta gönderen formlar ve dış SMTP ayarları, alan adının kayıtlı olduğu firma ve o panele kimin erişebildiği, müşteri tarafındaki teknik iletişim kişisi.

Kota ve sürüm kontrolü

Toplam kapasite

Envanterdeki disk ve inode değerlerini toplayın ve hedef paketin değerleriyle karşılaştırın. Toplama iki pay ekleyin: yıllık büyüme ve taşıma sırasında oluşan geçici dosyalar. cPanel belgelerine göre kotasına yakın bir hesapta yedekleme, gerekli dosyalar yazılamadığı için başarısız olabilir. WHM'de bir yedek arşivi geri yüklenirken de sunucuda arşiv boyutunun en az iki katı boş alan bulunmalıdır.

Örnek: 30 hesabın toplam disk kullanımı 96 GB, toplam inode sayısı 1,4 milyon olsun ve yıllık %25 büyüme bekleyelim. Bu durumda en az 120 GB disk gerekir; 100 GB'lık bir paket ilk günden sınırda kalır. Inode için de aynı hesabı yapın ve hedef paketin inode sınırını sağlayıcıdan yazılı olarak isteyin. İşlemci, bellek ve eşzamanlı işlem gibi disk dışı kaynakları da hesaba katın; ölçülmeden taşınan portföy yeni sunucuda aynı darboğaza takılır.

Hesap sayısı ve paketler

Hedef bayi hesabında açabileceğiniz cPanel hesabı ve alan adı sayısını kontrol edin. Paket kartındaki site sayısının cPanel hesabını mı, alan adını mı saydığını sipariş öncesi sorun; addon ve park edilmiş alan adlarının bu sayıya nasıl yansıdığını da netleştirin.

Paketlerinizi taşımadan önce hedef WHM'de tanımlayın. Geri yükleme sırasında sistem arşivdeki paketi hedefte oluşturmaya çalışır; oluşturamazsa hesaba varsayılan paketi atar. Bu, hesabın disk ve e-posta sınırlarının sessizce değişmesi demektir. Paket tanımlama adımları için WHM'de paket tanımlama ve müşteri hesabı açma yazısına bakın.

PHP sürümü

Her alan adının PHP sürümünü cPanel'deki MultiPHP Manager ekranından not edin ve hedef sunucuda aynı sürümün bulunduğunu doğrulayın. Eski bir sürümde çalışan site (örnekteki 7.4 gibi) hedefte yalnız daha yeni sürümlerle karşılaşırsa taşımayla birlikte bozulabilir.

Kural basit: aynı anda iki şeyi değiştirmeyin. Ya siteyi taşımadan önce eski sunucuda yeni PHP sürümüne geçirip test edin ya da aynı sürümle taşıyıp güncellemeyi sonraya bırakın. Sorun çıktığında nedenin sunucu mu, sürüm mü olduğunu ayırt edebilmeniz buna bağlıdır. Hesaba özel PHP-FPM ayarları kullanıyorsanız bunları da listeleyin; cPanel belgelerine göre Transfer Tool ile yapılan taşımada bu ayarlar kendiliğinden devreye girmez, sonradan elle geri yüklenir.

MySQL ve MariaDB sürümü

cPanel'deki Server Information (sunucu bilgileri) ekranı, sunucunun veritabanı yazılımının sürümünü "MySQL Version" satırında gösterir; MariaDB kullanan sunucularda da satırın adı aynıdır. Eski ve yeni sunucunun değerlerini karşılaştırın. cPanel'in sunucu taşıma belgesi, hedefte aynı MySQL veya MariaDB sürümü kullanılmadığında ciddi hatalar görülebileceğini belirtir ve yazılım güncellemesini taşımadan sonraya bırakmayı önerir.

Eski sürümden yeniye geçişte döküm çoğunlukla içe aktarılır, ancak uygulamanın yeni sürümün daha katı SQL kurallarıyla uyumu ayrıca test edilmelidir. Yeniden eskiye geçişte ve MySQL ile MariaDB arasındaki geçişlerde karakter kümesi ve karşılaştırma (collation) farkları içe aktarmayı durdurabilir. Hedefteki veritabanı türünü ve sürümünü sağlayıcıya yazılı sorun ve bu farkı deneme taşımasında özellikle test edin.

Taşıma yöntemi: Transfer Tool mu, tam hesap yedeği mi?

cPanel'den cPanel'e taşımada iki resmi yol vardır. Hangisini kendi bayi WHM'inizden kullanabileceğiniz sağlayıcıya bağlıdır: cPanel belgeleri, bu arayüzlerin bayilere açılıp kapatılmasının sağlayıcının elinde olduğunu belirtir.

WHM Transfer Tool

Transfer Tool (WHM » Transfers » Transfer Tool), bir kaynak sunucudaki birden çok cPanel hesabını, paketleri ve yapılandırmaları tek oturumda hedef sunucuya kopyalar. Şartı, kaynak sunucuda SSH erişimi ve root yetkisidir (doğrudan ya da su veya sudo ile). Paylaşımlı bir bayi hesabından taşınıyorsanız eski sunucuda bu yetkiye sahip olmazsınız; bu yöntem, kaynak sunucunun root erişimi elinizdeyse (örneğin kendi VPS'inizden taşınırken) kullanılabilir.

Transfer Tool'un Live Transfer seçeneği iki cPanel sunucusu arasında kesintiyi azaltmak için tasarlanmıştır. Taşıma bitince kaynak sunucudaki A, nameserver ve MX kayıtlarını hedefe çevirir, web ve e-posta isteklerini hedefe aktarır ve kaynaktaki hesabı askıya alır. Alan adı dış bir e-posta sunucusu kullanıyorsa MX kaydına dokunmaz. cPanel, bu özellik kullanıldığında yönlendirmelerin çalışabilmesi için kaynak sunucunun iki gün daha açık tutulmasını önerir.

Tam hesap yedeği (cpmove)

Kaynakta root yetkisi yoksa standart yol her hesabın tam yedeğidir. Yedek, eski sunucudaki hesabın cPanel'inde Backup ekranındaki Download a Full Account Backup bağlantısından üretilir. Geri yüklemede kabul edilen dosya adları arasında cpmove-KULLANICI.tar.gz ve backup-MM.DD.YYYY_HH-MM-SS_KULLANICI.tar.gz biçimleri bulunur. Arşivin içinde ev dizini ve e-posta kutuları, veritabanı dökümleri, DNS bölge dosyaları, DKIM anahtarları, SSL sertifikaları ve cron görevleri yer alır.

Tam yedek cPanel içinden geri yüklenemez; geri yükleme WHM'deki Transfer or Restore a cPanel Account ekranından yapılır. Bu ekranın üç seçeneği vardır: sunucudaki bir arşivden geri yükleme (Restore from a local cpmove file), arşivi yükleyerek geri yükleme (Upload a file to restore) ve eski sunucudaki hesabı cPanel kullanıcı adı ile parolasıyla doğrudan çekme (Transfer from Remote cPanel Account). Bayi hesabınızda bu ekran açık değilse geri yüklemeyi sağlayıcı yapar; arşivleri nereye koyacağınızı ve hesapların hangi sırayla açılacağını önceden kararlaştırın.

Geri yüklemede varsayılan olarak açık gelen Restricted Restore seçeneğine dikkat edin: cPanel belgelerine göre bu mod park edilmiş (alias) ve addon alan adlarını geri yüklemez. Birden çok alan adı barındıran hesaplarda, geri yüklemeden sonra tüm alan adlarının hesapta göründüğünü kontrol edin. İki adımlı doğrulama (2FA) ayarları ise ne Transfer Tool ne de Transfer or Restore a cPanel Account ile taşınır; müşterilerinizin bunu yeni sunucuda yeniden kurması gerekir.

Deneme taşıması

Portföyün tamamına geçmeden önce bir hesabı uçtan uca taşıyın. Deneme hesabı düşük kritiklikte olmalı ama portföyünüzü temsil etmeli: en az bir veritabanı, birkaç e-posta hesabı ve portföyde yaygın olan PHP sürümü. Kendi ajans sitenizin hesabı çoğu zaman iyi bir adaydır.

1. Taşıyın: Seçtiğiniz yöntemle hesabı hedefte açın. DNS'e dokunmayın.
2. Hosts dosyasıyla test edin: Bilgisayarınızın hosts dosyasına yeni sunucunun IP adresini ve alan adını ekleyin. Böylece siz siteyi yeni sunucudan görürken ziyaretçiler eski sunucuda kalır. Dosya Windows'ta C:\Windows\System32\drivers\etc\hosts, macOS ve Linux'ta /etc/hosts konumundadır ve yönetici yetkisiyle düzenlenir. Örnek satır:

   203.0.113.10  ornekmimar.com.tr www.ornekmimar.com.tr

3. Kontrol edin: Sayfalar, yönetim paneli girişi, formlar, veritabanı bağlantısı ve webmail girişi. Yeni SSL sertifikası, alan adı yeni sunucuyu gösterene kadar üretilemeyebilir; bu aşamadaki sertifika uyarısını not edip geçin.
4. Süreyi ölçün: Yedek üretme, aktarma, geri yükleme ve test adımlarının her birinin kaç dakika sürdüğünü yazın. Dalga takvimi bu ölçümden çıkar.
5. Canlıya alın: Test başarılıysa bu hesabın DNS'ini çevirin ve e-posta akışını bir iki gün izleyin. İlk dalga ancak bundan sonra başlar.
6. Hosts satırını silin: İşletim sistemi eklediğiniz satırı kendiliğinden kaldırmaz; silmezseniz sonraki kontrollerde yanlış sunucuyu görürsünüz.
7. Çalışma kılavuzu yazın: Karşılaştığınız her sorunu ve çözümünü kaydedin. Sonraki dalgalar bu kılavuzla yürür.

DNS ve e-posta geçişi

TTL düşürme zamanlaması

TTL, bir DNS kaydının çözümleyicilerin önbelleğinde en fazla kaç saniye tutulabileceğini belirtir. Kaydı değiştirdiğinizde, eski kaydı önbelleğe almış çözümleyiciler TTL dolana kadar eski adresi vermeye devam eder.

Bu yüzden TTL'i ne zaman düşüreceğiniz eski TTL değerine bağlıdır: yeni düşük değerin her yerde geçerli olması için eski TTL süresi kadar beklemeniz gerekir. Örnek: A kaydının TTL'i 86.400 saniye (24 saat) ise geçişten en az 24 saat önce 300 saniyeye indirin; pay bırakmak için 48 saat daha güvenlidir. TTL'i tüm hesaplarda bir kerede ya da her dalgadan bir iki gün önce düşürebilirsiniz. Geçiş tamamlanıp birkaç gün sorunsuz geçtikten sonra normal değere döndürün; geri dönüş planınız bu süre boyunca düşük TTL'e dayanır.

Nameserver mı, A kaydı mı?

Envanterdeki "DNS nerede" sütunu, hangi hesapta neyi değiştireceğinizi belirler.

Bu yazının hazırlandığı tarihte üst bölgedeki NS kayıtlarının TTL'i .com için 172.800 saniye (48 saat), .tr için 43.200 saniyeydi (12 saat). Bu değerleri kayıt otoriteleri belirler ve değişebilir.

Çok sayıda hesapta pratik yaklaşım iki aşamalıdır. Eski sağlayıcıdaki DNS bölgelerini düzenleyebiliyorsanız dalgalar boyunca DNS'i yerinde bırakın ve her dalgada yalnız A kayıtlarını (gerekirse MX kayıtlarını) yeni sunucuya çevirin. Tüm hesaplar yeni sunucuda oturduktan sonra nameserver değişikliğini ayrı bir adım olarak yapın. Geri yükleme, arşivdeki bölge dosyasında eski IP'yi gösteren A kayıtlarını varsayılan olarak yeni sunucunun IP'siyle değiştirir (Replace All Matching A Records); yine de iki taraftaki bölgelerin aynı kayıtları içerdiğini karşılaştırın. Değişiklik yayılırken bazı çözümleyiciler eski, bazıları yeni nameserver'ı soracağından eski bayi hesabını bu süre dolmadan kapatmayın.

Markalı (özel) nameserver kullanıyorsanız ayrı bir risk vardır: bu adların IP adresini değiştirmek, onları kullanan tüm müşteri alan adlarını aynı anda etkiler. Böyle bir değişikliği dalgaların sonuna bırakın. Yöntemlerin genel karşılaştırması için alan adını hostinge bağlama: nameserver mı, A kaydı mı? yazısına bakın.

MX, SPF ve DKIM

• MX: E-postası sunucuda duran alan adlarında MX kaydı genellikle alan adının kendisini veya mail. alt alan adını gösterir; bu durumda A kaydını çevirmek e-postayı da taşır. E-postası Google Workspace veya Microsoft 365 gibi dış bir hizmette olan alan adlarında MX'e dokunmayın.
• Email Routing: cPanel'deki Email Routing (e-posta yönlendirme) ekranının "Automatically Detect Configuration" seçeneği gerçek DNS sorgusu yapmaz, sunucudaki yerel bölge dosyasına bakar. DNS'i dışarıda duran ve e-postası dış hizmette olan bir alan adında yeni sunucudaki bölge yerel MX gösteriyorsa, siteden gönderilen form e-postaları dış hizmete değil sunucudaki kutuya düşer. Bu hesaplarda Remote Mail Exchanger seçeneğini elle seçin.
• SPF: SPF kaydında eski sunucunun IP'si ip4: ile doğrudan yazılıysa yeni IP'yi ekleyin; kayıt a veya mx mekanizmasıyla kurulmuşsa DNS değişikliğini kendiliğinden izler. Kesişim döneminde iki IP'nin de kayıtta bulunması, iki sunucudan çıkan e-postaların reddedilmesini önler.
• DKIM: Tam hesap yedeği DKIM anahtar dosyalarını da içerir. DNS'i başka yerde yönetilen alan adlarında, _domainkey altında yayımlanan açık anahtarın yeni sunucudaki anahtarla uyuştuğunu cPanel'deki Email Deliverability ekranından kontrol edin; uyuşmuyorsa DNS'teki kaydı güncelleyin.

Bu kayıtların anlamı ve örnekleri için SPF, DKIM ve DMARC nedir? yazısına bakabilirsiniz.

E-posta kesişim dönemi

DNS değiştikten sonra bir süre bazı gönderen sunucular e-postayı hâlâ eski sunucuya teslim eder. Bu dönemde e-posta kaybolmaz ama iki yere bölünür: eski sunucuya düşen iletiler yeni kutuda görünmez.

• Eski hesapları geçişten sonra en az eski TTL süresi artı bir güvenlik payı boyunca e-posta kabul eder hâlde tutun.
• Kesişim dönemi bitince eski kutulara düşen iletileri IMAP senkronizasyonuyla yeni kutulara bir kez daha aktarın.
• Geçiş anında yeni sunucu kısa süre e-posta kabul edemezse bu kayıp anlamına gelmez: SMTP standardı (RFC 5321), teslim edilemeyen iletinin kuyruğa alınıp yeniden denenmesini ve vazgeçme süresinin genellikle en az 4–5 gün olmasını öngörür.
• Müşterilerin e-posta programlarında sunucu adı olarak eski sağlayıcının sunucu adı yazılıysa bu cihazlar DNS değişikliğini izlemez; yeni ayarları dalga duyurusunda bildirin. mail.alanadi.com gibi alan adına bağlı sunucu adları ise DNS ile birlikte yeni sunucuya geçer.

Taşıma dalgaları

Dalga, aynı gece DNS'i çevrilen hesap grubudur. Grupları kritikliğe göre kurun ve düşük riskliden başlayın: ilk dalgalar süreçteki hataları ucuza yakalar, en kritik hesaplar olgunlaşmış bir kılavuzla taşınır. Kritiklik dışında üç ölçüt daha işe yarar:

• DNS'in yeri: DNS'ini sizin değiştirebildiğiniz hesaplarla müşterinin kendi DNS'inde duranları ayrı gruplara koyun; ikincisi müşteriyle randevu gerektirir.
• Aynı müşterinin hesapları: Bir müşterinin birden çok hesabı varsa aynı dalgada taşıyın; müşteri tek bir geçiş yaşar.
• Kopyalama ile geçişi ayırmak: Hesapları geçiş gecesinden önce hedefe kopyalayabilirsiniz; geçiş gecesi yalnız son senkron ve DNS değişikliği yapılır. Az değişen sitelerde son senkron gerekmeyebilir; veritabanı sürekli değişen sitelerde geçiş anında son bir döküm alınıp hedefe aktarılır. Bu ayrım bakım penceresini ciddi ölçüde kısaltır.

Takvim örneği

Örnek: 30 hesaplık bir portföy varsayalım (14 düşük, 10 orta, 6 yüksek kritiklikte). Deneme taşımasında bir hesabın kopyalanması ve testi ortalama 30 dakika sürmüş olsun. Geçiş gecesi yalnız DNS değişikliği ve kontroller yapılsın, hesap başına 10–15 dakika ayrılsın. Kayıtların mevcut TTL'i 24 saat, bakım penceresi 23.00–03.00 olsun.

Bu takvim bir kalıptır; kendi deneme ölçümünüz ve müşteri kısıtlarınız (kampanya dönemi, resmî tatil, müşterinin onayladığı saat) takvimi değiştirir. Yüksek kritik hesapları haftanın en düşük trafikli gecelerine koyun ve bir gecede az sayıda tutun.

Son kontroller

Her dalganın ertesi sabahı dalgadaki her hesap için aşağıdaki listeyi işaretleyin. Sitenin kendisine dair ayrıntılı kontroller tek hesap taşıma rehberinde yer alıyor; buradaki liste bayi düzeyindeki eksikleri yakalamaya yöneliktir.

• Hesap WHM'deki List Accounts ekranında sizin bayi hesabınızın altında görünüyor mu?
• Hesaba doğru paket atanmış mı, yoksa varsayılan pakete mi düşmüş?
• Envanterdeki tüm alan adları (addon, park ve alt alan adları) hesapta var mı?
• Her alan adı yeni IP'yi gösteriyor mu? Doğrulama amaçlı TXT kayıtları ve dış hizmetlere giden CNAME kayıtları korunmuş mu?
• Email Routing ayarı ve MX kaydı alan adının e-posta kurgusuyla uyumlu mu? Dışarıdan gönderilen test iletisi doğru kutuya düşüyor mu?
• SPF ve DKIM, Email Deliverability ekranında geçerli görünüyor mu?
• SSL sertifikaları yeni sunucuda üretilmiş mi? cPanel'deki SSL/TLS Status ekranından bakın.
• PHP sürümü envanterdekiyle aynı mı; hesaba özel PHP ayarları yeniden uygulandı mı?
• Cron görevleri çalışıyor mu?
• İki adımlı doğrulama kullanan müşterilere yeniden kurulum bilgisi gitti mi?
• Fatura ve otomasyon sisteminizde (ör. WHMCS) hesaplar yeni sunucuya bağlandı mı? Bağlanmadıysa askıya alma ve kapatma komutları eski sunucuya gider.
• Hesap yeni taraftaki yedekleme düzenine dahil mi?
• Geçişten sonra eski sunucuda yeni sipariş, form kaydı veya e-posta birikmiş mi?

Geri dönüş planı

Geri dönüş planı her dalgadan önce yazılır ve üç soruyu yanıtlar: hangi durumda geri dönülür, eski sunucu ne kadar açık kalır, geri dönüşte hangi veri riske girer?

Geri dönüş kararı

Her dalga için bir karar eşiği belirleyin. Örnek: "Geçişten sonraki iki saat içinde site açılmıyorsa, ödeme veya e-posta çalışmıyorsa ve sorun bu sürede çözülemiyorsa DNS eski sunucuya çevrilir." Kararı kimin vereceğini ve müşteriye kimin haber vereceğini de önceden yazın.

Eski sunucuyu ne kadar açık tutmalı?

Alt sınırı üç süre belirler: kayıtların eski TTL süresi, nameserver değiştirdiyseniz üst bölgenin NS TTL'i (.com'da 48 saat) ve gönderen e-posta sunucularının yeniden deneme süresi (genellikle 4–5 gün). Bunların üzerine sorunların ortaya çıkması için bir gözlem süresi ekleyin. Pratik öneri: son dalgadan ve varsa nameserver değişikliğinden sonra en az 7–14 gün.

Bu süre boyunca eski hesapları silmeyin ve DNS kayıtları dışında üzerlerinde değişiklik yapmayın. Eski sağlayıcıdaki hizmetin bitiş tarihini de kontrol edin: dönem sonu bu pencerenin içine düşüyorsa hizmeti uzatmanız gerekebilir.

DNS'i geri çevirme

A kaydı yöntemiyle geçtiyseniz geri dönüş, kayıtları eski IP'ye çevirmekten ibarettir ve TTL düşük tutulduğu sürece dakikalar içinde etkili olur. Bu yüzden TTL'i, dalga kesin olarak başarılı sayılana kadar normal değerine döndürmeyin. Nameserver değiştirdiyseniz geri dönüş de üst bölgenin TTL'ini bekler; nameserver değişikliğini dalgaların sonuna bırakmanın bir nedeni de budur.

Veri kaybı penceresi

Geçiş anından geri dönüş anına kadar yeni sunucuya yazılan her şey (siparişler, form kayıtları, yüklenen dosyalar, gelen e-postalar) geri döndüğünüzde eski sunucuda yoktur. Bu pencereyi küçültmek için:

• Her hesabın geçiş saatini kaydedin; geri dönüşte bu saatten sonra oluşan kayıtları yeni sunucudan dışa aktarıp eski tarafa işleyin.
• Yüksek kritik sitelerde geri dönüş kararını ilk birkaç saat içinde verin; pencere uzadıkça geri taşınacak veri büyür.
• E-posta için ters yönde IMAP senkronizasyonu yapın: yeni kutulara düşen iletileri eski kutulara aktarın.

Netx'e taşınıyorsanız

Netx'in bayi hosting paketleri cPanel ve WHM ile sunulur ve dört kademeden oluşur: XSmall, XMedium, XLarge ve XXLarge. Paket kartlarında web sitesi sayısı sırasıyla 10, 25, 50 ve 100; SSD disk 50, 50, 150 ve 200 GB olarak yer alır. Envanterinizdeki toplam diski ve site sayısını bu değerlerle karşılaştırarak başlangıç kademesini seçebilirsiniz; bayi paketleri arasında üst kademeye yükseltme müşteri panelinden yapılabilir. Güncel fiyatlar paket sayfasındadır.

Hesap listesini ve takvimi sipariş öncesi destek ekibiyle yazılı olarak netleştirin. Bu yazışmada kaç hesabın hangi yöntemle taşınacağını, hangi adımları kimin yapacağını, taşımanın ücretli olup olmadığını, hedefteki PHP ve veritabanı sürümlerini, inode ve işlem sınırlarını ve paket kartındaki site sayısının neyi saydığını sorun. Hizmet ödeme onayından sonra otomatik açılır ve giriş bilgileri e-postayla gelir. Kullanım Koşulları'na göre hosting hizmetlerinde satın alma tarihinden itibaren 14 günlük iptal hakkı bulunduğundan, deneme taşımasını bu süre içinde yapmak kararınızı gerçek bir ölçüme dayandırır.

Sık sorulan sorular

Müşterilere taşımayı ne zaman ve nasıl duyurmalıyım?

İlk duyuruyu en az bir hafta önce, dalga tarihini içeren ikinci duyuruyu geçişten bir iki gün önce gönderin. Duyuruda geçiş saatini, beklenen etkiyi (kısa süreli e-posta gecikmesi gibi), müşterinin yapması gerekenleri ve sorun olursa kime ulaşacağını yazın.

Taşımayı kullanılmayan hesapları ayıklamak için kullanmalı mıyım?

Evet. Envanter; ödemesi durmuş, yıllardır güncellenmemiş veya yalnız birkaç e-posta için tutulan hesapları görünür kılar. Taşımayacağınız hesapların tam yedeğini alıp müşteriyle anlaştığınız süre boyunca saklayın, ardından kapatın.

Tek hesapta toplanmış müşterileri ayırmak için iyi bir zaman mı?

Olabilir, ama aynı dalgada değil. WHM'deki Convert Addon Domain to Account ekranı bir addon alan adını ayrı bir cPanel hesabına dönüştürür; cPanel belgelerine göre bunun için bayide hesapları yeniden düzenleme (rearrange-accts) yetkisi gerekir ve işlem sırasında yeni alan adının ihtiyacının üç katı boş disk önerilir. Önce hesabı olduğu gibi taşıyın, yeni sunucuda oturduktan sonra ayırın.

Kesişim döneminde iki hizmetin bedelini birden mi ödeyeceğim?

Genellikle evet; birkaç hafta boyunca eski ve yeni hizmet birlikte çalışır. Bu maliyeti bütçeye baştan koyun. Eski hizmeti geri dönüş penceresi bitmeden kapatmak, sağladığı tasarruftan daha büyük bir risk getirir.