Migrasi & Rollout

Catera awalnya dibangun di atas Convex, lalu dipindahkan ke Supabase sebagai backend aktif. Strategi rollout dirancang supaya tiap tahap bisa diverifikasi dan dibatalkan sendiri-sendiri, bukan satu migrasi besar sekali jalan.

Prinsip rollout

1. Flag tunggal di level build — VITE_BACKEND_PROVIDER menentukan backend aktif untuk seluruh aplikasi. Lihat Gambaran Arsitektur.
2. Landing zone generik dulu, tabel kanonik kemudian — data yang dipindah dari Convex mendarat dulu di public.legacy_documents (JSONB apa adanya), baru domain demi domain mendapat tabel kanonik bertipe. Lihat Skema Data & Tabel Kanonik.
3. Baca dual-mode dengan pengecekan kesiapan — kode baru membaca tabel kanonik setelah flag domain terkait diaktifkan dan jumlah baris legacy vs. kanonik untuk domain itu sudah sama. Selama belum, otomatis fallback ke legacy_documents tanpa downtime.
4. Keamanan tidak menunggu migrasi data selesai — RLS dan RPC can_manage_* diterapkan sejak awal cutover, bukan ditambahkan belakangan setelah semua tabel kanonik siap.

Proses impor data (sekali jalan, dapat diulang)

Skema terpisah migration menyimpan jejak setiap proses impor dari Convex:

• migration.runs — satu baris per proses impor (status, waktu mulai/ selesai, ringkasan jumlah baris sumber vs. tujuan).
• migration.convex_documents — salinan mentah dokumen Convex per tabel, dipakai sebagai sumber untuk mengisi legacy_documents maupun tabel kanonik.
• migration.id_map — pemetaan ID dokumen Convex ke UUID Supabase, supaya referensi antar-tabel tetap konsisten setelah pindah.
• migration.storage_map — status pemindahan berkas (foto profil, dsb.) dari storage Convex ke Supabase Storage.

Skema ini ditutup total dari public/akses klien — murni alat kerja proses migrasi, bukan tabel yang dibaca aplikasi.

Status rollout saat ini

Dokumentasi ini tidak mencantumkan tanggal cutover, jumlah data produksi, atau host/project aktif — detail operasional semacam itu tercatat di catatan rilis internal tim (bukan untuk dipublikasikan). Yang perlu diketahui pembaca teknis:

• Jalur Convex tetap ada di kode sebagai jalur rollback, bukan backend aktif — lihat flag VITE_BACKEND_PROVIDER di Gambaran Arsitektur.
• Migrasi berjalan per domain, bukan serentak — sebagian domain sudah punya tabel kanonik, yang lain masih di legacy_documents. Status detail per migrasi tersedia di riwayat supabase/migrations/.

Perlu verifikasi

Jumlah domain yang sudah sepenuhnya kanonik vs. masih legacy bisa berubah seiring migrasi lanjutan berjalan. Jangan jadikan daftar di halaman ini sebagai status real-time — rujuk riwayat migrasi di repo app untuk status terkini.

---

Sumber: supabase/migrations/0001_migration_control.sql, src/lib/backend-provider.ts, src/features/hr/supabase-hr.ts, direktori supabase/migrations/.