ERP Sunucusu Taşıma: Logo, Mikro ve Zirve İçin Geçiş Planı

ERP sunucusu taşıma, şirketin kullandığı muhasebe veya ticari yazılımın uygulama, veritabanı, kullanıcı erişimi ve entegrasyon bileşenlerini mevcut sunucudan yeni bir altyapıya kontrollü biçimde geçirme işidir. Logo, Mikro ve Zirve kullanan işletmeler için yalnız dosyaları kopyalamak yeterli olmayabilir. Lisans, veritabanı sürümü, e-belge bağlantıları, yazıcılar, Active Directory, güvenli uzak erişim ve geri yükleme prosedürü işin tamamını etkiler.

Kısa cevap: Önce mevcut ürün ve sürümü envanterleyin; uygulama üreticisinin yeni işletim sistemi ve veritabanı ortamını desteklediğini doğrulayın. Yeni kurumsal sunucu kiralama altyapısını hazırlayın, uygulama uyumlu yedek alın, izole ortamda geri yükleme denemesi yapın ve kontrollü bir kesinti penceresi belirleyin. Kullanıcılar yeni ortamda kritik işlemleri doğruladıktan sonra eski sunucuyu kapatmayı planlayın. İşinize özel kapsam için ERP sunucusu taşıma teklifi isteyin.

Bu rehber; şirket içindeki eski sunucusunu yenilemek, farklı veri merkezine geçmek, şubelerini merkezi ERP ortamında birleştirmek veya mevcut barındırma sağlayıcısını değiştirmek isteyen BT ve finans yöneticilerine yöneliktir. Buradaki örnekler belirli bir Logo, Mikro veya Zirve sürümü için üretici onayı ya da kesintisiz geçiş garantisi değildir.

1. ERP sunucusu taşımadan önce hangi bilgileri toplamalısınız?

Taşıma projesinin ilk çıktısı bir sistem ve bağımlılık envanteri olmalıdır. Ürün adı tek başına yeterli değildir: kullanılan ERP paketi, tam sürüm, veritabanı motoru ve sürümü, istemci güncellemeleri, firma/veritabanı sayısı, modüller, entegrasyonlar, hizmet hesabı ve uygulamaya giriş yöntemi yazılı kaydedilmelidir.

Ayrıca kullanıcı sayısıyla eşzamanlı aktif kullanıcı sayısını ayırın. Aynı anda rapor alan, e-fatura hazırlayan ve büyük veri sorgusu yapan çalışanlar işlemci, bellek ve disk üzerinde farklı yükler oluşturur. Kaynak sunucuda ortalama ve yoğun saat CPU, RAM, disk gecikmesi, boş alan, SQL veritabanı boyutu ve büyüme hızı ölçülmelidir.

Ürün yöneticisi, muhasebe sorumlusu, veri tabanı yöneticisi ve varsa dış yazılım destek firması başlangıç toplantısına katılmalıdır. Taşıma günü karar verecek tek kişi BT ekibi olmamalıdır; örneğin ay sonu kapanışını veya e-beyanname dönemini finans birimi daha iyi bilir.

2. Logo, Mikro ve Zirve için tek bir taşıma yöntemi var mı?

Hayır. Aynı üreticinin farklı ürün ve sürümleri bile farklı veri depolama, kurulum ve lisans koşulları gerektirebilir. Logo GO veya Tiger ailesi, Mikro'nun farklı ticari yazılım sürümleri ve Zirve Masaüstü ürünleri tek bir evrensel SQL taşıma prosedürüne indirgenmemelidir. Bulut üzerinden zaten hizmet olarak kullanılan ürünler için ayrıca sunucu kiralamak gerekli olmayabilir.

Önce üretici veya yetkili uygulama destek kanalıyla hedef Windows Server sürümünü, SQL Server sürümünü, desteklenen bağlantı yöntemini ve veri taşıma aracını teyit edin. Veritabanı başka bir SQL örneğine aktarılacaksa uyumluluk düzeyi, collation, SQL kimlik doğrulama ve uygulama servisleri de kontrol edilmelidir.

ERP'nin yanında e-fatura/e-arşiv servisleri, banka entegrasyonları, barkod okuyucu, etiket ve mali yazıcı, zamanlanmış görev, dosya paylaşımı veya özel rapor varsa bunları ayrı test maddesi yapın. Uygulama açılıyor olması bu entegrasyonların çalıştığı anlamına gelmez. Ürün bazlı ön araştırma için Logo sunucu ihtiyaçları, Mikro altyapı rehberi ve Zirve sunucu rehberi incelenebilir.

