WooCommerce Sitesi Sipariş Kaybı Yaşamadan Nasıl Taşınır?

WooCommerce mağazasını sipariş kaybetmeden taşımanın yolu, iki veritabanını sonradan birleştirmeye çalışmak değil, kısa bir dondurma penceresinde eski sunucudaki veritabanının tamamını yeni sunucuya aktarmaktır. Önce entegrasyonların envanterini çıkarır, siteyi yeni sunucuda dış sistemlerden yalıtılmış bir kopyada prova eder ve DNS TTL değerini düşürürsünüz. Geçiş anında eski sitede sipariş almayı durdurur, yarım kalan ödemelerin sonuçlanmasını bekler, tam veritabanı dökümünü yeni sunucuya yükler ve DNS'i çevirirsiniz. Eski sunucu kapalı vitrinle bir süre açık kalır, oraya düşen her sipariş ödeme kuruluşunun işlem listesiyle karşılaştırılıp elle uzlaştırılır.

WooCommerce taşımasını farklı kılan ne?

Bir kurumsal sitenin içeriği taşıma süresince pek değişmez. Dosyaları kopyalar, veritabanını aktarır, DNS'i çevirirsiniz. Genel adımları WordPress sitesini başka hostinge taşıma rehberinde anlattık. Mağazada ise veritabanı her dakika değişir. Yeni siparişler, düşen stoklar, açılan müşteri hesapları, sipariş notları, ödeme kuruluşundan gelen durum güncellemeleri, kuyrukta bekleyen arka plan işleri. Veritabanını kopyaladığınız andan itibaren eski ve yeni kopya birbirinden ayrışmaya başlar.

Bu ayrışmayı sonradan birleştirmek pratikte mümkün değil. Sipariş numaraları, sipariş kalemleri, müşteri kimlikleri ve stok hareketleri birbirine numarayla bağlıdır. İki tarafta aynı numarayla oluşmuş iki farklı sipariş, tablo tablo kopyalanarak düzeltilemez. Üstelik HPOS (yüksek performanslı sipariş depolama) kullanan bir mağazada siparişler wc_orders ve ilgili tablolarda durur. Yalnız yazıları ve meta verisini taşıyan bir araç siparişleri hiç götürmeyebilir. Bu yüzden kuralımız basit: tablo seçmeyin, tam döküm alın ve geçiş anında yalnız bir veritabanı yaşasın.

Geçişten önce envanter çıkarın

Mağaza yalnız ziyaretçiyle konuşmaz. Ödeme kuruluşu sitenize bildirim gönderir, ERP sipariş çeker, pazaryeri stok ister, siteniz kargo firmasına etiket isteği atar. Bunların her biri ya alan adınıza ya da sunucunuzun IP adresine bağlıdır. Geçişte kopan bağlantı çoğu zaman bu listede unutulan bir kalemdir.

E-posta aynı hosting hesabındaysa site ile birlikte taşınacak demektir. MX, SPF ve DKIM kayıtlarının yeni duruma göre ayarlanması ayrı bir iş. Hosting değişince e-postanın neden bozulduğunu kontrol listesiyle önceden gözden geçirin. Eski ve yeni sunucuda paneller farklıysa, örneğin cPanel'den Plesk'e geçiyorsanız, cPanel'den Plesk'e dosya, veritabanı ve e-posta taşıma adımları dizin ve yapılandırma farklarını kapsar.

Hazırlık kopyasında prova

Yeni sunucuya mağazanın bir kopyasını kurun ve bilgisayarınızın hosts dosyasıyla gerçek alan adı üzerinden açın. Kopyayı geçici bir alt alan adında kurarsanız adres değiştirme (search-replace) gerekir. Hosts dosyasıyla gerçek adı kullanmak, son aktarımda hiçbir şeyi değiştirmeden aynı dökümü yüklemenizi sağlar. Bedeli şu: kopya gerçek alan adıyla çalıştığı için dış sistemlerle gerçekten konuşabilir. İlk açılıştan önce şunları kapatın:

• Müşterilere giden e-postalar. Kopyadaki bir test, gerçek müşteriye "siparişiniz iptal edildi" yazabilir.
• Giden web kancaları ve ERP, pazaryeri, muhasebe senkronları. Aksi hâlde test siparişleri canlı sistemlere düşer.
• Ödeme yöntemlerinin canlı kipi. Test (sandbox) anahtarlarına geçin.
• Sunucu cron'u ve Action Scheduler kuyruğu. Kopyada bekleyen eylemler, canlıda zaten yapılmış işleri bir kez daha yapabilir.

