Web Sitesi Yenilemede Veri Nasıl Korunur? Kayıpsız Veri Aktarımı Rehberi

Web sitesi yenilemede veri aktarımı, eski sistemdeki müşteri hesaplarını, siparişleri, form kayıtlarını, e-postaları ve analitik geçmişini yeni sisteme eksiksiz taşıma işidir. Bu yazıda tasarım ya da içerik tarafını değil, işin görünmeyen yüzünü anlatıyorum: veri tabanı, yedek, test aktarımı ve doğrulama. 2012'den beri yaptığım yenileme projelerinde en pahalı hataları hep bu katmanda gördüm.

Web sitesi yenilemede veri aktarımı nedir?

Veri aktarımı, eski sitenin veri tabanında ve bağlı servislerinde duran kayıtları yeni sistemin yapısına uygun biçimde taşıma, eşleştirme ve doğrulama sürecidir. Kullanıcı hesapları, şifre özetleri, siparişler, form başvuruları, e-posta kutuları ve analitik geçmişi bu kapsama girer. Amaç tek bir kaydı bile kaybetmeden geçiş yapmaktır.

Burada önemli bir ayrım yapıyorum. Sayfa metinlerini, görselleri ve URL yapısını taşımak içerik taşımasıdır; SEO tarafını ise yenileme sırasında SEO koruma rehberinde ayrıca anlattım. Bu yazının konusu ise işletmenin hafızasıdır. Yani kim ne satın aldı, kim hangi formu doldurdu, hangi müşteri hangi şifreyle giriyor.

Kısacası, tasarımı değiştirebilirsiniz ama işletmenin geçmişini değiştiremezsiniz; o geçmişi olduğu gibi yeni eve taşımanız gerekir.

Yenileme sırasında veri neden kaybolur?

Veri çoğu zaman kötü niyetle değil, dikkatsizlikle kaybolur. Sahada en sık gördüğüm senaryo şudur: ekip yeni siteyi bir test sunucusunda haftalarca hazırlar, bu sırada eski site sipariş ve form almaya devam eder. Yayın günü yalnızca ilk kopyayı taşırsanız, aradaki haftaların kayıtları boşlukta kalır.

Ayrıca her platformun veri modeli farklıdır. Örneğin eski sistemde tek alanda duran "ad soyad" bilgisi yeni sistemde iki ayrı alan ister. Eşleştirmeyi elle yapmazsanız isimler yarım kalır ya da boş kalır. Bunun yanında karakter seti sorunlarıyla da sık karşılaşırsınız; Türkçe karakterler soru işaretine dönüşür.

• Test kopyası ile yayın günü arasında biriken yeni kayıtlar.
• Alan eşleştirme hataları ve kesilen metinler.
• Karakter seti uyumsuzluğu (latin1 ile utf8mb4 karışması).
• Eski hosting hesabını erken kapatmak.
• Kimsenin sahiplenmediği üçüncü taraf servislerdeki veriler.

Dolayısıyla veri kaybı teknik bir kazadan çok, plansızlığın sonucudur.

Bir de sahiplik sorunu var. Tasarımcı veriyi yazılımcının taşıyacağını düşünür, yazılımcı ise müşterinin kendi yedeğini aldığını varsayar. Herkes bir başkasına güvendiğinde, kimse son kontrolü yapmaz. Bu yüzden projenin ilk toplantısında veri aktarımının tek bir sorumlusunu isimle belirliyorum.

Hangi verileri taşımalısınız ve envanteri nasıl çıkarırsınız?

İlk iş, sitenin tuttuğu bütün veri türlerinin listesini çıkarmaktır. Burada sayfa listesinden söz etmiyorum; veri tabanındaki tabloları ve dış servisleri kastediyorum. Ben bunu genelde bir tabloda topluyorum ve her satıra bir sahip atıyorum.

Böylece hiçbir veri türü "herkes biliyor sanıyordu" kategorisinde kalmaz. Tabloya bir de "yeni sistemde karşılığı var mı" sütunu eklemenizi öneririm.

Veri aktarımı öncesi yedeği nasıl almalısınız?

