E-Ticaret Ajansı Değiştirirken Kod, Veri, Entegrasyon ve Hesap Devir Teslimi Nasıl Yönetilir?

E-ticaret ajansı değişikliği neden operasyon devridir?

E-ticaret ajansı değişikliği, yalnızca kaynak kodun veya yönetim paneli şifresinin yeni sağlayıcıya verilmesi değildir; satış kanalını çalıştıran teknik ve operasyonel bileşenlerin tamamının kontrollü biçimde devredilmesidir. Başarılı bir geçişte kod, veri, hesap sahipliği ve operasyon bilgisi aynı plan içinde ele alınır. Mağaza görünürde çalışmaya devam etse bile ödeme, kargo, stok, sipariş veya ölçüm sistemlerinden biri eksik devredildiğinde yeni ekip kritik bir sorunu teşhis etmekte zorlanabilir.

Ajans değişimini kesintisiz ticaret projesi olarak yönetin

Yeni sağlayıcı değerlendirilirken yalnızca tasarım ve geliştirme kabiliyetine değil, mevcut sistemi devralma yöntemine de bakılmalıdır. Özellikle e-ticaret yazılım firması seçim kriterleri içinde teknik audit, erişim güvenliği, entegrasyon dokümantasyonu ve üretim ortamını yönetme yetkinliği ayrı değerlendirilmelidir. Ajans değişiminin amacı yalnızca yeni bir ekiple çalışmak değil, mağazanın teknik sahipliğini işletmenin kontrolünde sürdürülebilir hâle getirmektir.

• Kaynak kod ile canlı satış operasyonunu tek kapsamda değerlendirin.
• Hesapların ve servislerin kimin adına kayıtlı olduğunu doğrulayın.
• Kritik entegrasyonların çalışma mantığını yazılı hâle getirin.
• Yeni ajansın devralacağı sorumlulukları açıkça tanımlayın.
• Geçiş öncesi geri dönüş ve acil müdahale planı oluşturun.

“Data is a precious thing and will last longer than the systems themselves.”- Tim Berners-Lee

Ajans değişikliğinde hangi hesaplar devralınmalıdır?

Ajans değişikliğinde devralınması gereken hesaplar, mağazanın satış, pazarlama, veri ve altyapı süreçlerini yönetmek için kullanılan bütün kurumsal hesapları kapsamalıdır. Domain ve DNS, hosting veya bulut, kod deposu, veritabanı, ödeme kuruluşu, kargo servisleri, ERP, pazaryeri, e-posta, analytics, reklam platformları ve Merchant Center erişimleri envantere eklenmelidir. Bir hesabın şifresini bilmek sahiplik anlamına gelmez; ana hesap ve kurtarma bilgilerinin şirket kontrolünde olması gerekir.

Hesap envanterini sahiplik ve yetki bilgileriyle oluşturun

Her hesap için ana sahip, yönetici kullanıcılar, bağlı e-posta adresi, çok faktörlü doğrulama yöntemi, faturalama sorumlusu, yenileme bilgisi ve bağlı olduğu sistem kaydedilmelidir. Ajans çalışanlarının kişisel e-postalarıyla açılmış hesaplar mümkün olduğunca kurumsal yapıya taşınmalı, yeni ekip için ayrı kullanıcılar oluşturulmalı ve eski erişimler geçiş tamamlandıktan sonra kaldırılmalıdır. Böylece hesap devri, ortak şifre paylaşımı yerine izlenebilir bir yetki yönetimi sürecine dönüşür.

• Domain kayıt şirketi, DNS, CDN ve SSL yönetim hesapları.
• Hosting, bulut, sunucu, veritabanı ve yedekleme panelleri.
• Ödeme, kargo, ERP ve pazaryeri servis hesapları.
• Google Analytics, Tag Manager ve Merchant Center erişimleri.
• Reklam platformları, dönüşüm etiketleri ve katalog bağlantıları.
• Git deposu, proje yönetimi ve hata takip araçları.

Kaynak kod ve veritabanı nasıl kontrol edilmelidir?

Kaynak kod ve veritabanı, teslim dosyasının açılabildiği kontrol edilerek değil, canlı mağazayı yeniden kurabilecek bütünlükte olup olmadığı doğrulanarak değerlendirilmelidir. Git deposunun tam geçmişi, branch ve tag yapısı, bağımlılık dosyaları, migration kayıtları, veritabanı şeması ve üretimde çalışan sürüm arasındaki ilişki incelenmelidir. Canlı ortamda bulunan fakat kaynak depoda karşılığı olmayan değişiklikler, devralma öncesinde kapatılması gereken kritik bir teknik belirsizliktir.

