Migration d'Odoo 17/18 vers Odoo 19 : Guide complet

La migration est l’une des opérations les plus risquées du cycle de vie d’un ERP : la perte de données, les modules personnalisés défectueux et les temps d’arrêt prolongés sont autant de risques réels qui nécessitent une planification et une exécution minutieuses.

Ce guide fournit une méthodologie de migration pratique, étape par étape, pour les organisations passant d'Odoo 17 ou Odoo 18 vers Odoo 19 Enterprise. Il couvre tout, de l'évaluation initiale et du mappage des données aux mises à jour des modules personnalisés, aux procédures de test et au plan de mise en service.

Points clés à retenir

• La compatibilité des modules personnalisés doit être vérifiée par rapport aux modifications de l'API d'Odoo 19
• La migration des données s'effectue via la plateforme de mise à niveau officielle d'Odoo ou OpenUpgrade
• Un environnement de test parallèle est obligatoire avant le basculement en production
• Les périodes financières doivent être clôturées avant le basculement pour éviter les problèmes de rapprochement
• Toutes les intégrations tierces doivent être revérifiées après la migration
• Le plan de restauration doit être documenté et testé avant la mise en service

---

Planification de la migration : phase d'évaluation

Avant d’écrire un seul script de migration, investissez du temps dans une évaluation approfondie. Les migrations échouent le plus souvent en raison d’une planification inadéquate et non de la complexité technique.

Étape 1 : Inventaire de votre environnement actuel

Documentez chaque composant de votre installation Odoo actuelle :

Current Environment Inventory:
- Odoo version: 17.0.x or 18.0.x
- Edition: Community or Enterprise
- Database size: X GB, Y records in sale.order, Z in account.move
- Installed modules: [list all modules]
- Custom modules: [list with developer contact]
- Third-party connectors: [Amazon, Shopify, etc.]
- Active integrations: [API, webhooks, cron jobs]
- Customized reports: [list]
- Custom fields (Studio or code): [list]
- Server specs: RAM, CPU, disk
- PostgreSQL version:

Étape 2 : Classer les modules personnalisés

Pour chaque module personnalisé, déterminez :

---

Choisir votre chemin de migration

Chemin 1 : Service de mise à niveau officiel Odoo

Odoo SA fournit un service de mise à niveau automatisé à upgrade.odoo.com. Vous soumettez votre base de données, ils exécutent des scripts de migration développés et maintenus par Odoo SA et vous recevez une base de données mise à niveau.

Avantages :

• Support et tests officiels par Odoo SA
• Gère automatiquement les modifications du schéma de base de données
• Convient à Odoo standard avec un minimum de personnalisations

Inconvénients :

• Nécessite la soumission des données de production aux serveurs d'Odoo
• Contrôle limité sur le processus de migration
• La migration des modules personnalisés est de votre responsabilité

Chemin 2 : OpenUpgrade (outil communautaire)

OpenUpgrade est un projet open source qui fournit des scripts de migration pour Community.

Chemin 3 : Nouvelle installation avec importation de données

Pour les instances fortement personnalisées ou les versions très anciennes :

1. Configurez une nouvelle instance Odoo 19 Enterprise
2. Reconfigurez tous les modules et paramètres
3. Exportez les données critiques de l'ancien système
4. Importez via l'outil d'importation d'Odoo ou des scripts de migration personnalisés
5. Ressaisir manuellement les soldes d'ouverture pour la comptabilité

Ce chemin est plus lent mais constitue le point de départ le plus propre.

Recommandé pour la plupart des migrations Odoo 17/18 → 19 : Chemin 1 ou 2 combiné à un effort parallèle de redéveloppement de modules personnalisés.

---

Préparation pré-migration

Clôture des périodes financières :

Avant la migration :

1. Verrouillez toutes les périodes avant le mois en cours dans Odoo Comptabilité
2. Exécutez les rapports chronologiques des créances et des dettes et réconciliez les différences
3. Rapprochez tous les relevés bancaires jusqu'à la date de migration
4. Publiez tous les projets de factures qui doivent être inclus dans les données historiques

Sauvegardez tout :

# PostgreSQL backup
pg_dump -h localhost -U odoo_user -Fc odoo_production > \
    odoo_prod_backup_$(date +%Y%m%d_%H%M%S).dump

# Filestore backup (attachments, images)
tar -czf odoo_filestore_$(date +%Y%m%d).tar.gz \
    /var/lib/odoo/.local/share/Odoo/filestore/

# Configuration backup
cp /etc/odoo/odoo.conf odoo_conf_backup_$(date +%Y%m%d).conf

---

Configuration de l'environnement de migration

Configuration de l'infrastructure :

# Install Odoo 19 Enterprise on migration server

# Install PostgreSQL 15+
sudo apt install postgresql-15 postgresql-contrib

# Install Python 3.12 and dependencies
sudo apt install python3.12 python3.12-dev python3.12-venv \
    libxml2-dev libxslt1-dev libldap2-dev libsasl2-dev \
    libtiff5-dev libjpeg8-dev libopenjp2-7-dev zlib1g-dev \
    libfreetype6-dev liblcms2-dev libwebp-dev libharfbuzz-dev \
    libfribidi-dev libxcb1-dev

# Clone Odoo 19 Enterprise
git clone https://github.com/odoo/odoo.git -b 19.0 /opt/odoo19
git clone https://github.com/odoo/enterprise.git -b 19.0 /opt/odoo19-enterprise