3. Yeni sunucu VPS mi, dedicated mı, yönetilen altyapı mı olmalı?

Tek bir ideal sunucu paketi yoktur. Sanal sunucuda kapasiteyi kademeli artırmak ve ayrı uygulama katmanları kurmak kolaylaşabilir. Yoğun ve sürekli işlem yapan büyük veritabanlarında veya özel donanım gereksiniminde dedicated sunucu kiralama daha uygun olabilir. Karar yalnız kullanıcı sayısıyla değil ölçülen iş yüküyle verilmelidir.

SQL Server için disk kapasitesinin yanı sıra IOPS, gecikme, geçici veritabanı iş yükleri, yedekleme süresi ve ağ gecikmesi önemlidir. ERP sunucusuna bellek eklemek, kötü sorgu veya yanlış indeksleme sorununu otomatik çözmez. Tersine, yetersiz kaynak seçimi de iyi yapılandırılmış uygulamayı yavaşlatabilir. Bu nedenle mümkünse gerçek veriyle pilot performans testi yapılmalıdır.

Kurumun kendi sistem yöneticisi yoksa yönetilen sunucu hizmeti kapsamında güncelleme, izleme, yedek takibi ve olay müdahalesinin hangi saatlerde kim tarafından yapılacağını teklifte ayrı yazdırın. Sunucu işletim sorumluluğu ile ERP uygulama destek sorumluluğunu karıştırmayın.

4. SQL Server veritabanı güvenli biçimde nasıl taşınır?

SQL Server kullanılan iş yüklerinde en yaygın kontrollü yöntemlerden biri, desteklenen yedekleme ve geri yükleme sürecidir. Önce kaynak ve hedef SQL sürümleri arasında uyumluluk kontrol edilir. Microsoft'un başka konuma veritabanı geri yükleme rehberi, aynı veya farklı SQL örneğine geri yükleme adımlarını açıklar. Daha yeni sürümden alınmış bir yedeğin eski SQL sürümüne doğrudan geri yüklenebileceği varsayılmamalıdır.

Tam yedek, başlangıç kopyasını sağlar. Kullanılan kurtarma modeline ve iş yüküne bağlı olarak fark ve işlem günlüğü yedekleri, geçiş anında değişen veriyi azaltmak için planlanabilir. Tam veya bulk-logged kurtarma modelinde log zinciri ve son log yedeği koşulları dikkatle değerlendirilmelidir. Microsoft'un işlem günlüğü geri yükleme sırası belgeleri bu ayrımı açıklar.

Veritabanı dışında SQL oturum açma hesapları, erişim yetkileri, Agent işleri, linked server, zamanlanmış bakım, şifreleme sertifikaları ve diğer sunucu düzeyi nesneler de taşınabilirlik kapsamında düşünülmelidir. Microsoft'un SQL örneği metadata taşıma açıklaması, yalnız kullanıcı veritabanını geri yüklemenin her uygulama için yeterli olmadığını belirtir. Üretici tarafından desteklenmeyen ham dosya kopyalama işlemleriyle üretim verisini riske atmayın.

5. Yedek hazırsa neden ayrıca geri yükleme testi gerekir?

Yedek dosyasının bulunması, yeni sunucuda ERP'nin sorunsuz açılacağı anlamına gelmez. Test ortamında yedek geri yüklenmeli; veritabanı tutarlılığı, hizmet hesapları, uygulama bağlantıları, kullanıcı oturumu, raporlar ve üreticiye özel işlemler gerçekçi biçimde doğrulanmalıdır. Test verilerini yetkisiz kişilere açmadan, üretim verisinin gizliliğini koruyacak bir ortam kullanılmalıdır.

Verinin yanında ekli evrak dosyaları, özel şablonlar, rapor tasarımları, e-belge entegrasyon anahtarları ve uygulama konfigürasyonları ayrı yerde tutuluyor olabilir. Bunların yedek kapsamına girdiği envanterden kontrol edilmelidir. SQL sistem veritabanlarının olduğu gibi kopyalanması her sürüm geçişinde uygun bir yöntem değildir.