Sonra provayı baştan sona yapın: sepete ekleme, kargo hesabı, kupon, test kipinde ödeme, teşekkür sayfası, yönetim panelindeki sipariş kaydı. Aynı provada eski sunucudan döküm almanın ve yeni sunucuya yüklemenin kaç dakika sürdüğünü ölçün. Dondurma pencerenizin uzunluğu bu süre artı güvenlik payıdır. Provada yaptığınız ayar değişikliklerini not alın, çünkü son aktarım bu kopyanın veritabanının üzerine yazılacak ve not almadığınız her ayar kaybolacak.

Zamanlamayı da buradan kurun. Mağaza büyüyüp sunucuya geçiyorsa VDS'e geçişin doğru zamanını gösteren ölçülebilir sinyalleri kampanya takviminizle birlikte değerlendirin. Netx'te VDS aktivasyonu siparişten sonra en geç 24 saat içinde yapılır, öncesinde güvenlik doğrulaması için sizinle iletişime geçilir. Prova için sunucuyu taşıma gününden günler önce hazır edin. DNS kayıtlarının TTL değerini en az 24–48 saat önceden düşürmeyi de unutmayın.

Dondurma penceresi: sipariş almayı durdurmak

Geçişin kalbi, eski sitede yeni sipariş oluşmasını durdurduğunuz kısa aralıktır. En düşük trafikli saati seçin ve sırayı önceden yazın.

1. Eski sitede sipariş girişini kapatın (seçenekler aşağıda).
2. Yarım kalan ödemelerin sonuçlanmasını bekleyin.
3. Eski sunucuda ERP, pazaryeri senkronlarını ve cron'u durdurun ki döküm alınırken veri değişmesin.
4. Tam veritabanı dökümünü alın, son değişen yükleme dosyalarını aktarın.
5. Dökümü yeni sunucuya yükleyin ve sayıları karşılaştırın.
6. DNS'i yeni sunucuya çevirin, yeni sunucuda ödemeyi canlıya, entegrasyonları ve cron'u açın.

Yalnız ödemeyi kapatmak mı, bakım modu mu?

İki yaklaşım var ve ikisinin de bedeli farklı. Tüm siteyi bakım moduna almak en güvenlisidir ama ziyaretçi katalogda da gezemez. Daha yumuşak yol yalnız mağaza tarafını kapatmaktır. WooCommerce 9.1 ile gelen Çok yakında modu, WooCommerce → Ayarlar → Site görünürlüğü ekranından açılır. Yalnızca mağaza sayfalarında uygula seçeneğiyle mağaza, sepet ve ödeme sayfaları kapanırken sitenin geri kalanı açık kalır. Bu modda yetkili kullanıcılar ve özel bağlantıya sahip olanlar mağazayı görmeye devam eder, bu yüzden kontrolü oturum açmamış bir tarayıcıdan yapın. Ödeme kuruluşunun bildirimlerinin bu moddan etkilenip etkilenmediği WooCommerce'in Çok yakında modu belgesinde yazmıyor. Bu yüzden bildirimlerin hâlâ işlendiğini provada sınayın ya da yarım kalan ödemeler sonuçlanana kadar modu açmayı erteleyin.

Ödeme yöntemlerini tek tek devre dışı bırakmak da sipariş girişini durdurur, ama müşteri ödeme sayfasına kadar gelip "kullanılabilir ödeme yöntemi yok" uyarısıyla karşılaşır. Kısa bir pencere için bu kabul edilebilir, uzun bir pencere için kötü bir deneyimdir.

Yarım kalan ödemeleri beklemek

Sipariş girişini kapattığınız anda ödeme sayfasında 3D Secure doğrulaması yapan müşteriler olabilir. Siparişleri "Ödeme bekliyor" durumunda oluşmuştur ve ödeme kuruluşunun bildirimiyle "Hazırlanıyor"a geçecektir. Bu bildirim döküm alındıktan sonra gelirse eski veritabanına yazılır ve yeni sunucuda o sipariş ödenmemiş görünür. Bu yüzden son 30–60 dakikada oluşmuş "Ödeme bekliyor" siparişlerine bakın, ödeme kuruluşunun panelinde sonuçlarını izleyin ve hepsi sonuçlanınca döküme geçin. WooCommerce → Ayarlar → Ürünler → Stok altındaki Stoğu tut (dakika) değeri, ödenmemiş siparişlerin ne kadar süre sonra iptal edileceğini belirler. Bekleme sürenizi kabaca bu değere göre ayarlayabilirsiniz.