Yedek, veri aktarımının sigortasıdır; onu aktarıma başlamadan önce almanız ve test etmeniz gerekir. Ben tek bir yedeğe asla güvenmiyorum. Veri tabanının tam dökümünü, dosya sisteminin arşivini ve e-posta kutularının kopyasını ayrı ayrı alıyorum.

1. Veri tabanının tam dökümünü alın (yapı ve veri birlikte).
2. Dosya sistemini, özellikle yüklenen dosyalar klasörünü arşivleyin.
3. Yedeği sunucudan indirin; aynı sunucuda duran yedek, sunucu çökerse işe yaramaz.
4. İndirdiğiniz dosyanın bütünlüğünü sağlama toplamıyla kontrol edin.
5. Yedeği boş bir ortama geri yükleyip çalışıp çalışmadığını deneyin.

Son madde çoğu ekibin atladığı adımdır. Ancak geri yüklemeyi hiç denemediğiniz bir yedek, gerçekte yedek değil bir umuttur. Ayrıca yedeği işiniz bitince sunucuda bırakmayın; herkese açık bir klasörde unutulan veri tabanı dökümü ciddi bir sızıntı kaynağıdır.

Kullanıcı hesaplarını ve şifreleri nasıl taşırsınız?

Kullanıcı hesaplarında en kritik konu şifrelerdir. Düzgün bir sistem şifreyi açık metin olarak saklamaz, yalnızca şifre özetini (hash) tutar. Bu yüzden şifreyi "okuyup" yeni sisteme yazamazsınız; özeti olduğu gibi taşımanız ve yeni sistemin o özeti doğrulayabilmesi gerekir.

Burada platform değişikliği önemli bir engel çıkarır. Örneğin WordPress, WordPress çekirdek ekibinin duyurusuna göre 6.8 sürümüyle phpass yerine bcrypt tabanlı bir yönteme geçti. Yani aynı platformun iki sürümü arasında bile özet biçimi değişebiliyor. Farklı bir platforma geçiyorsanız, yeni sistemin eski özet biçimini tanıması için bir uyumluluk katmanı yazmanız gerekir.

Bu katman kurulamıyorsa ikinci yol, kullanıcıları ilk girişte şifre yenilemeye yönlendirmektir. Fakat bunu kullanıcıya önceden, net bir e-postayla duyurmalısınız. Aksi halde müşteri hizmetleri hattınız yayın haftasında tıkanır.

Sipariş ve fatura geçmişini kaybetmemek için ne yapmalı?

Sipariş verisi tek bir tablo değildir; sipariş başlığı, kalemler, ödeme kaydı, kargo bilgisi ve müşteri kaydı birbirine kimlik numaralarıyla bağlıdır. Bu bağları koparırsanız, sipariş listesi dolu durur ama hiçbir sipariş doğru müşteriye ait olmaz.

Bu nedenle ilk kuralım şudur: eski kimlik numaralarını mümkünse koruyun. Koruyamıyorsanız, eski ve yeni kimlikleri eşleyen bir tablo tutun ve bunu aktarım bitince silmeyin. Muhasebe, iade ya da e-fatura tarafında aylar sonra bir kayıt aradığınızda bu eşleme tablosu hayat kurtarır.

Ayrıca sipariş numarası serisine dikkat edin. Yeni sistem sipariş numaralarını 1'den başlatırsa, eski ve yeni siparişler aynı numarayı taşır ve müşteri iletişimi karışır. Yeni serinin eski en yüksek numaranın üstünden başlamasını sağlayın. E-ticaret projelerinde bu ayarları e-ticaret danışmanlığı kapsamında en baştan planlıyorum.

Form kayıtlarını ve potansiyel müşteri verisini nasıl korursunuz?

Form kayıtları genelde en çok ihmal edilen veridir. İletişim, teklif ya da randevu formları çoğu sitede bir eklentinin kendi tablosunda durur. Eklenti yeni sitede yoksa, o tablo da yeni siteye geçmez ve yılların başvuru arşivi sessizce kaybolur.