Yedekleri mümkünse farklı bir güvenlik alanında tutun ve geri dönüşte erişilebildiğini deneyin. Yedekleme ve felaket kurtarma planında RPO (kabul edilebilir veri kaybı) ile RTO (hedef toparlanma süresi) uygulama bazında tanımlanmalıdır. Teste başlanmadan önce hangi başarısızlıkta işlemin durdurulacağı yazılı olmalıdır.

6. Şubeler yeni ERP sunucusuna nasıl güvenli bağlanır?

Kiralık sunucuyu erişilebilir yapmak için muhasebe veritabanı portlarını veya Windows uzak masaüstünü doğrudan internete açmak varsayılan bir çözüm olmamalıdır. Kullanım senaryosuna göre şirket merkezi ve şubeler arasında site-to-site VPN, çalışanlar için kullanıcı VPN'i veya üreticinin desteklediği bir Remote Desktop Services mimarisi tasarlanabilir.

Doğru yöntem, ERP yazılımının uzak ağ üzerinden doğrudan istemci-veritabanı trafiğini destekleyip desteklemediğine bağlıdır. Bazı uygulamalarda kullanıcıya merkezi oturum sunmak, yüksek gecikmeli şube bağlantıları üzerinde istemciyi doğrudan çalıştırmaktan daha iyi sonuç verebilir. Ancak RDS/RemoteApp uyumluluğu, profil yönetimi, yazıcı ve akıllı kart ihtiyacı önceden denenmelidir.

Ağ ve güvenlik hizmetleri kapsamına kimlik doğrulama, mümkünse çok faktörlü koruma, en az yetki, ağ segmentasyonu, erişim logları ve yetkili yönetici bağlantıları dahil edilmelidir. Erişim yolu değiştiğinde tüm şubelerin kesintiden önce bağlantı ve uygulama testi yapması önemlidir.

7. Windows, SQL, RDS ve ERP lisanslarını kim doğrulamalı?

Sunucu kira bedeline Windows Server, SQL Server, kullanıcı erişim lisansları, RDS lisansları veya ERP uygulama lisansının otomatik olarak dahil olduğunu düşünmeyin. Kullanıcının mevcut lisansını veri merkezindeki farklı bir sağlayıcı altyapısında kullanabilmesi, lisans programına ve sözleşme koşullarına bağlı olabilir.

Windows Server üzerindeki çok kullanıcılı uzak masaüstü ortamlarında uygun RDS CAL veya ilgili hizmet sağlayıcı lisanslama modeli incelenmelidir. Microsoft'un RDS CAL gereksinimleri ve sürüm uyumluluğu dokümanı, lisans sunucusu ve oturum ana bilgisayarı arasındaki sürüm ilişkisini açıklar. Yönetim amaçlı RDP oturumlarını genel çalışan oturumlarıyla eşdeğer saymayın.

Teklifte lisansları ayrı başlıklara bölün: işletim sistemi, veritabanı, uzaktan erişim ve ERP ürünü. Yetkili lisans danışmanı ile uygulama üreticisi son onayı vermeli; sürüm yükseltme maliyetleri ve bakım sözleşmeleri ayrıca değerlendirilmelidir.

8. Kesinti penceresi ve geri dönüş planı nasıl hazırlanır?

Bir muhasebe sunucusu taşınırken kesintiyi azaltmak hedeflenebilir; ancak sıfır kesinti önceden kanıtlanmış bir mimari olmadan vaat edilmemelidir. İş birimi ile geçiş günü ve işlem dondurma saati belirlenir. Son yedek veya geçerli log zinciri tamamlanır; kullanıcıların eski ortama yeni kayıt yazması engellenir. Ardından hedef sistem açılır ve kontrollü kullanıcı kabul testine geçilir.

Geri dönüş planı, yalnız eski sunucuyu açmaktan ibaret değildir. Yeni ortama geçtikten sonra muhasebe kayıtları oluşturulduysa bunların eski veritabanına nasıl ve hangi kurallarla geri alınacağı ayrıca çözülmelidir. İki ayrı ortamda eşzamanlı veri girişine izin vermek kayıt çakışması yaratabilir. Bu nedenle tek bir yazma otoritesi ve net karar noktası bulunmalıdır.

İşlem öncesi geri dönüş tetikleyicilerini belirleyin: belirlenen zaman sınırına kadar uygulama açılmazsa, raporlar bozulursa, e-belge işlemleri başarısızsa veya veri tutarlılığı doğrulanamazsa ne yapılacak? Kararı kim verecek, muhasebe ekibi hangi adımda bilgilendirilecek, eski sistem hangi koşullarda tekrar üretime alınacak? Bu soruların yanıtı geçişten önce verilmelidir.

