Migrasi SAP ECC dari Server Fisik ke Cloud

Migrasi dari Server Fisik ke Cloud: Pengalaman dan Tantangannya.

Dulu, ketika sistem ERP SAP ECC 6 masih berjalan manis di server on-premise—semuanya terasa “dalam kendali”. Server ada di ruangan sendiri, bisa dicek fisiknya, bahkan kadang dibelai kipas angin saat suhu ruangan naik. Tapi seiring waktu, muncul pertanyaan besar: apa tetap relevan bertahan di on-premise?

Akhirnya, saya (dan tim) memutuskan untuk mulai proses migrasi dari server fisik ke cloud. Dan dari pengalaman ini, banyak hal yang ternyata jauh dari kata “mudah”—tapi sangat berharga untuk dibagikan.

Kenapa Pindah ke Cloud?

Ada beberapa alasan yang jadi pemantik awal:

• Biaya pemeliharaan server fisik makin mahal (dan unpredictable).
• Kebutuhan fleksibilitas dan scalability dari sistem makin tinggi.
• Permintaan uptime dan ketersediaan data makin ketat dari user dan manajemen.
• Tantangan dari sisi backup, disaster recovery, dan high availability makin kompleks.

Dan akhirnya, cloud jadi pilihan. Lebih tepatnya: AWS.

Migrasi SAP ECC 6 EHP 6 dari On-Prem ke AWS

Waktu itu, sistem kami jalan di SAP ECC 6 EHP 6, menggunakan database DB2 di atas AIX 6.1. Skenario migrasi kami melibatkan tiga lingkungan: DEV, QAS, dan PRD.

Kami pilih AWS karena:

• Tersedianya VM siap pakai untuk SAP, termasuk AMI Hardened BYOS untuk SUSE SLES.
• Support untuk database DB2, meskipun bukan pilihan mainstream di cloud.
• Fitur-fitur seperti R5 instance, EBS IOPS tinggi, dan integrasi dengan CloudWatch sangat membantu dalam operasional SAP.

Tantangan yang Dihadapi

1. Sizing dan TCO yang Akurat

Meskipun kalkulator AWS sangat membantu, realita kadang berkata lain. Saat uji coba, R5.4xlarge (16 vCPU, 128 GB RAM) terasa cukup—tapi di PRD, load-nya beda. Tuning dan monitoring jadi krusial.

2. Backup dan Restore Prosedur

Di on-prem, kita terbiasa dengan DB2 backup pakai script manual. Di cloud? Kita harus pikirkan soal snapshot EBS, offsite copy, dan pastikan skenario DR (disaster recovery)-nya jalan. Di sinilah muncul kebutuhan dokumentasi backup yang disesuaikan dengan standar ISO.

3. Security dan IAM

Pengaturan IAM (Identity and Access Management) di AWS tidak bisa disambi. Harus ada pemisahan yang jelas: akun billing, akun prod, akun staging/dev. Pengalaman setting akun anak (child AWS Account) dan consolidated billing benar-benar membuka mata pentingnya desain arsitektur yang sustainable.

4. Performance & Monitoring

Kami pakai nmon untuk monitoring sistem Linux di awal, lalu beralih ke CloudWatch. Tapi tetap, ada gap: misalnya, bagaimana melihat bottleneck di DB2 yang jalan di bawah SAP NetWeaver? Tools standar AWS kadang perlu dilengkapi dengan custom script dan plugin tambahan.

Pelajaran yang Didapat

1. Migrasi itu bukan cuma mindahin VM. Tapi juga soal mindset, culture, dan cara kerja baru.
2. Monitoring itu harus jadi kebiasaan, bukan responsif saat error saja.
3. Dokumentasi adalah nyawa. Baik backup, recovery, maupun arsitektur desain—semua harus jelas, terutama kalau ingin comply ke ISO atau audit.
4. Support vendor itu penting. Baik dari sisi SAP, AWS, maupun partner migrasi seperti Glair—kerja sama erat bikin proses lebih smooth.

Rekomendasi Buat Kamu yang Mau Mulai Migrasi ke Cloud

• Lakukan assessment menyeluruh sebelum migrasi: workload, storage, network latency.
• Mulai dari sistem non-produktif (DEV/QAS/Staging) dulu.
• Pikirkan lisensi OS, terutama kalau pakai SUSE SLES BYOS.
• Dokumentasikan semua, termasuk plan B dan fallback scenario.
• Jangan lupa: jangan migrasi sendirian. Libatkan partner cloud, SAP basis, dan stakeholder bisnis.

Migrasi dari server fisik ke cloud adalah perjalanan, bukan tujuan instan. Ada stres, ada kegagalan, tapi juga ada rasa puas saat sistem jalan lebih efisien, lebih scalable, dan kita bisa fokus ke hal-hal yang lebih strategis.

Kalau kamu sedang menimbang untuk migrasi—jangan tunggu sempurna. Mulai dari yang kecil, dan belajar dari setiap langkahnya. Karena seperti yang saya alami, di dunia sysadmin: belajar paling cepat ya waktu error.