Kodu ve veriyi izole ortamda yeniden çalıştırarak doğrulayın

Yeni ajans, canlı sisteme müdahale etmeden önce mevcut kodu ve güncel bir veri kopyasını güvenli staging ortamında ayağa kaldırabilmelidir. Kurulum adımları, environment değişkenleri, cron görevleri, queue süreçleri, dosya depolama alanları ve özel sunucu ayarları bu test sırasında görünür olur. web tasarım firması değişiminde dikkat edilmesi gereken teknik noktalar da sahiplik ve sürdürülebilirlik açısından benzer bir kontrol mantığı sunar.

• Git geçmişi ile üretimdeki sürümün eşleşmesini doğrulayın.
• Bağımlılık, build ve deployment dosyalarının eksiksizliğini kontrol edin.
• Veritabanı şeması, migration ve yedekleri birlikte inceleyin.
• Dosya depolama alanlarını ve medya varlıklarını envantere alın.
• Staging ortamında kurulum ve temel alışveriş akışını test edin.
• Depo dışında yapılan manuel değişiklikleri ayrıca belgeleyin.

Ürün, müşteri ve sipariş verileri nasıl korunmalıdır?

Ürün, müşteri ve sipariş verileri geçiş sırasında değiştirilecek bir içerik paketi değil, işletmenin devam eden ticari kayıtları olarak korunmalıdır. Ürün varyasyonları, stok ilişkileri, müşteri hesapları, adresler, sipariş durumları, kampanyalar, kuponlar ve gerekli operasyonel ilişkiler veri modeliyle birlikte değerlendirilmelidir. Veri migrasyonunun amacı yalnızca kayıt sayısını taşımak değil, kayıtlar arasındaki iş ilişkilerini ve işlem geçmişini korumaktır.

Taşıma öncesi ve sonrası veri mutabakatı hazırlayın

Ajans değişikliği aynı altyapı üzerinde gerçekleşiyorsa tam veri migrasyonu gerekmeyebilir; ancak erişim, yedekleme ve bütünlük kontrolü yine yapılmalıdır. Altyapı da değişiyorsa alan eşleştirmeleri, karakter kodlamaları, kimlik ilişkileri, tarih ve durum değerleri için dönüşüm kuralları belirlenmelidir. Taşıma sonrasında ürün, müşteri ve sipariş sayıları karşılaştırılmalı; örnek kayıtlar üzerinden fiyat, stok, vergi, teslimat ve sipariş durumları fonksiyonel olarak kontrol edilmelidir.

• Geçiş öncesinde doğrulanmış tam veritabanı yedeği alın.
• Ürün, varyasyon, stok ve kategori ilişkilerini kontrol edin.
• Müşteri ve sipariş bağlantılarının korunduğunu doğrulayın.
• Durum, vergi, fiyat ve para birimi alanlarını karşılaştırın.
• Dosya ve görsel referanslarının yeni ortamda çalıştığını test edin.
• Taşıma sonrasında veri mutabakat raporu oluşturun.

ERP ve ödeme entegrasyonları kesintisiz nasıl devredilir?

ERP ve ödeme entegrasyonlarının kesintisiz devri, her bağlantının hangi veriyi hangi yönde taşıdığının ve hangi kimlik bilgileriyle çalıştığının belgelenmesiyle başlar. Stok, fiyat, ürün, sipariş, fatura, ödeme durumu ve kargo bilgisinin hangi sistemde ana kayıt olduğu belirlenmelidir. Entegrasyon devrinde yalnızca API anahtarı değil, veri akışı, hata senaryosu ve senkronizasyon sorumluluğu da teslim edilmelidir.

Kritik bağlantıları tek tek test ederek yeni ekibe aktarın

ERP, ödeme kuruluşu, kargo ve pazaryeri bağlantıları için test senaryoları hazırlanmalı; başarılı işlem kadar hata ve yeniden deneme davranışları da kontrol edilmelidir. kurumsal e-ticaret altyapısındaki entegrasyon kapsamı incelenerek hangi bağlantıların satış operasyonu açısından kritik olduğu sınıflandırılabilir. Canlı anahtarlar ve webhook adresleri ancak staging doğrulaması tamamlandıktan ve geçiş sırası netleştirildikten sonra kontrollü biçimde değiştirilmelidir.

• Her entegrasyon için veri yönünü ve ana kayıt sistemini belirleyin.
• API anahtarları, webhooklar ve IP izinlerini envantere alın.
• Test ve canlı ortam kimlik bilgilerini birbirinden ayırın.
• Ödeme başarısı ve başarısızlığı senaryolarını ayrı test edin.
• ERP stok ve sipariş senkronizasyonunu uçtan uca doğrulayın.
• Kargo ve pazaryeri hata kayıtlarının izlenebilir olduğunu kontrol edin.

