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

La mise à niveau vers Odoo 19 Enterprise offre des améliorations significatives en termes de performances, d'expérience utilisateur et de fonctionnalités assistées par l'IA. Mais 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 migration Odoo 19 nécessite la mise à jour d'une version majeure à la fois (17→18→19 ou 17→19 directement avec OpenUpgrade)
• 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
• Prévoyez un calendrier de migration total de 3 à 8 semaines en fonction de la complexité
• 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: (minimum 15 required for Odoo 19)

Étape 2 : Classer les modules personnalisés

Pour chaque module personnalisé, déterminez :

Étape 3 : Identifiez les modifications majeures d'Odoo 19

Changements clés entre Odoo 17/18 et Odoo 19 qui affectent les modules personnalisés :

• OWL 3.x : les composants frontend doivent être migrés à partir des modèles OWL 2.x
• Python 3.12 : Certaines syntaxes Python 3.10/3.11 peuvent nécessiter un ajustement
• PostgreSQL 15+ : version minimale requise ; certains modèles de requête changent
• Dépréciations de l'API : plusieurs méthodes _legacy supprimées ; vérifiez _multi → _create_multi
• Moteur de rapports : Certaines variables de rapport QWeb renommées
• Refactoring du déplacement de compte : les modifications de la structure de ligne account.move affectent les personnalisations comptables

---

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 :

• Ne gère pas les modules personnalisés
• 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 et Enterprise.

# Clone OpenUpgrade for Odoo 19
git clone https://github.com/OCA/OpenUpgrade.git -b 19.0

# Install upgrade dependencies
pip install openupgradelib

# Run migration
python odoo-bin --config=upgrade.conf \
    --update=all \
    --load=base,web,openupgrade_framework

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 (semaines 1-2)

Préparation de la base de données :

-- Run on source database before export
-- Identify orphaned records
SELECT id, name FROM res_partner WHERE active = FALSE AND id NOT IN (
    SELECT partner_id FROM sale_order
    UNION SELECT partner_id FROM account_move
    UNION SELECT partner_id FROM stock_picking
);

-- Archive old draft records (reduces migration time)
UPDATE sale_order SET active = FALSE
WHERE state = 'draft' AND date_order < NOW() - INTERVAL '2 years';

-- Verify accounting reconciliation
SELECT COUNT(*) FROM account_move_line
WHERE reconciled = FALSE AND debit != credit;

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 -p 5433 -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

Révision du code du module personnalisé :

Pour chaque module personnalisé, effectuez une vérification de compatibilité :

# Check for deprecated patterns
grep -r "execute_kw" custom_modules/   # Still valid in v19
grep -r "browse\(\[" custom_modules/  # Should be browse(ids) not browse([ids])
grep -r "_multi" custom_modules/      # Check for renamed methods
grep -r "account\.move\.line\." custom_modules/  # Account refactoring affected
grep -r "@api\.one" custom_modules/   # Removed in v14, ensure not present
grep -r "@api\.multi" custom_modules/ # Removed in v14, ensure not present

---

Configuration de l'environnement de migration (semaine 2-3)

Configuration de l'infrastructure :

# Install Odoo 19 Enterprise on migration server
# Requirements: Ubuntu 22.04/24.04, PostgreSQL 15+, Python 3.12

# 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

Restaurer la base de données source sur le serveur de migration :

# Create target database
createdb -h localhost -U postgres odoo_migration_test

# Restore backup
pg_restore -h localhost -U postgres -d odoo_migration_test \
    odoo_prod_backup_YYYYMMDD.dump

# Run Odoo upgrade
python3 /opt/odoo19/odoo-bin \
    -d odoo_migration_test \
    -u all \
    --without-demo=all \
    --stop-after-init

---

Migration de modules personnalisés (semaines 3 à 5)

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 compatibilité Python :

# Old pattern (deprecated):
@api.multi
def my_method(self):
    for record in self:
        pass

# New pattern:
def my_method(self):
    for record in self:
        pass

3. 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"/>

4. Mettre à jour les composants OWL (le cas échéant des widgets frontend) :

OWL 3.x introduit des changements de réactivité. Si vos modules utilisent des widgets JavaScript personnalisés :

// Old OWL 2.x:
class MyWidget extends Component {
    static template = 'MyModule.MyWidget';
    willStart() { ... }
}

// New OWL 3.x:
class MyWidget extends Component {
    static template = 'MyModule.MyWidget';
    setup() {
        onWillStart(async () => { ... });
    }
}

5. 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 (semaines 5 à 6)

Validation des données financières :

-- Verify balance sheet balances (assets = liabilities + equity)
SELECT
    SUM(CASE WHEN account_type LIKE 'asset%' THEN balance ELSE 0 END) as assets,
    SUM(CASE WHEN account_type LIKE 'liability%' THEN balance ELSE 0 END) as liabilities,
    SUM(CASE WHEN account_type = 'equity' THEN balance ELSE 0 END) as equity
FROM account_account aa
JOIN account_move_line aml ON aml.account_id = aa.id
JOIN account_move am ON aml.move_id = am.id
WHERE am.state = 'posted';

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 (semaines 7 et 8)

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 (< 5 minutes)
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. Avec OpenUpgrade, vous devrez peut-être passer à 17→18→19 en fonction des scripts de migration disponibles. 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. Une instance Odoo standard avec un minimum de personnalisations : 2-3 semaines. Modérément personnalisé (5 à 10 modules personnalisés) : 4 à 6 semaines. Fortement personnalisé avec des intégrations complexes : 8 à 16 semaines. 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.

Ma licence Odoo Enterprise sera-t-elle transférée vers la version 19 ?

Oui. Les abonnements Odoo Enterprise sont indépendants de la version. Votre abonnement annuel couvre quelle que soit la version que vous utilisez. Contactez votre partenaire Odoo pour obtenir le code Odoo 19 Enterprise si vous n'y accédez pas via le référentiel Git d'Odoo avec vos identifiants d'entreprise.

---

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.

ECOSIRE a migré avec succès des dizaines d'instances Odoo des versions 13, 14, 15, 16, 17 et 18 vers Odoo 19 Enterprise. 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 →

Nous évaluerons votre environnement actuel, identifierons tous les risques de migration et vous fournirons un plan de migration à portée fixe afin que vous sachiez exactement à quoi vous attendre avant l'exécution du premier script de migration.