İşe Yarayan Managed Hosting Migration Example

16 Haziran 2026 tarihinde yayımlandı

En temiz managed hosting migration example gösterişli değildir. Trafik akmaya devam eder, e-posta gelmeye devam eder, siparişler işlenmeye devam eder ve müşteri çoğunlukla yalnızca eski sunucunun gürültüsünün kesildiğini fark eder. Hedef budur. Bir geçiş, gece geç saatlerde kahramanca bir kurtarma operasyonuna dönüşüyorsa, süreç cutover'dan çok önce yanlış yürütülmüştür.

Gerçekçi bir durumu ele alalım: eskiyen bir unmanaged VPS üzerinde çalışan küçük bir e-ticaret sitesi, izleme, yedekleme ve aktif destek sunan managed VPS'e taşınıyor. Mağaza WordPress ve WooCommerce üzerinde çalışıyor; aylık yaklaşık 40.000 ziyaret, işlemsel e-posta, birkaç zamanlanmış içe aktarma ve sürprizlerden hoşlanmayan bir ödeme ağ geçidi var. Eski sunucuda karışık PHP sürümleri, manuel cron işleri var ve son restore test işleminin ne zaman yapıldığından kimse tam olarak emin değil. Bu, en güzel sunucu durumu değil ama kontrol altında.

Pratik bir managed hosting migration example

DNS'e dokunmadan veya dosyaları kopyalamadan önce ilk iş envanter çıkarmaktır. Birilerinin çalıştığını sandığı şeyi değil, gerçekte neyin çalıştığını kontrol ederiz. Bu; web sunucusu sürümü, PHP sürümü, veritabanı motoru, disk kullanımı, cron işleri, SSL sertifikaları, DNS bölgeleri, posta yönlendirmesi, güvenlik duvarı kuralları ve tüm arka plan çalışanları anlamına gelir. Bir e-ticaret yığını için ayrıca ödeme callback'lerini, SMTP davranışını, önbellek katmanlarını ve sunucu IP'sine bağlı harici hizmetler olup olmadığını da doğrularız.

Bu aşama önemlidir çünkü geçişlerdeki sıkıntıların çoğu gizli bağımlılıklardan kaynaklanır. Bir site tarayıcı tarafında basit görünebilirken sunucu arka planda sessizce görüntü işleme, stok içe aktarma, webhook işleme ve uzak bir hedefe yedek gönderme işleri yapıyor olabilir. Bunlardan biri gözden kaçarsa ana sayfa düzgün görünebilir ama iş mantığı iki saat sonra bozulabilir.

Envanter tamamlandığında yeni managed ortam, eski hataları körü körüne klonlamak yerine uygulamanın gereksinimlerine göre kurulur. Eski sunucu, kimse dokunmak istemediği için güncel olmayan bir PHP dalında çalışıyorsa, taşınmadan önce geçici uyumluluğu koruyup korumamaya ya da uygulamayı düzeltmeye karar vermenin zamanı budur. Managed hosting burada yardımcı olur çünkü yalnızca işlem gücü kiralamıyorsunuz. Aynı zamanda size sakince bu sürüm farkının bir risk olduğunu ve buradan geçmenin en güvenli yolunun ne olduğunu söyleyecek birini de edinmiş oluyorsunuz.

Yeni sunucuda web yığınını provision eder, SSH erişimini sıkılaştırır, temel güvenlik duvarı kurallarını uygular, yedeklemeleri etkinleştirir, izlemeyi yapılandırır ve control panel hazırlarız. Bir staging hostname varsa, genel geçişten önce doğrulama için onu kullanırız. Bu, baskıyı azaltır. İnsanlar DNS zaten değişirken daha kötü kararlar verir.

Cutover'dan önce neler olur

Veri taşıma genellikle dosyaların tam bir kopyası ve yeni sunucuya içe aktarılan bir veritabanı dışa aktarımıyla başlar. Bu ilk senkronizasyon son senkronizasyon değildir. Bu bir provadır. Uygulamanın yeni yığın altında nasıl davrandığını test edebilmek için sitenin hedefte açılmasını isteriz.

