Muhasebe ve ERP yazılımını ofis bilgisayarından yeni bir sunucuya taşımak, dosyalar kopyalandığında bitmez. Kullanıcıların doğru veriyle çalışması, entegrasyonların yalnız yeni sistem üzerinden işlem üretmesi ve geçiş kararının yetkili kişilerce kabul edilmesi gerekir. Aksi hâlde iki farklı sunucuda oluşan kayıtlar, teknik kesintiden daha zor bir iş problemine dönüşebilir. Bu rehber ERP sunucu taşımasında veri dondurma, pilot kullanım ve canlıya geçiş kabulünü ele alır; performans boyutlandırması veya yedekten dönüş tatbikatının yerine geçmez.

Geçiş kapsamını uygulama listesinden başlatın

İlk envanter yalnız sunucu adı ve disk boyutu olmamalıdır. ERP sürümü, veritabanı motoru, şirket veya dönem verileri, dosya paylaşım yolları, belge arşivi, lisans mekanizması ve kullanılan entegrasyonlar yazılmalıdır. Yazılımın yeni işletim sistemi ve sunucu düzeniyle uyumluluğunu yetkili yazılım firması doğrulamalıdır. Altyapı sağlayıcısının sunucuyu hazırlaması, uygulama üreticisinin taşıma prosedürünü otomatik olarak kapsamaz.

Barkod cihazı, yazıcı, e-belge bağlantısı, banka aktarımı ve zamanlanmış raporlar gibi bağımlılıkları da inceleyin. Her bağımlılığın bir teknik sahibi bulunmalıdır. Eski makinenin masaüstünde çalışan küçük bir görev, işin önemli bir parçası olabilir. Geçiş sonrasında kimin hangi kontrolü yapacağı belirlenmezse, sorunlar ancak ilk gerçek işlem sırasında görünür olur.

Veri dondurma anı neyi durdurmalı?

Veri dondurma, kullanıcıların uygulamadan çıkmasının ötesindedir. Entegrasyon servisleri, otomatik içe aktarma, zamanlanmış görevler ve arka plandaki yazma işlemleri de değerlendirilmelidir. Hangi sistemin ne zaman duracağı ve durduğunun nasıl kanıtlanacağı geçiş planında yer almalıdır. Yalnızca kullanıcılara mesaj göndermek, arka planda çalışan bir servisin yazmasını engellemez.

• Son işlem kabul saatini ve sorumlu iş birimini belirleyin.
• Uygulama oturumlarını üreticinin desteklediği yöntemle kapatın.
• Veri yazan entegrasyon ve zamanlanmış görevleri kontrollü durdurun.
• Son tutarlı aktarımın veya uygulama yedeğinin tamamlandığını doğrulayın.
• Eski sistemde yeni işlem oluşmasını engelleyen yöntemi kaydedin.
• Plan dışı acil işin hangi sistemde ve kimin onayıyla yapılacağını yazın.

Veri dondurma süresi şirketin iş takvimine göre seçilmelidir. Ay sonu kapanışı, yoğun sevkiyat veya toplu e-belge işlemleri sırasında taşıma yapmak gereksiz risk yaratabilir. Gerekli duruş süresini tahmin ederken veri aktarımının yanında doğrulama ve karar süresini de hesaba katın. Kesintisiz geçiş vaadi, test edilmiş bir uygulama tasarımı yoksa verilmemelidir.

Pilot kullanıcı testi gerçek işi temsil etmeli

Yeni sistemde giriş ekranının açılması başarı ölçütü değildir. Pilot kullanıcı, günlük işi bilen yetkili bir personel olmalı; yalnız teknik ekibin oluşturduğu boş bir hesapla test yapılmamalıdır. Şirket seçimi, güncel dönem, kritik rapor, belge görüntüleme ve gerekli yazdırma işlemleri kontrol edilmelidir. Test adımları küçük ama temsilî bir liste hâlinde önceden hazırlanırsa kabul toplantısı daha hızlı ilerler.

Gerçek kayıt üreten testler ayrıca planlanmalıdır. Yanlışlıkla resmî belge göndermek veya banka entegrasyonuna gerçek işlem bırakmak kabul testinin amacı değildir. Uygun test ortamı, üreticinin önerdiği deneme yöntemi veya kontrollü ve yetkili işlem kullanılmalıdır. Test sırasında oluşan kayıtların ne olacağı önceden belli değilse pilotu başlatmayın. Dış sistemlere yapılan işlemlerin geri alınabilir olduğunu varsaymayın.

Veri doğruluğunu hangi kanıtlarla kabul edeceksiniz?

Kayıt sayılarının eşleşmesi yararlı olabilir, fakat tek başına yeterli değildir. Kritik şirket ve dönemlerin mevcut olduğu, son işlem zamanının beklenen noktada bulunduğu ve seçilen iş raporlarının tutarlı sonuç verdiği kontrol edilmelidir. Uygun mutabakat ölçütünü muhasebe sorumlusu ve yazılım firması birlikte belirlemelidir. Teknik ekip, iş kuralı doğruluğunu bilmeden “veriler tamam” kararı vermemelidir.

