Rencana 30 Hari Migrasi dari Excel atau Google Form ke Sistem Assessment Institusi

Banyak institusi menunda migrasi dari Excel atau Google Form bukan karena tidak melihat manfaatnya, tapi karena membayangkan prosesnya sebagai proyek besar yang mengganggu operasional selama berbulan-bulan. Kenyataannya, migrasi yang direncanakan dengan baik bisa selesai dalam satu bulan — asal dipecah menjadi tahap yang jelas dan tidak dipaksakan sekaligus di minggu pertama.

Berikut rencana 30 hari yang bisa disesuaikan dengan skala institusi Anda, dibagi menjadi empat minggu dengan fokus berbeda.

Minggu 1: Audit Data dan Bersihkan Sebelum Pindah

Kesalahan paling sering dalam migrasi adalah memindahkan data yang sudah berantakan ke sistem baru, dengan harapan sistem baru akan "merapikannya sendiri". Ini jarang terjadi — data yang tidak konsisten di Excel akan tetap tidak konsisten setelah diimpor.

Minggu pertama sebaiknya dipakai untuk:

• Mengumpulkan seluruh data siswa (nama, kelas, cabang jika ada) ke satu format standar.
• Mengumpulkan bank soal yang masih relevan — buang soal yang sudah usang atau duplikat, jangan ikut dipindahkan hanya karena "sayang kalau dibuang".
• Menentukan struktur tagging kompetensi untuk bank soal, karena inilah yang membedakan sistem assessment sesungguhnya dari sekadar kuis online — soal perlu dikelompokkan per kompetensi, bukan cuma per bab.

Institusi yang melewati langkah audit ini biasanya baru sadar datanya bermasalah di minggu ketiga, saat sudah terlambat untuk memperbaiki tanpa mengulang dari awal.

Minggu 2: Impor Data dan Uji dengan Satu Kelas

Setelah data rapi, saatnya memindahkannya ke sistem baru. Untuk data siswa dan bank soal dalam jumlah besar, proses ini sebaiknya memakai fitur impor massal berbasis CSV, bukan input manual satu per satu — memasukkan ratusan siswa atau ribuan soal secara manual bukan hanya memakan waktu, tapi juga rawan salah ketik yang baru ketahuan saat ujian sudah berjalan.

Setelah data masuk, jangan langsung buka ke seluruh institusi. Uji dulu dengan satu kelas atau satu angkatan kecil. Minta guru kelas tersebut menjalankan satu ujian penuh — dari pembuatan soal, siswa mengerjakan, sampai guru meninjau hasil — untuk menangkap masalah kecil sebelum jadi masalah besar di skala penuh.

Minggu 3: Latih Staf dan Jalankan Paralel

Minggu ketiga adalah waktu untuk melatih guru dan staf administrasi menggunakan sistem baru, sambil tetap menjalankan sistem lama sebagai jaring pengaman. Menjalankan dua sistem sekaligus selama satu-dua minggu terasa merepotkan, tapi ini jauh lebih aman dibanding memutus sistem lama secara tiba-tiba sebelum tim benar-benar siap.

Fokus pelatihan minggu ini sebaiknya pada alur kerja harian yang paling sering dipakai: membuat ujian, menilai jawaban, melihat hasil per siswa, dan mengekspor laporan sederhana. Fitur yang jarang dipakai bisa menyusul setelah alur inti dikuasai.

Ini juga waktu yang tepat untuk menentukan siapa yang punya akses admin, siapa yang hanya guru, dan siapa yang perlu akses lihat-saja — struktur akses yang jelas sejak awal mencegah kebingungan siapa yang bertanggung jawab atas data apa begitu sistem lama benar-benar dimatikan.

Minggu 4: Cutover Penuh dan Pantau Ketat

Di minggu terakhir, sistem lama resmi dihentikan untuk aktivitas baru — meski data lamanya tetap disimpan sebagai arsip, bukan dihapus. Semua ujian, penilaian, dan pelaporan baru berjalan sepenuhnya di sistem baru.

Dua minggu pertama setelah cutover biasanya masih menghasilkan pertanyaan dan kesalahan kecil dari staf yang lupa langkah tertentu. Ini normal. Yang penting institusi punya jalur cepat untuk menjawab pertanyaan tersebut — baik lewat admin internal yang sudah dilatih lebih dulu, maupun lewat dukungan dari vendor sistem.

Menangani Musim Sibuk yang Bertabrakan dengan Jadwal Migrasi

Rencana 30 hari ini mengasumsikan kondisi operasional yang relatif normal. Kenyataannya, banyak institusi baru serius mempertimbangkan migrasi justru menjelang musim sibuk — tryout, ujian akhir semester, atau pendaftaran siswa baru — karena di situlah kelemahan sistem lama paling terasa. Kalau ini kondisi Anda, penting jujur menilai apakah 30 hari ke depan benar-benar realistis, atau justru bertabrakan dengan periode yang seharusnya dihindari untuk perubahan besar.

Aturan praktis yang aman: hindari memulai minggu keempat (cutover penuh) tepat berdekatan dengan hari pertama musim sibuk. Kalau musim tryout dimulai dalam tiga minggu, misalnya, lebih aman menunda mulai migrasi sampai musim tersebut selesai, dibanding memaksakan cutover di tengah periode paling sensitif operasional institusi.

Kalau menunda benar-benar tidak memungkinkan karena alasan bisnis tertentu, opsi lain adalah memperlambat rencana ini menjadi 45 atau 60 hari, dengan sengaja menjadwalkan minggu-minggu paling menuntut secara operasional sebagai jeda dari tahap migrasi — bukan memaksakan audit data atau pelatihan staf berjalan bersamaan dengan periode ujian besar. Migrasi yang terburu-buru karena tenggat yang dipaksakan biasanya menghasilkan lebih banyak masalah dibanding migrasi yang sedikit lebih lambat tapi berjalan di waktu yang tepat.

Kenapa 30 Hari, Bukan Lebih Cepat atau Lebih Lambat

Migrasi yang dipaksakan dalam satu-dua minggu biasanya melewatkan tahap audit data, sehingga masalah muncul justru saat musim ujian sudah dekat — waktu paling buruk untuk debugging data. Sebaliknya, migrasi yang diulur lebih dari sebulan sering kehilangan momentum: staf yang sudah mulai belajar sistem baru lupa lagi karena jeda terlalu panjang antar tahap.

Tiga puluh hari cukup panjang untuk melakukan audit data dengan benar dan menguji sebelum rollout penuh, tapi cukup pendek untuk menjaga momentum dan urgensi tim. Yang membuat rencana ini berhasil bukan jumlah harinya secara persis, tapi disiplin menjalankan tiap tahap secara berurutan tanpa melompati audit data di awal.