Bu noktada, iyi bir managed hosting migration example umutla yapılan tıklamalar değil, ayrıntılı kontroller içerir. Sayfa oluşturmayı, yönetici girişini, ödeme akışını, dosya izinlerini, medya yüklenmesini, zamanlanmış görevleri, e-posta gönderimini, yönlendirme kurallarını ve SSL geçerliliğini doğrularız. Test ederken log'ları da inceleriz. Log'lar şu anda aynı hikâyeyi anlatıyordur ya da anlatmıyordur. Yeni host üzerinde PHP uyarıları aniden çoğalmaya başlarsa, kullanıcılar boş bir sepet sayfası görmeden önce bunları görmek daha iyidir.

DNS hazırlığı da erken başlar. Mümkünse TTL değerleri geçişten önce, genellikle cutover'dan 24 ila 48 saat önce düşürülmelidir. Bu, her yerde anında yayılımı garanti etmez ama bekleme odasını kısaltır. DNS üçüncü bir tarafça yönetiliyorsa, birinin geçiş gününden önce erişimi doğrulaması gerekir. Teknik bir planın “alan adı eski ajans hesabında ve onlar tatilde” yüzünden ne kadar sık geciktiği şaşırtıcıdır.

Mağazalar, üyelik siteleri ve SaaS uygulamaları için ayrıca nihai cutover'ın kısa bir içerik dondurma gerektirip gerektirmediğine de karar veririz. Statik tanıtım siteleri neredeyse hiçbir operasyonel seremoni olmadan taşınabilir. Dinamik platformlar farklıdır. Kullanıcılar taşıma sırasında sipariş verebiliyor veya kayıt oluşturabiliyorsa, eski ve yeni veritabanları arasında bölünmüş veriyi önlemek için bir plana ihtiyacımız vardır.

Yaygın cevap, son bir senkronizasyon penceresidir. Geçişi trafiğin daha düşük olduğu saatlere planlarız, gerekirse uygulamayı kısa bir süreliğine bakım moduna alırız, son veritabanı dump'ını ve dosya senkronizasyonunu çalıştırırız, taze veriyi yeni sunucuya içe aktarırız ve ardından DNS'i değiştiririz. Gösterişli değildir ama işe yarar.

Cutover'ın kendisi

İşte bu managed hosting migration example için gerçek sıralama.

Eski site yayında kalırken yeni sunucu zaten özel olarak test edilmiştir. Planlanan zamanda sipariş alımını kısa süreliğine duraklatır, son veritabanı dışa aktarımını çalıştırır, değişen dosyaları senkronize eder, yeni uygulama durumunu doğrular ve alan adını yeni sunucuya yönlendirecek şekilde DNS kayıtlarını güncelleriz. Posta başka bir yerde barındırılıyorsa MX kayıtlarını olduğu gibi bırakırız. Posta aynı sunucuda yerelse bunu açıkça ele alırız, çünkü e-posta geçişleri, normalde makul insanların hafta sonunu kaybettiği yerdir.

DNS değişikliklerinden sonra birden fazla ağdan test yapar ve yeni endpoint üzerinde header'ları, SSL'i ve uygulama davranışını doğrularız. Yayılım sırasında bazı kullanıcılar bir süre daha eski IP'ye ulaşacağından hem eski hem de yeni sunucuları izleriz. Kuruluma bağlı olarak, veritabanı dondurulduktan sonra eski örneği bir bakım sayfası sunacak veya trafiği yönlendirecek şekilde çalışır durumda tutabiliriz; bunun tek amacı bayat yazmaları önlemektir.

Managed support tam da burada değerini gösterir. Birisi taşıma sırasında kaynak kullanımını, hata oranlarını, disk G/Ç'sini ve servis durumunu izliyordur. PHP-FPM worker'larının ayarlanması gerekiyorsa, MySQL buffer'ları fazla sıkıysa, bir eklenti yeni sürüm altında uyarılar üretmeye başlıyorsa, bu düzeltmeler sistem gözlem altındayken yapılır; bir müşteri ekran görüntüsü ve son derece haklı bir rahatsızlık düzeyiyle ticket açtıktan sonra değil.

Gerçek geçişlerde önemli olan ödünleşmeler

