Bagaimana pindah ke sistem baru tanpa menghentikan pekerjaan?

Anda bisa pindah tanpa menghentikan pekerjaan jika tidak mematikan sistem lama sebelum sistem baru membuktikan dirinya: jalankan keduanya pada transaksi nyata yang sama dan bandingkan hasilnya, uji kasus langka yang disebutkan pemilik proses, wajibkan persetujuan manusia untuk setiap modul sebelum digunakan, dan siapkan sistem lama agar bisa dipakai kembali. Dalam panduan pelaksanaan migrasinya, Microsoft menyarankan pemantauan sistem baru selama 24 hingga 48 jam pertama setelah peralihan dan mempertahankan lingkungan sumber sebagai cadangan selama masa stabilisasi.

Di bagian 5 Anda telah memilih jalur untuk setiap sistem. Bagian ini tidak mengulang metode peralihan umum yang kami jelaskan di Modernisasi sistem lama tanpa henti. Fokusnya pada hal baru: apa yang perlu diuji ketika AI yang menulis atau mengonversi kode baru.

Mengapa kode hasil konversi AI butuh pengujian berbeda

Kode buatan alat konversi tampak rapi dan langsung berjalan pada percobaan pertama, dan justru itulah yang membuat kesalahannya sulit terlihat. Kesalahan tidak muncul dalam pekerjaan sehari-hari, melainkan pada kasus yang terjadi sebulan sekali atau setahun sekali. Amazon menjelaskan dalam panduan transformasi aplikasi mainframe bahwa konversi awal dari COBOL ke Java mempertahankan perilaku yang sama, lalu sebuah langkah bernama Reforge memakai model bahasa besar untuk menata ulang kode dengan gaya Java modern. COBOL adalah bahasa pemrograman lama yang masih menjalankan banyak sistem perbankan dan mainframe; mainframe adalah server pusat berukuran besar tempat sistem inti organisasi besar berjalan.

Setiap langkah yang menulis ulang kode bisa mengubah detail kecil. Jadi tidak cukup jika pengembang membaca kode baru dan mengatakan kode itu tampak benar. Manajemen hanya punya satu pertanyaan: apakah sistem baru memberi hasil yang sama dengan sistem lama pada data yang sama? Jawabannya datang dari membandingkan hasil, bukan dari membaca kode.

Bandingkan hasil pada transaksi nyata yang sama

Ambil satu periode bisnis yang sudah tutup, misalnya bulan yang pembukuannya sudah ditutup, jalankan transaksinya di sistem baru, lalu bandingkan hasilnya dengan keluaran sistem lama. Yang dibandingkan:

• Angka akhir: total faktur, saldo, dan stok di akhir periode.
• Laporan: laporan bulanan yang diandalkan manajemen, baris demi baris.
• Yang dikirim ke sistem lain: berkas dan pesan yang dikirim ke bank, akuntansi, atau portal pemerintah.
• Penolakan dan kesalahan: transaksi yang ditolak sistem lama harus ditolak juga oleh sistem baru, dengan alasan yang sama.

Sebagian alat membantu persiapan, bukan penilaian. AWS Transform untuk mainframe, misalnya, menyusun rencana pengujian dari atribut kode, kompleksitas pekerjaan, dan jalur penjadwal dalam 3 tahap (konfigurasi, penentuan cakupan, dan peninjauan), lalu membuat skrip untuk mengumpulkan data uji dari mainframe dalam 4 tahap. Namun Amazon mengingatkan dalam panduan yang sama bahwa skrip itu harus dijalankan di mainframe Anda sendiri, dengan izin tim Anda. Alat menyiapkan; tim Anda yang menjalankan dan memutuskan. Untuk memeriksa datanya sendiri, Microsoft menyarankan membandingkan jumlah baris sebagai pemeriksaan cepat, lalu checksum sebagai pemeriksaan lebih dalam: checksum adalah angka yang dihitung dari data dan berubah jika satu karakter saja berubah.

Kasus langka: tanyakan kepada yang memahaminya

Transaksi nyata selama sebulan tidak mencakup semuanya. Kasus yang membuat sistem gagal diketahui oleh pemilik proses, bukan pengembang: tutup buku akhir tahun, retur sebagian atas faktur lama, pelanggan dengan harga khusus, faktur yang dibatalkan setelah diposting, gaji karyawan yang masuk di tengah bulan. Mintalah setiap pemilik proses menuliskan kasus yang mereka khawatirkan, lalu ubah setiap kasus menjadi uji dengan hasil yang diharapkan sudah ditulis sebelum dijalankan.