9. Taşıma gününde uygulanacak 12 adımlık kontrol listesi

Aşağıdaki liste tek bir ürünün zorunlu üretici prosedürü değil, uygulama destek ekibiyle özelleştirilecek bir operasyon çerçevesidir:

1. ERP ürünü, sürüm, lisans ve modül envanterini onaylayın.
2. Veritabanı, dosya paylaşımı, e-belge ve harici entegrasyon bağımlılıklarını kaydedin.
3. Kaynak sistemin kapasite ölçümleri ve veri büyümesini raporlayın.
4. Hedef sunucuda işletim sistemi, SQL ve uygulama uyumluluğunu doğrulayın.
5. VPN, DNS, güvenlik duvarı ve kullanıcı erişim yollarını önceden test edin.
6. Uygulama tutarlı tam yedek ve bağımsız kurtarma kopyası oluşturun.
7. Yedekleri izole hedef ortamda geri yükleyerek pilot testi tamamlayın.
8. Muhasebe sorumlusundan yazılı geçiş ve kesinti penceresi onayı alın.
9. Kullanıcı oturumlarını ve veri yazımını kontrollü biçimde durdurun.
10. Son veri senkronizasyonu veya üretici onaylı son yedek adımını tamamlayın.
11. Hedef ortamda kayıt, rapor, e-belge, yazıcı ve şube erişim testlerini yapın.
12. Kabul sonucu, geri dönüş karar noktası, izleme ve eski sistemi kapatma tarihini kaydedin.

Bu adımların gerçek sırası veritabanı kurtarma modeline ve üretici yönergelerine göre değişebilir. Pilot çalışma yapılmadan canlı ortamda yöntem denemek, son dakika kesinti ve veri tutarsızlığı riskini büyütür.

10. Yeni ERP sunucusunun devreye alındığı nasıl anlaşılır?

Başarılı geçiş ölçütü yalnız yeni sunucunun açılması veya ERP giriş ekranının görünmesi değildir. Yetkili bir kullanıcı şirket seçebilmeli, cari hesap ve stok işlemlerini açabilmeli, örnek rapor hazırlayabilmeli, e-belge iş akışını uygun test yöntemiyle doğrulayabilmeli ve gerekiyorsa yazdırma yapabilmelidir. Bu işlemler kişisel veya gerçek ticari veriyi gereksiz yere çoğaltmadan yapılmalıdır.

BT ekibi bağlantı sürekliliği, uygulama olay kayıtları, SQL hataları, disk gecikmesi, kaynak kullanımı, yedek işlerinin tamamlanması ve VPN oturumlarını izlemelidir. Kullanıcı kabulü finans sorumlusu tarafından; teknik kabul sistem yöneticisi tarafından ayrı kaydedilebilir. Her bulgu için önem derecesi, sorumlu kişi ve kapanış süresi oluşturun.

Geçişten sonra önceki sunucu hemen silinmemelidir. Geri dönüş penceresi, sözleşme, güvenli arşiv ve veri saklama yükümlülükleri değerlendirildikten sonra kontrollü kapatma ve güvenli veri imhası kararı verilmelidir.

11. ERP sunucusu taşıma maliyetini hangi kalemler belirler?

Taşıma maliyeti bir kerelik kopyalama ücretinden oluşmaz. Yeni sunucu kapasitesi, Windows ve SQL lisansları, ağ/VPN kurulumu, güvenlik, yedekleme, geçiş mühendisliği, uygulama üreticisi desteği, test saatleri ve gerekirse geçici paralel ortam kaynakları birlikte hesaplanmalıdır. Yeni hosting bedeliyle taşıma hizmeti bedelini ayrı incelemek, tekliflerin karşılaştırılmasını kolaylaştırır.

Bu tablo bir fiyat listesi değildir. İki teklifi karşılaştırırken aynı kullanıcı sayısı, veritabanı boyutu, kritik iş akışı ve hedef kesinti düzeyini kullanın. Fiyatı etkileyen diğer kalemler için sunucu kiralama fiyatlandırma rehberine bakabilirsiniz.

12. ERP taşıma teklifi için hangi bilgileri göndermelisiniz?