Dosya arşivini de ayrı inceleyin. Veritabanı yeni sunucuda bulunurken ek belgeler eski paylaşım yolunda kalmış olabilir. Uygulamanın gerçekten yeni dosya konumlarını kullandığını doğrulayın. Kabul kaydında hassas müşteri verilerini ekran görüntüleriyle gereksiz çoğaltmak yerine, kontrolün kapsamını, sonucunu ve sorumlusunu kaydetmek tercih edilmelidir. Kanıt paylaşımını şirketin veri güvenliği kurallarına uygun yürütün.

Çift yazmayı önleyen tek bir geçiş kararı verin

Eski ve yeni sistemin aynı anda üretim kaydı alması, sonradan birleştirilmesi zor iki veri kümesi yaratabilir. Kullanıcı bağlantıları, uzak masaüstü kısayolları, uygulama ayarları ve entegrasyon adresleri tek bir hedefe yönlendirilmelidir. Eski sistemin yalnız arşiv veya inceleme amacıyla tutulması gerekiyorsa, bunun nasıl salt okunur veya erişimi sınırlı kalacağı uygulama üreticisiyle belirlenmelidir.

DNS değişikliği varsa önbellek etkisi göz önüne alınmalıdır; fakat sorun yalnız DNS değildir. Sabit IP kullanan istemci, eski paylaşım yolu veya ayrı bir servis hesabı da eski ortama bağlanabilir. Pilot sonrasında bağlantıları gerçek kullanıcı cihazlarından kontrol edin. Canlıya geçiş onayı, yalnız sistem yöneticisinin mesajı değil, iş sorumlusu ile teknik ekibin ortak kararı olmalıdır.

Geri dönüş, yeni kayıtlar başladığında değişir

Yeni sunucuda henüz üretim yazması başlamadıysa eski sisteme dönmek görece basit olabilir. Yeni işlemler oluştuğunda ise bağlantıyı eski sunucuya çevirmek veri kaybı veya tutarsızlık yaratabilir. Bu eşik geçiş planında açıkça işaretlenmelidir. Hangi durumda taşımanın iptal edileceği, hangi durumda yeni sistemde onarım yapılacağı ve kayıt mutabakatının kimde olduğu önceden kararlaştırılmalıdır.

Eski sunucuyu hemen silmemek tek başına geri dönüş planı değildir. Geri dönülecek veri anı, sonradan oluşan kayıtların yönetimi ve uygulama üreticisinin desteklediği yöntem bilinmelidir. Snapshot veya dosya kopyası da uygulama tutarlılığını otomatik kanıtlamaz. Taşıma planındaki geri dönüş adımı ile düzenli yedekleme ve felaket kurtarma tasarımı birbirinden ayrı tutulmalıdır.

Canlıya geçiş tutanağını kısa ama somut tutun

Uzun bir doküman yerine tek sayfalık, sahipleri belli bir kayıt yeterli olabilir. Kaynak ve hedef sistem, veri dondurma zamanı, aktarım sonucu, yapılan pilot kontroller ve açık kalan sorunlar yazılmalıdır. “Küçük sorunlar var” gibi belirsiz ifadeler yerine iş etkisini ve çözüm sorumlusunu belirtin. Kritik bir iş akışı doğrulanmadıysa, tüm kullanıcıların geçişini tamamlanmış göstermeyin.

• Yazılım uyumluluğu ve lisans koşulları yetkili firma tarafından doğrulandı.
• Eski ortamda yeni kayıt oluşması önlendi.
• Pilot kullanıcıların temel iş akışları başarıyla denendi.
• Veri, belge arşivi ve kritik rapor mutabakatı yapıldı.
• Entegrasyonların yalnız doğru hedefte çalıştığı kontrol edildi.
• Geri dönüş eşiği, gözlem süresi ve kabul sahipleri kayda geçti.

Altyapı teklifiyle taşıma kapsamını ayırın

Muhasebe programı sunucusu veya işletmeye uygun VDS altyapısı değerlendirirken kullanıcı düzenini, uygulama ve veritabanı sürümünü, bağlantı yöntemini ve planlanan geçiş aralığını paylaşın. Sunucu kaynakları, işletim sistemi ve uygulama lisansları, yedekleme, yazılım taşıma ve entegrasyon çalışmaları ayrı kapsam kalemleri olarak netleştirilmelidir. Her paketin tüm uygulama operasyonunu içerdiğini varsaymayın.

ERP sunucu taşımanız için altyapı ve geçiş gereksinimlerini birlikte değerlendirelim. Mevcut sistemin kısa envanteri ve yetkili yazılım firmanızın taşıma koşulları, teknik görüşmede doğru sorumlulukların belirlenmesini kolaylaştırır.