Di sinilah aturan yang Anda konfirmasi di bagian 4 kembali berguna: setiap aturan yang sudah dikonfirmasi menjadi setidaknya satu kasus uji. Aturan tanpa uji adalah aturan yang tidak bisa Anda pastikan selamat dari konversi. Tentang jenis-jenis pengujian itu sendiri, lihat panduan pengujian perangkat lunak dan penjaminan mutu kami.

Persetujuan manusia untuk setiap modul

Contoh terbitan yang paling jelas dari prinsip ini adalah alur migrasi sistem perbankan yang diumumkan Thought Machine bersama Amazon pada 29 September 2026. Alur ini terdiri dari 4 tahap: mengekstrak logika bisnis dari aplikasi lama dengan AWS Transform, menyatukan variasi yang berulang menjadi spesifikasi terpadu, menghasilkan produk keuangan baru beserta rangkaian ujinya dengan agen AI, dan tahap validasi yang memberi tim rekayasa dan tim risiko bank wewenang persetujuan yang tegas sebelum apa pun diterima. Bahkan setelah disetujui, hasilnya masuk ke lingkungan sandbox terisolasi untuk evaluasi lanjutan, bukan langsung ke produksi.

Pelajaran bagi perusahaan Anda tidak memerlukan bank maupun Amazon: setiap modul sistem, seperti penagihan, penggajian, atau persediaan, mendapat dua tanda tangan sebelum digunakan. Satu dari sisi teknis, yang memastikan semua uji sudah dijalankan, dan satu dari pemilik proses, yang memastikan hasilnya benar dari sisi bisnis. Microsoft meminta hal yang sama setelah peralihan: pemilik aplikasi memastikan semua fungsi utama berjalan dengan benar.

Menjalankan paralel dan rencana kembali

Menjalankan paralel berarti kedua sistem bekerja berdampingan selama periode tertentu, dengan sistem lama tetap menjadi acuan resmi. Sebelum mulai, tentukan kapan periode itu berakhir dan syarat apa yang membolehkannya berakhir, misalnya hasil yang cocok selama satu siklus bisnis penuh. Lalu atur peralihan seperti ini:

Rencana kembali bukan pengakuan kegagalan; ini asuransi. Tuliskan sejak awal apa yang membuat Anda kembali, misalnya kesalahan pada faktur atau terhentinya proses inti, siapa yang memegang keputusan itu, dan bagaimana pengguna kembali ke sistem lama. Jangan mematikan sistem lama secara permanen sebelum masa stabilisasi berakhir. Apa yang biasanya gagal pada minggu-minggu pertama setelah peralihan kami bahas di Tiga puluh hari pertama setelah migrasi.

Pandangan Origami

Kami memperlakukan peralihan sebagai keputusan manajemen, bukan peristiwa teknis. Karena itu kami membangun perbandingan antara kedua sistem sebelum membangun sistem barunya, dan sejak awal menyepakati kasus langka beserta hasil yang diharapkan bersama pemilik proses, sehingga definisi keberhasilan sudah tertulis sebelum siapa pun melihat hasilnya.

Kami memakai AI untuk mempercepat konversi dan membuat pengujian, tetapi persetujuan setiap modul tetap berada pada orang-orang tertentu di tim Anda. Untuk melihat cara kami bekerja, lihat layanan kami.

Latihan minggu ini: lembar peralihan untuk setiap modul

Untuk setiap sistem yang Anda pilih untuk dikonversi atau dibangun ulang di bagian 5, isi lembar ini bersama pemilik proses sebelum menetapkan tanggal peralihan apa pun:

Ini contoh ilustrasi; lembar Anda akan berbeda. Yang penting, jangan tetapkan tanggal peralihan sebelum setiap modul memiliki dua penanda tangan yang disebut namanya dan pemicu kembali yang tertulis.

Selanjutnya

Masih ada satu pertanyaan yang diajukan setiap manajer sebelum mengirim kode dan data ke alat AI: ke mana data saya pergi selama modernisasi? Bagian 7, bagian terakhir, menjawabnya dan merangkum latihan seluruh seri dalam rencana 90 hari.

Sumber

• Microsoft: Melaksanakan migrasi, Cloud Adoption Framework — rapat kriteria kembali, pembekuan perubahan, validasi data, pemantauan 24 hingga 48 jam, dan mempertahankan lingkungan sumber sebagai cadangan.
• Amazon: Transformasi aplikasi mainframe di AWS Transform — rencana pengujian, skrip pengumpulan data uji, dan langkah Reforge.
• Amazon: pengumuman Thought Machine dan AWS tentang migrasi sistem perbankan lama — empat tahap dan persetujuan oleh tim rekayasa dan tim risiko.
• AWS Transform: halaman resmi.