İlk teklif görüşmesini hızlandırmak için mevcut ve hedef sunucu sayısını, ERP ürün/sürüm bilgisini, SQL motoru ve veritabanı boyutunu, eşzamanlı kullanıcı ve şube sayısını, mevcut bağlantı türünü, hedef geçiş tarihini, beklenen kesinti penceresini ve yedekleme ihtiyacını hazırlayın. Henüz donanım kapasitesi ölçülmediyse bunu da açıkça belirtin; tahmini değerler kesin gereksinim gibi sunulmasın.

Netsun Bilişim'den istenecek çıktı yalnız CPU/RAM önerisi değil; hedef mimari, taşıma adımları, uygulama üreticisi sorumlulukları, lisans varsayımları, test/kabul ölçütleri ve geri dönüş yaklaşımı olmalıdır. ERP ve muhasebe altyapısı çözümleri kapsamında farklı iş yükleri birlikte değerlendirilebilir.

Mevcut sisteminizde Logo, Mikro veya Zirve çalışıyorsa ürün ve sürüm bilgisiyle birlikte kurumsal ERP sunucusu taşıma teklifi alın. İncelemenin amacı hazır paket satmak değil, uygulamanızın doğrulanmış gereksinimlerine göre güvenli ve ölçülebilir bir geçiş planı oluşturmaktır.

Sık sorulan sorular

1. ERP sunucusu taşıma sırasında şirket çalışmaya devam edebilir mi?

Pilot hazırlık ve ilk veri kopyalama aşamaları bazı senaryolarda üretim sürerken yapılabilir. Son geçişte veri yazımının durması veya uygulamanın devre dışı kalması gerekebilir. Kesinti beklentisi, desteklenen yöntem ve test sonuçlarına göre belirlenmelidir.

2. Logo, Mikro ve Zirve aynı SQL Server sürümünde çalışır mı?

Bütün ürün ve sürümler için böyle bir genelleme yapılamaz. Her uygulamanın ve modülün desteklediği SQL Server ile Windows Server sürümleri ayrı kontrol edilmelidir. Yükseltme kararı üreticinin güncel uyumluluk bilgisiyle verilmelidir.

3. Eski SQL yedeğini yeni sunucuya geri yüklemek yeterli midir?

Her zaman değil. SQL kullanıcıları, logins, Agent işleri, sertifikalar, bağlantı bilgileri, dosya klasörleri ve uygulama entegrasyonları veri tabanı dışında olabilir. Uygulama seviyesinde kullanıcı kabul testi gereklidir.

4. ERP sunucusu taşınırken veri kaybı sıfır olabilir mi?

Uygun yöntem ve kontrollü son senkronizasyonla veri kaybı hedefi çok düşük tutulabilir; ancak test edilmeden kesin garanti verilmez. Veri kaybı riski kullanılan kurtarma modeli, son sağlam yedek ve kesinti kararına bağlıdır.

5. Muhasebe sunucusu için VPS yeterli olur mu?

Küçük veya orta ölçekli bazı iş yüklerinde uygun bir sanal sunucu yeterli olabilir. Eşzamanlı kullanıcı, sorgu, disk gecikmesi, veri büyümesi ve lisans koşulları ölçülmeden kesin CPU/RAM önerisi yapılmamalıdır.

6. Sunucuyu veri merkezine taşıyınca RDS lisansı gerekir mi?

Yalnız veri merkezinde barındırma yapmak tek başına RDS kullanımını başlatmaz. Çalışanların Windows Server üzerinde Remote Desktop Services oturumları kullanması hâlinde ilgili erişim lisansları değerlendirilmelidir. İşletim sistemi ve ERP lisansları ayrıca incelenir.

7. ERP sunucusu taşıma sonrası eski sunucu ne zaman kapatılır?

Uygulama ve muhasebe kabul testleri, belirlenen gözlem ve geri dönüş penceresi tamamlandıktan sonra; saklama ve mevzuat yükümlülükleri dikkate alınarak kapatma planlanır. Önceki verilerin silinmesi ayrı bir onay ve kayıt sürecidir.

8. ERP sunucusu taşıma teklifi almak için ne paylaşmalıyım?

Ürün/sürüm, kullanıcı ve şube sayısı, veritabanı boyutu, mevcut sistemin konumu, lisans durumu, erişim ve yedekleme ihtiyacı ile hedef geçiş tarihini belirtin. ERP sunucusu taşıma teklif formunu açın.