Domain, DNS ve altyapı erişimleri nasıl teslim alınır?

Domain, DNS ve altyapı erişimleri mağazanın erişilebilirliğini doğrudan etkilediği için kontrollü sırayla teslim alınmalıdır. Domain kayıt sahibinin işletme olması, DNS yönetiminin kurumsal hesaba bağlı bulunması, hosting veya bulut kaynaklarının görünür olması ve SSL, CDN, e-posta ile yedekleme servislerinin sorumlularının belirlenmesi gerekir. Kritik altyapı hesabını devralmak, eski şifreyi almak yerine şirket adına yönetilebilir yeni bir erişim modeli kurmak anlamına gelir.

Yetki değişikliklerini servis kesintisi yaratmadan uygulayın

Yeni ajans için bireysel kullanıcılar ve rol bazlı yetkiler oluşturulmalı, çok faktörlü doğrulama etkinleştirilmeli ve kurtarma yöntemleri şirket tarafından saklanmalıdır. DNS veya sunucu değişikliği gerekiyorsa mevcut kayıtlar dışa aktarılmalı, TTL ve yönlendirme etkileri planlanmalı, e-posta kayıtları ve üçüncü taraf doğrulamaları ayrıca kontrol edilmelidir. Eski ajans hesapları, yeni erişimler ve kritik servisler test edilmeden topluca kapatılmamalıdır.

• Domain kayıt sahibi ve yenileme sorumlusunu doğrulayın.
• DNS kayıtlarını değişiklik öncesinde eksiksiz dışa aktarın.
• Sunucu ve bulut kullanıcılarını kişi bazlı yetkilendirin.
• SSL, CDN, e-posta ve yedekleme servislerini kontrol edin.
• Çok faktörlü doğrulama ve kurtarma hesaplarını kurumsallaştırın.
• Eski ajans erişimlerini doğrulama tamamlandıktan sonra kaldırın.

SEO ve analytics verileri geçişte nasıl korunmalıdır?

SEO ve analytics verilerinin korunması için mevcut URL yapısı, yönlendirmeler, indexleme tercihleri ve ölçüm kurulumları geçiş öncesinde envantere alınmalıdır. Ajans değişikliği sırasında altyapı veya tema yenileniyorsa ürün, kategori ve içerik URL’lerinin istemeden değişmesi; canonical, robots, sitemap veya schema ayarlarının kaybolması organik görünürlüğü etkileyebilir. Teknik geçişte SEO sürekliliği, eski ve yeni yapının URL bazında karşılaştırılmasıyla korunur.

Ölçüm hesaplarını ve dönüşüm sinyallerini aynı anda doğrulayın

Google Analytics, Tag Manager, Search Console, Merchant Center ve reklam dönüşüm kurulumlarının sahipliği ile veri akışı yeni ajans tarafından kontrol edilmelidir. SEO ve GEO uyumlu web sitesi teknik gereksinimleri geçiş sırasında korunması gereken indekslenebilirlik ve teknik yapı kararları için yararlı bir kontrol çerçevesi sunar. Yeni sürüm yayına alınmadan önce temel sayfalar, yönlendirmeler, eventler, satın alma dönüşümü ve ürün feed akışı staging veya ön doğrulama ortamında test edilmelidir.

• Mevcut indekslenebilir URL listesini ve yönlendirmeleri çıkarın.
• Canonical, robots, sitemap ve yapılandırılmış veriyi karşılaştırın.
• Analytics ve Tag Manager sahipliklerini şirket hesabında doğrulayın.
• Search Console ve Merchant Center yetkilerini yeni ekibe devredin.
• Satın alma ve kritik dönüşüm eventlerini yeniden test edin.
• Yayın sonrası tarama hataları ve ölçüm kesintilerini izleyin.

Yeni ajans teknik audit sürecinde neleri incelemelidir?

Yeni ajans teknik audit sürecinde kod kalitesi, güvenlik, veritabanı, entegrasyonlar, altyapı, performans, SEO ve operasyonel bağımlılıkları birlikte incelemelidir. Audit, önceki ajansı puanlamak için değil, sistemin gerçek durumunu ve devralma önceliklerini belirlemek için yapılmalıdır. Audit çıktısı sorunların yalnızca listesini değil, iş etkisini, müdahale önceliğini ve devralma sırasını göstermelidir.

Audit bulgularını bakım ve sürekli geliştirme planına bağlayın