Son aktarım: birleştirme değil, tam döküm

Dondurma başladıktan sonra eski sunucudan veritabanının tamamının dökümünü alın. Komut satırı erişiminiz varsa:

mysqldump --single-transaction --no-tablespaces \
  -u kullanici -p magaza_db > son-dokum.sql

--single-transaction, InnoDB tablolarının tutarlı bir anlık görüntüsünü tabloları kilitlemeden alır. Seçeneklerin tamamı mysqldump belgesinde yer alıyor. --no-tablespaces ise paylaşımlı hostingte sık görülen PROCESS yetkisi hatasını önler. Döküm varsayılan olarak her tablodan önce DROP TABLE satırı içerir, yani yeni sunucuda yüklediğinizde hazırlık kopyasının tabloları silinip yerine eski sunucudakiler gelir:

mysql -u kullanici -p magaza_db < son-dokum.sql

Komut satırı yoksa phpMyAdmin'in dışa aktarma ekranında tüm tabloları seçerek aynı işi yapabilirsiniz. Büyük veritabanlarında tarayıcı zaman aşımına düşebilir, bunu da provada görürsünüz.

Yükleme bitince iki tarafta aynı sorguyu çalıştırıp sonucu karşılaştırın. HPOS kullanan mağazada son sipariş numarası ve toplam sipariş sayısı:

SELECT MAX(id) AS son_siparis, COUNT(*) AS adet
FROM wp_wc_orders
WHERE type = 'shop_order';

Eski depolamayı kullanıyorsanız aynı bilgiyi wp_posts tablosunda post_type = 'shop_order' koşuluyla alırsınız. Hangisini kullandığınızı WooCommerce → Ayarlar → Gelişmiş → Özellikler ekranındaki Sipariş verisi depolama seçeneği gösterir. İki tarafın sonuçları aynı değilse DNS'i çevirmeyin.

Yükleme klasörü veritabanının dışındadır. Ürün görsellerinin büyük kısmını provada taşıdıysanız dondurmada yalnız son eklenen dosyaları, genellikle içinde bulunulan ayın klasörünü, yeniden aktarmanız yeterli.

DNS'i çevirin, eski sunucuyu kapalı vitrinde tutun

DNS kaydını yeni sunucuya çevirdiğiniz anda ziyaretçilerin çoğu yeni siteye gelmeye başlar, ama hepsi değil. TTL süresi dolmamış çözümleyiciler bir süre eski IP'yi verir. Ödeme kuruluşları ve entegrasyon sunucuları da kendi DNS önbelleklerini kullanır. Bu yüzden eski sunucu bir süre daha trafik alır ve bu trafiğin sipariş üretmemesi gerekir.

Eski sitedeki mağaza kapalı kalsın: Çok yakında modu ya da bakım sayfası geçiş sonrası da açık dursun. Eski sunucudaki cron görevlerini silin, WordPress tarafında DISABLE_WP_CRON tanımlayın, entegrasyon eklentilerini durdurun. Sık atlanan nokta budur. Eski sunucudaki bir pazaryeri senkronu, eski veritabanındaki bayat stok bilgisini saatlerce pazaryerine göndermeye devam edebilir. Eski sunucudaki Action Scheduler kuyruğu da aynı riski taşır. Yeni sunucuda ise dökümle birlikte gelen bekleyen eylemlerin gerçekten işlendiğini izleyin. Kuyruk ilerlemiyorsa Action Scheduler'da işlemlerin neden biriktiğine bakın.

Geçişten sonraki ilk saatler

• Gerçek bir küçük siparişle ödeme akışını baştan sona deneyin, ödeme bildiriminin yeni sunucuya ulaştığını sipariş notlarından ve eklenti günlüğünden doğrulayın, sonra iade edin.
• Sipariş e-postalarının hem size hem müşteriye geldiğini kontrol edin. Gelmiyorsa sipariş e-postalarının hangi halkada koptuğunu adım adım ayırın.
• Web kancalarının teslim durumunu ve ERP'ye yeni siparişlerin düştüğünü kontrol edin.
• Stok sayılarını birkaç üründe pazaryeri ve ERP ile karşılaştırın.
• SSL sertifikasını, cron görevlerini ve yedek planını yeni sunucuda doğrulayın.
• Eski sunucunun erişim günlüğünde trafiğin azaldığını izleyin.