# Install Python dependencies
pip3.12 install -r /opt/odoo19/requirements.txt

---

Migration de modules personnalisés

Cette phase est la plus longue. Chaque module personnalisé nécessite :

1. Mettre à jour la version du manifeste :

# Change from:
'version': '17.0.1.0.0',
# To:
'version': '19.0.1.0.0',

2. Mettre à jour la syntaxe de la vue :

<!-- Old (v16 and earlier): -->
<field name="state" attrs="{'invisible': [('active', '=', False)]}"/>

<!-- New (v17+): -->
<field name="state" invisible="not active"/>

3. Testez chaque module indépendamment :

# Install and test each custom module
python3 odoo-bin -d test_db -i my_custom_module --stop-after-init
python3 odoo-bin -d test_db --test-enable -u my_custom_module

---

Validation et tests des données

Validation du nombre d'enregistrements :

Comparez le nombre d'enregistrements entre la base de données source et la base de données migrée :

# Run on both source and target to compare
models_to_check = [
    'res.partner', 'product.template', 'product.product',
    'sale.order', 'purchase.order', 'account.move',
    'stock.quant', 'mrp.production', 'hr.employee'
]

for model in models_to_check:
    count = env[model].search_count([])
    print(f"{model}: {count}")

Liste de contrôle des tests d'acceptation des utilisateurs :

• Tous les menus et éléments de navigation accessibles
• Flux de travail clés : commande client → livraison → facture → paiement
• Comptabilité : écritures de journal, rapprochement bancaire, rapports
• Inventaire : réceptions, livraisons, valorisation des stocks
• Fabrication : nomenclature, bons de travail, contrôles qualité (le cas échéant)
• RH : salariés, gestion des congés, paie (si applicable)
• Fonctionnalité du module personnalisé vérifiée par les utilisateurs professionnels
• Les rapports sont générés correctement et correspondent aux résultats d'avant la migration
• Intégrations externes (API, webhooks) testées en staging

---

Plan de transition de mise en ligne

Planification de la fenêtre de basculement :

Choisissez une fenêtre de basculement avec un impact commercial minimal :

• Week-end (du samedi soir au dimanche matin pour la plupart des entreprises)
• Fin du mois fiscal (simplifie la saisie du solde d'ouverture)
• Après le dernier jour ouvrable précédant un jour férié (délai tampon supplémentaire)

Liste de contrôle de transition :

T-48 hours:
[ ] Final communication to all users about downtime window
[ ] Freeze all non-critical transactions in old system
[ ] Verify migration server is ready
[ ] Complete last data validation run

T-0 (Cutover Start):
[ ] Put old system in maintenance mode (disable user access)
[ ] Create final backup of production database
[ ] Run final migration on this backup
[ ] Verify record counts and financial balances
[ ] Test all critical workflows
[ ] DNS/URL cutover to new system
[ ] Smoke test from user devices (desktop, mobile)

T+2 hours (Go-Live Verification):
[ ] All users can log in
[ ] Create test sale order, confirm, ship, invoice
[ ] Verify email sending works
[ ] Check integrations are receiving/sending data
[ ] Monitor error logs for first 30 minutes

Plan de restauration :

Si des problèmes critiques sont détectés lors du basculement :

1. Basculez le DNS vers l'ancien serveur
2. Réactivez l'ancien système pour les utilisateurs
3. Documentez tous les problèmes trouvés
4. Planifier une fenêtre de migration de suivi

---

Questions fréquemment posées

Puis-je passer directement d'Odoo 17 à Odoo 19, ou dois-je passer par 18 ?

En utilisant le service de mise à niveau officiel d'Odoo, vous pouvez généralement passer directement de la version 17 à la version 19. Les scripts de migration d'Odoo SA gèrent les sauts multi-versions. Vérifiez toujours dans le référentiel OpenUpgrade les versions spécifiques dont vous avez besoin.

Combien de temps dure une migration Odoo typique ?

La chronologie dépend fortement du niveau de personnalisation. La migration elle-même (mise à niveau de la base de données) prend des heures ; l’heure est aux tests, aux mises à jour des modules et à la validation.

Qu'arrive-t-il aux personnalisations de Studio pendant la migration ?

Les personnalisations du Studio sont stockées sous forme de données Odoo standard (vues, champs, automatisations) et migrent via le processus de mise à niveau standard de la base de données. Cependant, certaines personnalisations d'affichage peuvent nécessiter une révision manuelle si Odoo 19 modifie la structure sous-jacente du formulaire. Testez toujours toutes les personnalisations de Studio après la migration.

Dois-je saisir à nouveau les soldes d'ouverture après la migration ?

Non, si vous migrez directement la base de données. Toutes les écritures de journal et soldes historiques sont transférés avec la base de données. Si vous choisissez le chemin « nouvelle installation avec importation de données », vous devrez saisir les soldes d'ouverture à compter de la date de basculement, ce qui nécessite une coordination minutieuse avec votre équipe comptable.

---

Prochaines étapes

Les migrations Odoo sont des projets à forts enjeux qui impactent directement la continuité des activités. La différence entre une migration fluide et une migration douloureuse réside dans la préparation, l’expertise et une méthodologie de test rigoureuse.

Notre méthodologie de migration couvre une évaluation complète, des mises à jour de modules personnalisés, des tests parallèles et un plan de transition documenté avec des procédures de restauration.

Demander une évaluation de migration Odoo auprès d'ECOSIRE →