Benim yöntemim, eski formların bütün kayıtlarını önce CSV olarak dışa aktarmak, ardından bunları CRM'e ya da yeni sistemin form tablosuna içe aktarmaktır. Böylece kayıtlar tek bir platforma bağlı kalmaz. Ek olarak yeni formun alan adlarını eski formla eşleştiriyorum; "telefon" ile "tel" gibi küçük farklar içe aktarmada boş sütunlara yol açıyor.

Yayın günü de ayrı bir risktir. Eski form hâlâ çalışırken yeni form da canlıya çıkarsa, bir süre iki farklı yere başvuru düşebilir. Bu yüzden eski formu yayın anında kapatın ve o saatten sonra gelen kayıtları ayrıca kontrol edin. Yeni formun tasarımı için randevu, teklif ve demo formu tasarımı yazısına da bakabilirsiniz.

E-posta hesapları taşınırken nelere dikkat etmeli?

E-posta, site yenilemenin en sinsi kaybıdır. Pek çok küçük işletmede kurumsal e-posta aynı hosting hesabında durur. Yeni site başka bir sunucuya taşınıp eski hosting kapatıldığında, yıllarca biriken yazışmalar da onunla birlikte gider.

• Önce e-postanın nerede barındığını netleştirin: hosting mi, ayrı bir servis mi.
• Kutuları IMAP ile yeni sunucuya kopyalayın, yalnızca yeni gelenleri değil geçmişi de alın.
• MX, SPF, DKIM ve DMARC kayıtlarını değiştirmeden önce mevcut değerleri not edin.
• DNS değişikliğinden sonra birkaç gün eski kutuyu da kontrol edin.

DNS kayıtlarının mevcut durumunu DNS sorgulama aracı ile hızlıca görebilirsiniz. Üstelik e-postayı siteden ayırmak, bir sonraki yenilemede aynı riski baştan ortadan kaldırır; bunu kurumsal e-posta altyapısı yazısında ayrıntılı anlattım.

Analitik geçmişini yeni siteye nasıl taşırsınız?

Analitik veriyi teknik anlamda taşımazsınız; doğru kurgularsanız zaten yerinde kalır. Kural basittir: yeni site için yeni bir GA4 mülkü açmayın, mevcut mülkü ve ölçüm kimliğini kullanmaya devam edin. Böylece yenileme öncesi ve sonrası aynı raporda yan yana durur.

Ancak GA4'ün saklama süresine dikkat edin. Google Analytics yardım sayfasına göre standart mülklerde olay düzeyindeki veri varsayılan olarak 2 ay kalır ve bu süreyi en fazla 14 aya çıkarabilirsiniz. Bu ayar keşif raporlarını etkiler. Uzun vadeli kıyaslama istiyorsanız, GA4 BigQuery dışa aktarımını yenilemeden önce açmanızı öneririm.

Dönüşüm olaylarını da unutmayın. Yeni sitede form ve satın alma olaylarının adları değişirse, reklam hesabındaki dönüşüm hedefleri boşa düşer. Olay adlarını eski siteyle birebir aynı tutun.

Search Console ve reklam hesaplarındaki veriler ne olur?

Search Console verisi alan adına bağlıdır; alan adı aynı kalıyorsa geçmiş performans verisi yerinde durur. Alan adı değişiyorsa, eski ve yeni mülkü birlikte doğrulamanız ve adres değişikliği aracını kullanmanız gerekir. Bu aracın nasıl çalıştığını Google Search Console rehberinde anlattım.

Reklam tarafında ise asıl risk, dönüşüm etiketlerinin yeni sitede eksik kalmasıdır. Etiket eksikse reklam hesabı birkaç gün boyunca sıfır dönüşüm görür. Otomatik teklif stratejileri de bu boşluğu "reklam işe yaramıyor" diye okur ve teklifleri düşürür. Bu yüzden yayından önce test ortamında etiketleri etiket asistanıyla doğruluyorum.

Öte yandan remarketing listeleri de çerezlere bağlıdır. Etiket aynı kalırsa listeler kesintisiz büyümeye devam eder; etiketi değiştirirseniz listeler sıfırdan dolar.