Eski sunucuya düşen siparişleri bulun ve uzlaştırın

Her şeyi doğru yapsanız da eski sunucuya geç gelen bir ödeme bildirimi ya da kapatmayı unuttuğunuz bir giriş yolu yüzünden orada sipariş oluşmuş olabilir. Bunları bulmak için eski veritabanında, dondurmanın başladığı andan sonra oluşan ya da değişen siparişleri sorgulayın. Zamanlar GMT (UTC) tutulur. Türkiye saatinden üç saat çıkarın:

SELECT id, status, total_amount, payment_method,
       transaction_id, date_created_gmt, date_updated_gmt
FROM wp_wc_orders
WHERE type = 'shop_order'
  AND (date_created_gmt >= '2026-11-02 00:00:00'
       OR date_updated_gmt >= '2026-11-02 00:00:00')
ORDER BY id;

Tarih örnektir, kendi dondurma saatinizi yazın. Eski depolamada aynı sorguyu wp_posts tablosunda post_date_gmt ve post_modified_gmt sütunlarıyla kurarsınız. Eski sunucunun erişim günlüğünde ödeme eklentinizin bildirim adresine (çoğu eklentide wc-api içerir) ve wc-ajax=checkout isteklerine de bakın.

En güvenilir kaynak ise ödeme kuruluşunun işlem listesidir. Dondurmanın başladığı andan itibaren yapılan tüm başarılı işlemleri dışa aktarın ve her birinin yeni veritabanında karşılığı olan bir sipariş olup olmadığını kontrol edin. Karşılığı olmayan her işlem için yeni sunucuda WooCommerce → Siparişler → Yeni sipariş ekle ile siparişi elle oluşturun, ödeme kuruluşundaki işlem numarasını nota yazın, stoğu düzeltin ve müşteriyi bilgilendirin. Ürünü gönderemeyecekseniz ödeme kuruluşu panelinden iade edin. Bu satırları veritabanından kopyalayarak "birleştirmeye" çalışmayın. Numaralar yeni taraftaki siparişlerle çakışır.

Geri dönüş planı

Geri dönüşün ilk şartı, eski sunucunun ve eski veritabanının geçişten sonra dokunulmadan durmasıdır. Kapatmak için acele etmeyin. İkinci şart, geri dönüş kararını ne zamana kadar vereceğinizi önceden yazmaktır. Örneğin ödeme akışı ilk iki saat içinde düzeltilemezse geri dönülür. Bu süre geçtikten sonra yeni sunucuda oluşan siparişler geri dönüşü de bir taşımaya çevirir: aynı dondurma, aynı tam döküm, bu sefer ters yönde.

Taşımadan hemen önce kendi tam yedeğinizi alın ve sunucu dışında saklayın. Sağlayıcının düzenli yedeği bu anı kapsamayabilir. Netx WordPress hosting paketlerinde yedek haftalık alınır, günlük yedek ücretli ek hizmettir. VDS'te yedekleme fiyata dahil değildir, siparişte ek yedek alanı seçilebilir. Aldığınız yedeğin gerçekten açıldığını yedeğin geri yükleme tatbikatıyla önceden sınamak, kriz anında sürprizleri azaltır.

Sık sorulan sorular

Taşıma eklentisiyle sipariş kaybetmeden taşıyabilir miyim?

Eklenti, veritabanının tamamını aldığı ve dondurma penceresi içinde çalıştırıldığı sürece aynı işi görür. Sorun aracın kendisinde değil, dökümün alındığı anla sitenin kapandığı an arasındaki boşluktadır. Eklentiyle provada aldığınız kopyayı canlıya geçirmek, provadan sonra gelen siparişleri kaybetmek demektir.

Sipariş numaraları değişir mi?

Tam dökümle taşındığında değişmez, yeni siparişler kaldığı yerden devam eder. Elle uzlaştırmada oluşturduğunuz siparişler ise yeni numara alır. Müşteriye bunu bildirin ve eski numarayı sipariş notuna yazın.

Dondurma penceresi ne kadar sürmeli?

Provada ölçtüğünüz döküm ve yükleme süresine, yarım kalan ödemeleri bekleme süresini ve kontrol sorgularını ekleyin. Küçük bir veritabanında bu birkaç dakikadır, büyük bir mağazada saatlere çıkabilir. Kendi ölçümünüz dışında bir sayıya güvenmeyin.