Her geçiş anında yazılım yükseltmeleri içermemelidir. Bazen en güvenli hareket önce taşıyıp stabilize etmek, sonra optimize etmektir. İşletmenin yarın büyük bir pazarlama kampanyası varsa, altyapı geçişini CMS'in büyük sürüm sıçramasıyla birleştirmenin zamanı bu değildir. Kararlılık kazanır.

Öte yandan, güvensiz veya kötü yapılandırılmış bir yığını değiştirmeden kopyalamak aynı sorunları daha yeni donanım üzerinde de koruyabilir. Bu; iş zamanlamasına, uygulamanın yaşına ve ne kadar test süresi bulunduğuna bağlıdır. Bir managed sağlayıcı burada dürüst olmalıdır. Tehlikeli bir bağımlılığı temizlemek için geçişi birkaç gün ertelemenin daha doğru karar olduğu durumlar vardır.

Bir diğer ödünleşme, görünür sıfır kesinti ile düşük riskli yürütme arasındadır. Birçok ekip kesinlikle hiç kesinti istemez, ancak bu, uygulamanın gerçekten ihtiyaç duyduğundan daha karmaşık çoğaltma veya yük dengeli cutover kalıpları gerektirebilir. Birçok küçük ve orta ölçekli işletme için dikkatle planlanmış beş dakikalık bir bakım penceresi, kırılgan bir mükemmellik girişiminden daha güvenlidir. Aşırı zeki ama yeterince test edilmemiş bir çözüm yerine sakin bir yaklaşım daha iyidir.

Taşıma sonrası neler kontrol edilir

Trafik tutarlı biçimde yeni sunucuya inmeye başladığında iş bitmiş olmaz. Önümüzdeki 24 ila 72 saat boyunca zamanlanmış işleri, yedekleme tamamlanmalarını, giden e-posta itibarını, DNS yayılımını, uptime kontrollerini ve uygulama log'larını doğrularız. Canlı trafik altında önbellek ayarlarının düzeltilmesi gerekebilir. Veritabanı ayarlaması, gerçek iş yükü kalıpları görünür olduğunda çoğu zaman iyileşir.

Bu geçiş sonrası izleme dönemi, yeni managed ortamın karşılığını vermeye başladığı yerdir. İzleme; CPU sıçramaları, bellek baskısı, başarısız servisler ve olağandışı yanıt süreleri için uyarı vermelidir. Yedeklemeler zaten zamanında çalışıyor olmalı ve restore mantığı net olmalıdır. Bir geçiş, DNS kaydı değiştiğinde değil, taşıma sonrasında hizmet kararlı olduğunda başarılıdır.

E-ticaret örneği için ayrıca sipariş akışını, ödeme onaylarını, kargo entegrasyonlarını, yönetici bildirimlerini ve search console davranışını da doğrularız. Küçük gözden kaçmalar burada yaşar. Hâlâ eski IP'ye bağlı bir webhook endpoint'i, yeni bir kullanıcı hesabı nedeniyle değişmiş bir cron yolu, harici bir API'yi engelleyen bir güvenlik duvarı kuralı. Bunların hiçbiri zor değildir ama fark edilmezse maliyetli olurlar.

kodu.cloud gibi bir sağlayıcı bu tür bir taşıma için çok uygundur çünkü managed hosting dekoratif bir etiket olarak ele alınmaz. Gerçek değer operasyonel kapsamdır: hedefi doğru hazırlamak, geçişi izlemek, yedeklemeleri ve izlemeyi aktif tutmak ve ilk tuhaf davranış ortaya çıktığında cutover sonrasında da erişilebilir kalmak.

Bu yüzden bir managed hosting migration example arıyorsanız, havai fişek aramayın. Uygulamanın envanterinin çıkarıldığı, yeni ortamın bilinçli şekilde kurulduğu, DNS'in dikkatle ele alındığı, son senkronizasyonun kontrollü yapıldığı ve geçiş sonrası kontrollerin ciddiye alındığı bir sürece bakın. Hizmet yeniden böyle sakinleşir. İyi bir geçiş neredeyse sıkıcı hissettirir ve üretim sistemleri için bu çok iyi bir haberdir.

Andres Saar Müşteri Hizmetleri Mühendisi