Veri tabanı yapısı farklıysa alan eşleştirmeyi nasıl kurarsınız?

Alan eşleştirme, eski sistemdeki her sütunun yeni sistemde hangi sütuna gideceğini gösteren bir haritadır. Ben bu haritayı kod yazmadan önce bir tabloda hazırlıyorum. Sol sütunda eski alan adı, ortada yeni alan adı, sağda ise dönüşüm kuralı duruyor.

Örneğin eski sistem telefonu "0532 000 00 00" biçiminde tutuyorsa ve yeni sistem ülke kodlu bir biçim istiyorsa, dönüşüm kuralını baştan yazarsınız. Aynı şey tarih biçimleri, para birimleri ve durum kodları için de geçerlidir. Eski sistemde "3" rakamı "kargoda" anlamına geliyorsa, yeni sistemdeki karşılığını açıkça tanımlamanız gerekir.

Üstelik bazı alanların yeni sistemde hiç karşılığı olmaz. Bu alanları çöpe atmak yerine bir not alanında ya da ayrı bir arşiv tablosunda saklamayı tercih ediyorum. Çünkü bugün gereksiz görünen bir alan, altı ay sonra bir müşteri şikâyetinde tek kanıt hâline gelebilir.

Kısacası, eşleştirme tablosu hem geliştiricinin yol haritası hem de ileride soru çıktığında başvuracağınız belge olur.

Karakter seti ve biçim sorunlarını nasıl önlersiniz?

Türkçe içerikli sitelerde en sık gördüğüm veri bozulması, karakter seti uyumsuzluğudur. "Şükrü" adı "Şükrü" gibi anlamsız bir diziye dönüşür. Bu sorun genelde dışa aktarma ile içe aktarma arasında farklı karakter setleri kullandığınızda ortaya çıkar.

Bu yüzden dökümü alırken karakter setini açıkça belirtiyorum ve yeni veri tabanını utf8mb4 ile kuruyorum. utf8mb4, emoji dahil bütün Unicode karakterlerini saklar; eski utf8 ayarı ise bazı karakterleri kesebilir. Ardından içe aktarmadan sonra ğ, ş, ı, İ harflerini içeren birkaç kaydı elle açıp kontrol ediyorum.

Biçim sorunları yalnızca harflerle sınırlı değildir. Ondalık ayırıcı da büyük bir tuzaktır: Türkiye'de virgül, pek çok yazılımda ise nokta kullanırsınız. Fiyat alanı yanlış okunursa, 1.250,00 TL'lik bir sipariş 1,25 TL olarak görünebilir. Dolayısıyla tutar alanlarını mutlaka toplam kontrolüyle doğrulayın.

Üçüncü taraf servislerdeki veriler ne olacak?

Modern bir site yalnızca kendi veri tabanından ibaret değildir. Bülten listesi bir e-posta servisinde, canlı destek geçmişi bir sohbet aracında, yorumlar bir değerlendirme platformunda, ödeme kayıtları ise ödeme sağlayıcısında durur. Yenilemede bu servislerin bağlantısı kopabilir.

• E-posta bülteni: abone listesini dışa aktarın ve izin kayıtlarını da saklayın.
• Ödeme altyapısı: geri dönüş adreslerini (callback) yeni siteye göre güncelleyin.
• Canlı destek ve sohbet araçları: geçmiş yazışmaları dışa aktarın.
• Kargo ve muhasebe entegrasyonları: API anahtarlarını ve bağlantı adreslerini yeniden tanımlayın.

Ayrıca bu servislerin hesaplarının kimin adına açık olduğunu kontrol edin. Eski ajansın ya da ayrılan bir çalışanın e-postasına bağlı bir hesap, yenileme sırasında erişim sorununa dönüşür. Bu nedenle bütün hesapları şirketin kendi kurumsal adresine taşımanızı öneririm.

Test aktarımını neden en az bir kez yapmalısınız?

Test aktarımı, gerçek verinin bir kopyasını yeni sisteme deneme amacıyla taşımaktır. Ben her projede en az bir, genellikle iki prova yapıyorum. İlk prova hataları bulur, ikinci prova düzeltmelerin gerçekten çalıştığını gösterir.