Eski paketler, güvenlik açıkları, secrets yönetimi, yetkilendirme, yedekleme, loglama, cron ve queue süreçleri, üçüncü taraf bağımlılıkları, performans darboğazları ve test kapsamı incelenmelidir. E-ticaret özelinde sepet, ödeme, sipariş, stok ve entegrasyon akışları iş açısından öncelikli test alanlarıdır. Bulgular kritik, kısa vadeli ve planlı iyileştirme gruplarına ayrıldığında yeni ajansın bakım teklifi ile geliştirme yol haritası daha gerçekçi bir kapsam üzerinden oluşturulabilir.

• Kod mimarisi, bağımlılıklar ve teknik borcu değerlendirin.
• Kimlik doğrulama, yetkilendirme ve secrets yönetimini inceleyin.
• Veritabanı bütünlüğü ve yedek geri yükleme sürecini test edin.
• Sepet, ödeme, sipariş ve stok akışlarını uçtan uca kontrol edin.
• Loglama, hata izleme ve performans gözlemlenebilirliğini doğrulayın.
• Audit bulgularını iş etkisine göre önceliklendirin.

Staging ve kontrollü geçiş planı nasıl uygulanmalıdır?

Staging ve kontrollü geçiş planı, yeni ajansın canlı mağazayı değiştirmeden sistemi tanımasını, kritik akışları test etmesini ve geri dönüş senaryosunu doğrulamasını sağlamalıdır. Büyük mağazalarda kod, entegrasyon, DNS veya altyapı değişikliklerini aynı anda yapmak yerine birbirinden ayrılmış kontrol noktaları oluşturmak riski azaltır. Geçiş tarihi tek başına plan değildir; her adımın sahibi, ön koşulu, test yöntemi ve rollback seçeneği bulunmalıdır.

Paralel destek dönemini net sorumluluklarla yönetin

Eski ve yeni ajansın kısa bir süre birlikte erişilebilir olması, dokümantasyonda görünmeyen bilgilerin aktarılmasına yardımcı olabilir. Bu dönemde hangi ekibin canlı müdahale yapabileceği, hangi değişikliklerin dondurulacağı, kritik olayda kimin karar vereceği ve müşteriye nasıl bilgi aktarılacağı yazılı olmalıdır. Geçiş sonrasında sipariş, ödeme, stok, entegrasyon, e-posta, analytics ve SEO sinyalleri belirlenen kontrol listesiyle doğrulanmadan süreç tamamlanmış kabul edilmemelidir.

• Canlı ortamdan ayrı ve güncel bir staging ortamı hazırlayın.
• Geçiş süresince değişiklik dondurma kurallarını belirleyin.
• Kritik akışlar için kabul testleri ve sorumlular tanımlayın.
• Rollback sürümünü ve geri dönüş karar mekanizmasını hazırlayın.
• Paralel destek sırasında müdahale yetkilerini netleştirin.
• Yayın sonrası izleme sürecini kontrol listesine bağlayın.

Yeni e-ticaret ajansı hangi devir kriterleriyle seçilmeli?

Yeni e-ticaret ajansı, yalnızca yeni özellik geliştirme veya tasarım kapasitesine göre değil, mevcut sistemi güvenli biçimde devralma ve sürdürülebilir şekilde işletme yetkinliğine göre seçilmelidir. Teknik audit yöntemi, kaynak kod inceleme yaklaşımı, veri ve hesap sahipliği politikası, entegrasyon deneyimi, staging kullanımı, rollback disiplini ve destek modeli karar kriterleri arasında olmalıdır. İyi tanımlanmış devir kapsamı, ajans tekliflerini aynı teknik sorumluluklar üzerinden karşılaştırmayı mümkün kılar.

Teklifi devralma, bakım ve geliştirme kapsamlarına ayırın

Ajans teklifinde ilk teknik audit, geçiş işleri, acil düzeltmeler, sürekli bakım ve yeni geliştirmeler ayrı kapsamlar olarak görülebilmelidir. e-ticaret yazılımı tekliflerini karşılaştırırken yalnızca teslim edilecek özelliklere değil; erişim sahipliği, dokümantasyon, destek sorumluluğu ve teknik borç yönetimine de bakmak gerekir. Böylece e-ticaret sitesi devralma süreci, belirsiz bir ajans değişikliğinden ölçülebilir kabul kriterleri olan yönetilebilir bir projeye dönüşür.

• Teknik audit metodolojisini ve teslim edilecek raporu sorun.
• Kaynak kod, veri ve hesap sahipliği yaklaşımını netleştirin.
• Entegrasyon ve canlı operasyon devralma deneyimini değerlendirin.
• Bakım ile yeni geliştirme sorumluluklarını ayrı tanımlayın.
• Dokümantasyon ve erişim yönetimini sözleşme kapsamına ekleyin.
• Geçişin tamamlanmasını ölçülebilir kabul kriterlerine bağlayın.