Artikel
Panduan Upgrade Odoo: Merencanakan Migrasi dari v14, v15 atau v16 ke v18
Rencana praktis upgrade Odoo dari v14, v15 atau v16 ke v18: apa saja yang terlibat, di mana custom module bermasalah, dan cara melakukan uji coba dengan aman.
- bottom
- odoo
Jika Anda menjalankan Odoo 14, 15 atau 16 dan ingin pindah ke 18, jawaban singkatnya: ini adalah sebuah proyek, bukan sekadar tombol. Odoo menyediakan layanan upgrade yang memigrasikan data dan skema standar. Yang tidak bisa dilakukan layanan itu adalah menulis ulang custom module Anda, melatih pengguna, atau memutuskan customization mana yang masih layak dipertahankan. Alokasikan waktu Anda untuk ketiga hal itu, bukan untuk alat upgrade-nya.
Panduan ini membahas apa yang dikatakan dokumentasi resmi Odoo tentang prosesnya, di mana usaha sebenarnya terkonsentrasi, dan urutan kerja yang menjaga risiko tetap rendah. Ditulis untuk pemilik usaha serta lead operasional atau IT yang perlu merencanakan, bukan untuk developer yang menjalankan perintahnya.
Mengapa tidak bisa bertahan selamanya
Menurut dokumentasi upgrade Odoo, setiap versi mayor mendapat dukungan tiga tahun, lalu database mendapat dua tahun tambahan untuk menyelesaikan upgrade. Halaman yang sama menyebutkan bahwa Anda boleh tetap di satu versi tanpa batas waktu, tetapi hal itu tidak direkomendasikan, dan database pada versi mayor harus di-upgrade setiap dua tahun.
Dihitung dari rilis Oktober tiap versi (2020, 2021 dan 2022), v14 sudah melewati masa dukungan maupun masa tambahan upgrade, v15 berada di akhir masa tambahannya, dan v16 sudah keluar dari dukungan tiga tahun tetapi masih dalam masa upgrade dua tahun. Periksa tanggal terkini untuk versi Anda langsung di sisi Odoo, karena kebijakan berlaku per database dan jenis hosting.
Bertahan punya biaya nyata: perbaikan dari vendor berkurang atau berhenti setelah dukungan berakhir, makin tidak kompatibel dengan aplikasi pihak ketiga dan konektor, dan lompatan yang makin besar di kemudian hari. Odoo sendiri mencatat bahwa semakin kecil selisih versi, semakin mudah upgrade-nya.
Satu catatan: Odoo merilis versi mayor baru setiap tahun, jadi 18 bukan rilis terbaru. Jika Anda merencanakan untuk akhir 2026 atau 2027, tanyakan apakah versi yang lebih baru adalah target yang lebih tepat sebelum berkomitmen. Versi 18 adalah jawaban yang masuk akal, tetapi harus menjadi keputusan, bukan default.
Apa yang dicakup upgrade, dan apa yang tidak
Dokumentasi tegas soal batasannya. Upgrade memindahkan database ke versi yang lebih baru dan didukung. Upgrade tidak mencakup:
- Downgrade.
- Pergantian edisi, misalnya Community ke Enterprise.
- Perubahan jenis hosting.
- Migrasi dari ERP lain.
Jika ingin mengganti edisi atau hosting sekaligus, perlakukan itu sebagai alur kerja terpisah dan jangan digabung dalam akhir pekan cutover yang sama.
Jalur yang didokumentasikan berbeda per hosting:
| Hosting | Cara kerja upgrade |
|---|---|
| Odoo Online | Rolling release. Untuk upgrade wajib, Odoo menjalankan test upgrade senyap terlebih dahulu, dan Anda juga bisa meminta test upgrade sendiri dari database manager. |
| Odoo.sh | Terintegrasi dengan platform upgrade. Backup produksi yang sudah di-upgrade dipulihkan di staging branch, dan setiap commit menjalankan ulang restore serta update module. |
| On-premise | Anda menjalankan script upgrade Odoo dari command line, dengan akses jaringan ke server upgrade. |
Tim yang memakai Odoo open source juga bisa melihat proyek OCA OpenUpgrade, yang di repositorinya digambarkan sebagai jalur upgrade open source untuk Odoo dan dikelola oleh Odoo Community Association. Ini jalur yang berbeda dengan jaminan yang berbeda, jadi pastikan cakupannya untuk versi dan module Anda sebelum mengandalkannya.
Di mana usaha sebenarnya: custom module
Ini kalimat terpenting dalam dokumentasi resmi: database dengan custom module tidak bisa di-upgrade sampai module tersebut tersedia untuk versi tujuan. Odoo menyarankan meminta test database sambil meng-upgrade kode custom Anda secara paralel.
Panduan Odoo tentang meng-upgrade database yang dikustomisasi memberi urutan yang masuk akal. Bagian yang perlu diketahui pengambil keputusan:
- Bekukan pengembangan. Perbaikan bug boleh. Fitur baru di versi lama hanya menambah tagihan migrasi.
- Pertanyakan setiap customization. Bandingkan dengan apa yang dilakukan Odoo standar di versi tujuan. Sebagian workaround di v14 mungkin kini menjadi fitur standar. Menghapus custom module adalah migrasi termurah.
- Buat module bisa diinstal di database kosong versi tujuan. Odoo mencantumkan masalah umum: dependensi tidak valid, perubahan sintaks (assets, OWL, attrs), field, view dan method yang dihapus atau diganti nama, serta XPath yang bergeser.
- Uji perilaku, bukan hanya instalasi. Module yang terinstal masih bisa salah saat dijalankan. View, email template, laporan, server action dan automated action, serta computed field semuanya perlu dicek, idealnya dengan automated test.
Semakin tua versi asal, semakin besar celahnya. Framework front-end dan sintaks view berubah cukup berarti di antara rilis-rilis ini, sehingga kode custom v14 biasanya butuh lebih banyak pengerjaan ulang daripada kode v16. Kami tidak akan menyebut angka, karena sepenuhnya bergantung pada banyaknya kode custom dan cara penulisannya.
Urutan kerja yang efektif
Berikut urutan yang akan kami rencanakan, diadaptasi dari langkah yang direkomendasikan Odoo.
1. Inventarisasi (minggu 1). Daftar aplikasi terpasang, custom module, customization Studio, aplikasi pihak ketiga, integrasi (pembayaran, pengiriman, e-commerce, ekspor akuntansi), laporan dan scheduled action. Tandai masing-masing: pertahankan, ganti dengan fitur standar, atau pensiunkan.
2. Minta test upgrade pertama. Lakukan sedini mungkin, sebelum pekerjaan custom apa pun. Tujuannya, menurut Odoo, memastikan upgrade standar berjalan dan Anda menerima test database yang bisa dipakai. Jika gagal, tim support Odoo ingin menerimanya lewat opsi upgrade testing, dan Anda perlu tahu sekarang.
3. Porting kode custom. Kerjakan dulu di database kosong versi tujuan, lalu di salinan data Anda yang sudah di-upgrade.
4. Uji bersama pengguna nyata. Perhatikan bahwa test database dikirim tanpa filestore, sehingga lampiran dan sebagian dokumen tidak akan berperilaku seperti di produksi sampai hal itu diperhitungkan. Minta orang menjalankan closing bulanan yang sebenarnya, siklus sales order sampai invoice, dan laporan yang mereka kirim ke auditor atau pemberi pinjaman.
5. Latih cutover. Ukur waktunya. Tentukan sebelumnya berapa lama produksi dibekukan, siapa yang menyetujui, dan apa rollback-nya. Rollback-nya sederhana: biarkan database produksi lama tidak tersentuh sampai Anda puas.
6. Go live dan pantau. Laporkan masalah pasca-upgrade dengan segera. Siapkan daftar singkat orang yang bisa memverifikasi angka di minggu pertama, terutama di akuntansi dan valuasi persediaan.
Melompati versi: satu kali atau bertahap?
Dokumentasi tidak memberi aturan pasti tentang berapa versi yang boleh dilompati dalam satu permintaan, hanya bahwa selisih yang lebih kecil lebih mudah. Dari v14 ke v18 berarti melintasi empat versi mayor perubahan, jadi harapkan lebih banyak siklus pengujian dan lebih banyak perbedaan yang harus diserap pengguna dibanding v16 ke v18. Jika taruhannya tinggi, tanyakan ke Odoo atau partner Anda jalur yang mereka rekomendasikan untuk hosting dan edisi Anda.
Risiko yang perlu direncanakan
- Akuntansi. Periksa saldo awal, konfigurasi pajak, fiscal position dan perubahan lokalisasi. Jika Anda beroperasi di UE atau Inggris, periksa pengaturan e-invoicing dan pelaporan pajak terhadap versi tujuan sebelum cutover.
- Integrasi. API, konektor dan webhook yang ditulis untuk versi lama mungkin perlu diubah.
- Pengguna. Meski tanpa kode custom, antarmuka dan sebagian alur kerja berbeda. Jadwalkan pelatihan, dan jangan menempatkan cutover di minggu tersibuk.
- Aplikasi pihak ketiga. Pastikan masing-masing punya rilis untuk versi tujuan, atau ada pengganti standar.
Soal biaya
Kami tidak akan menyebut angka karena sangat bervariasi menurut ukuran database, banyaknya kode custom, jumlah integrasi, dan seberapa banyak pengujian dilakukan internal. Aturan praktis: alat upgrade itu sendiri adalah pos terkecil dalam anggaran. Porting custom module, pengujian dan pelatihan adalah yang terbesar.
Langkah berikutnya
Jika Anda menimbang apakah pindah sekarang, menunggu versi yang lebih baru, atau memangkas customization dulu, kami senang membahasnya. Teknologia Solutions menawarkan percakapan tanpa biaya: kami meninjau versi Anda saat ini, custom module dan kendala Anda, lalu menyampaikan dengan jujur apakah upgrade memang langkah berikutnya yang tepat. Tanpa kewajiban, dan catatannya tetap milik Anda.
Sumber: Dokumentasi Odoo 18.0: Upgrade; Dokumentasi Odoo 18.0: Upgrade a customized database; OCA OpenUpgrade. Masa dukungan, prosedur hosting dan tooling berubah antar rilis, jadi verifikasi detailnya terhadap dokumentasi primer Odoo dan kontrak Anda sebelum merencanakan.