Provada özellikle ilişkili kayıtlara bakıyorum. Bir müşterinin siparişleri, adresleri ve yorumları yeni sistemde hâlâ aynı müşteriye bağlı mı? Bu soruya evet diyemiyorsanız, gerçek aktarıma geçmeyin.

Provanın bir faydası daha var: süreyi ölçersiniz. Veri tabanı büyükse aktarım saatler sürebilir. Bu süreyi önceden bilmezseniz, yayın gecesi sitenin ne kadar süre kapalı kalacağını da tahmin edemezsiniz.

Ayrıca test ortamının dışarıdan erişime kapalı olması gerekir. Gerçek müşteri verisiyle çalışan bir test sitesi arama motorlarına açık kalırsa, hem kopya içerik hem de kişisel veri sızıntısı yaşarsınız. Test ortamını şifreyle koruyun; güçlü bir şifre için şifre oluşturucu işinizi görür. Mümkünse test aktarımında kişisel alanları maskeleyin.

Veri aktarımı sonrası doğrulamayı nasıl yaparsınız?

Doğrulamayı gözle değil, sayılarla yapıyorum. Aktarımdan önce eski sistemde her tablonun kayıt sayısını çıkarıyorum, sonra aynı sayımı yeni sistemde tekrarlıyorum. Sayılar tutmuyorsa, fark bulunana kadar yayına geçmiyorum.

1. Kayıt sayısı: müşteri, sipariş, form ve yorum tabloları tek tek.
2. Toplam kontrolü: örneğin sipariş tutarlarının genel toplamı iki sistemde aynı mı?
3. Örneklem kontrolü: rastgele seçtiğiniz 20 müşterinin geçmişini elle açın.
4. Uç durumlar: en eski kayıt, en yeni kayıt, Türkçe karakterli isimler.
5. İşlev testi: taşınan bir hesapla giriş yapın, eski bir siparişi görüntüleyin.

Kısacası, sitenin açılması doğrulama değildir. Rakamlar iki tarafta eşleşmedikçe veri aktarımını bitmiş saymayın. Bu kontrol listesini tabloya dökmek, müşteriye de şeffaf bir teslim raporu sunmanızı sağlar.

Yayın günü veri aktarımını nasıl planlarsınız?

Yayın günü planının merkezinde "son fark" aktarımı durur. Test kopyasından sonra eski sitede oluşan yeni kayıtları, yayın anında ayrıca taşımanız gerekir. Bunu yapmanın en temiz yolu, kısa bir bakım penceresi açmaktır.

• Trafiğin en düşük olduğu saati seçin; bunu analitik verinizden görebilirsiniz.
• Eski sitede sipariş ve form almayı geçici olarak durdurun.
• Son farkı taşıyın ve sayım doğrulamasını tekrarlayın.
• DNS ya da sunucu yönlendirmesini ancak bundan sonra değiştirin.
• Eski sistemi yalnızca görüntüleme modunda bir süre açık tutun.

DNS'e geçmeden önce kayıtların TTL değerini düşürmek, değişikliğin daha hızlı yayılmasına yardım eder. Ardından URL yönlendirmelerini yönlendirme denetleyici ile kontrol edin. URL tarafındaki tam kontrol listesi için SEO migration kontrol listesine göz atabilirsiniz.

İşler ters giderse geri dönüş planınız ne olmalı?

Geri dönüş planı, yayın sonrası ciddi bir veri sorunu çıkarsa eski sisteme hangi adımlarla döneceğinizi önceden yazdığınız belgedir. Ben bu planı yayın gününden önce hazırlıyorum, çünkü panik anında doğru kararı vermek zordur.

Plan üç soruya net cevap vermeli. İlk olarak, hangi durumda geri döneceksiniz? Örneğin ödeme alınamıyorsa ya da müşterilerin önemli bir kısmı giriş yapamıyorsa. İkinci olarak, geri dönüşü kim onaylayacak? Son olarak, geri dönüş sırasında yeni sitede oluşan kayıtları nasıl kurtaracaksınız?

Son soru çoğu zaman unutulur. Yeni site birkaç saat yayında kaldıysa, o saatlerde gelen siparişler yeni veri tabanındadır. Geri dönerken bu kayıtları da eski sisteme aktarmanız gerekir. Bu yüzden eski sistemi hemen silmemek, geri dönüş planının da ön koşuludur.

Böylece yayın gecesi bir sorun çıktığında tartışmak yerine listeyi uygularsınız.

Veri aktarımı ne kadar sürer ve süreyi ne belirler?

Süre, veri hacmine, platform farkına ve temizlik ihtiyacına bağlıdır. Aynı platform içinde tema değiştiriyorsanız veri tabanı yerinde kalır ve aktarım neredeyse sıfırdır. Farklı bir platforma geçiyorsanız, eşleştirme, test ve doğrulama haftalar alabilir; bu, saha tecrübesine dayalı bir başlangıç aralığıdır, garanti değil.

Süreyi uzatan asıl etken genelde veri hacmi değil, verinin kirliliğidir. Mükerrer müşteri kayıtları, eksik e-posta adresleri ve yıllar içinde farklı biçimlerde girilmiş adresler, her birini tek tek karar vermeyi gerektirir. Ayrıca sipariş kayıtları arasında ilişkisi kopmuş satırlar da ek iş çıkarır.

Bu nedenle takvim hazırlarken aktarımın kendisine değil, temizlik ve doğrulamaya zaman ayırın. Test aktarımında ölçtüğünüz süre, yayın gecesi planının da temelini oluşturur.

Eski sistemi ne zaman kapatmak güvenlidir?

Eski sistemi yayından hemen sonra kapatmak, gördüğüm en pahalı alışkanlıklardan biridir. Aktarımda gözden kaçan bir tablo çoğu zaman haftalar sonra ortaya çıkar: bir müşteri eski faturasını ister, bir çalışan eski bir yazışmayı arar.

Bu nedenle eski sistemi yalnızca görüntüleme modunda en az birkaç hafta açık tutmanızı öneririm; bu süre saha tecrübesine dayalı bir başlangıç aralığıdır, garanti değil. Hosting sözleşmesinin bitiş tarihini de buna göre ayarlayın. Kapatmadan önce son bir tam yedek alın ve bunu şirketin kendi arşivine indirin.

Üstelik eski sunucudaki kişisel verileri kapatma sonrasında unutmamalısınız. Hosting firmasından hesabın ve yedeklerin silindiğine dair onay isteyin. Aksi halde artık kullanmadığınız bir sunucuda müşteri verisi durmaya devam eder.

KVKK açısından veri aktarımında nelere dikkat etmeli?

Kişisel veri içeren bir aktarım, hukuki açıdan da bir işlemdir. Yeni hosting, yazılım firması ya da ajans verinize erişecekse, bu tarafla veri işleme şartlarını yazılı hâle getirin. Hukuki değerlendirmeyi mutlaka bir uzmana yaptırın; ben burada yalnızca teknik tarafta dikkat ettiğim noktaları paylaşıyorum.

• Test ortamında gerçek kişisel veri kullanmaktan kaçının ya da veriyi maskeleyin.
• Veri dökümlerini e-posta eki veya açık paylaşım bağlantısıyla göndermeyin.
• Sunucunun yurt dışında olup olmadığını öğrenin ve aydınlatma metninizi buna göre güncelleyin.
• Artık gerekmeyen eski kayıtları taşımak yerine silme politikanızı uygulayın.

Yetki tarafını da ihmal etmeyin. Aktarım bittiğinde geçici olarak açtığınız veri tabanı kullanıcılarını, FTP hesaplarını ve paylaşım bağlantılarını kapatın. Proje boyunca erişim verdiğiniz dış ekiplerin yetkilerini de geri alın. Böylece aktarım için açılan kapılar, aktarımdan sonra da açık kalmaz.

Yani yenileme, veri temizliği için de iyi bir fırsattır. Yıllardır kimsenin bakmadığı test hesaplarını ve spam form kayıtlarını taşımamak, yeni sistemi de hafifletir.

Veri aktarımını kendiniz mi yapmalısınız, uzmana mı bırakmalısınız?

Bunun cevabı veri hacmine ve platform değişikliğine bağlıdır. Aynı platformun yeni temasına geçiyorsanız, veri tabanı yerinde kalır ve risk düşüktür. Ancak platform değişiyorsa, örneğin hazır bir altyapıdan özel yazılıma geçiyorsanız, alan eşleştirme ve şifre uyumluluğu uzmanlık ister.

Benim önerim şudur: tasarımı kim yaparsa yapsın, veri aktarımının bir sorumlusu olsun ve bu kişi doğrulama raporunu imzalasın. Sorumluluk "tasarımcı sanıyordu, yazılımcı sanıyordu" arasında kalırsa, veri de orada kaybolur.

Kendi başınıza yapacaksanız, en azından yedeği, test aktarımını ve sayım doğrulamasını atlamayın. Bu üç adım, gördüğüm kayıpların büyük kısmını önlerdi. Yenileme projelerinde veri tarafını web tasarım hizmetinin temel bir parçası olarak ele alıyorum.

Veri aktarımında en sık yapılan hatalar nelerdir?

Yıllar içinde aynı hataların farklı projelerde tekrarlandığını gördüm. Bunları bir liste hâlinde tutuyorum ve her yeni projede başlangıçta gözden geçiriyorum.

1. Yedeği aynı sunucuda tutmak ve geri yüklemeyi hiç denememek.
2. Test kopyası ile yayın arasındaki son farkı unutmak.
3. Yeni GA4 mülkü açıp analitik geçmişini ikiye bölmek.
4. Dönüşüm olaylarının adını değiştirip reklam hedeflerini boşa düşürmek.
5. E-postanın aynı hostingde durduğunu fark etmeden hesabı kapatmak.
6. Karakter setini kontrol etmeden içe aktarmak.
7. Doğrulamayı sitenin açılıp açılmadığına bakmakla sınırlamak.

Dikkat ederseniz, bu hataların hiçbiri ileri teknik bilgi gerektirmiyor. Hepsi planlama ve kontrol listesiyle önlenebilecek türden. Bu yüzden veri aktarımını bir yazılım işi değil, bir proje yönetimi işi olarak görüyorum.

Yenileme sonrası ilk 30 günde neyi izlemelisiniz?

Yayın sonrası ilk ay, gizli veri sorunlarının ortaya çıktığı dönemdir. Bu süre boyunca bazı sinyalleri düzenli izliyorum.

• Müşteri hizmetlerine gelen "giriş yapamıyorum" talepleri.
• Form başvuru sayısının yenileme öncesi ortalamayla kıyası.
• GA4'te dönüşüm olaylarının günlük akışı.
• Search Console'da tarama ve dizin hataları.
• Sipariş ve fatura kayıtlarında boş veya bozuk alanlar.

Form sayısında ani bir düşüş, çoğu zaman bir veri ya da etiket sorununa işaret eder, tasarıma değil. Bu sinyalleri okumak için pazarlama raporlarını okuma yazısındaki yaklaşımı kullanabilirsiniz. Sonuç olarak, veri aktarımı yayın günü bitmez; ilk ayın sonunda, rakamlar dengeye oturduğunda biter.

Özetle kayıpsız veri aktarımı için hangi adımları izlemelisiniz?

Özetle süreci altı adıma indirgiyorum: envanter, yedek, test aktarımı, doğrulama, yayın günü son farkı ve izleme. Her adımın bir sorumlusu ve yazılı bir çıktısı olursa, yenileme işletmenin hafızasına dokunmadan biter.

Yenilemeyi tasarımın cazibesiyle başlatmak doğaldır. Fakat müşteri, yeni sitenin rengini değil, eski siparişini görebildiğini hatırlar. Bu yüzden veri tarafını projenin ilk haftasında planlayın, son haftasına bırakmayın.

Site taşımanın genel çerçevesi için Google Search Central site taşıma rehberi iyi bir başlangıç noktasıdır. Veri tarafında takıldığınız bir nokta olursa bana ulaşabilirsiniz.