Aller au contenu principal

Migrer depuis un autre hébergeur Odoo

Déplacer une base Odoo existante vers Skysize se résume à trois choses : une sauvegarde propre de l'ancienne instance, un projet Skysize qui embarque le même code personnalisé, et une bascule de votre domaine. Ce guide parcourt tout le chemin, avec les vérifications qui évitent les échecs d'import les plus fréquents.

Il s'applique à toute origine : un autre hébergeur Odoo, un serveur que vous gérez vous-même, ou une instance locale. Les notes propres à certains hébergeurs sont en fin de page.

:::tip Vous migrez plusieurs bases ? Chaque base Odoo devient son propre projet Skysize. Suivez ce guide une fois par base, et répétez d'abord avec la plus petite. :::

1. Faire l'inventaire de l'ancienne instance​

Avant d'exporter quoi que ce soit, notez :

  • Version et édition d'Odoo, par exemple 17.0 Enterprise. L'import restaure la base sur la version avec laquelle elle a été créée. Le passage à une version plus récente est une étape distincte, réalisée après la migration.
  • Modules personnalisés et tiers : tout ce qui est installé et ne fait pas partie d'Odoo standard, et où se trouve leur code source. Ouvrez Applications, retirez le filtre Applications et filtrez sur Installé pour les lister. Vous aurez besoin du code source dans un dépôt Git.
  • Dépendances Python requises par ces modules.
  • Taille de la base et du filestore, pour savoir si la sauvegarde tient dans la limite d'envoi par navigateur sur l'hébergement managé (voir Importer une sauvegarde Odoo existante).
  • Utilisateurs PostgreSQL supplémentaires qui se connectent directement à la base : outils BI comme Power BI ou Metabase, utilisateurs de réplication, scripts de reporting, ou un utilisateur technique créé lors d'une migration précédente. L'import gère les traces qu'ils laissent dans le dump (voir l'étape 3). Ce qu'il faut prévoir, c'est un nouveau chemin d'accès aux données pour eux après le déménagement.
  • Domaine, e-mail sortant et intégrations : le domaine sur lequel les utilisateurs se connectent, le serveur SMTP, les systèmes externes qui appellent votre Odoo (prestataires de paiement, webhooks, EDI), et ceux qu'Odoo appelle en n'autorisant que des adresses IP connues.

2. Préparer le projet sur Skysize​

  1. Poussez les modules personnalisés dans un dépôt Git, avec les dossiers de modules à la racine. S'ils se trouvent dans des sous-dossiers, voir Organiser les modules dans des répertoires imbriqués. Ajoutez un requirements.txt pour les paquets Python, voir Installer des paquets Python. Si la base n'a aucun code personnalisé, créez un projet sans dépôt.
  2. Créez le projet et réglez la version et l'édition d'Odoo pour correspondre à l'ancienne instance. Une base Enterprise a besoin d'une branche Enterprise.
  3. Laissez le premier déploiement se terminer. La base vide qu'il crée sera remplacée par l'import. Ce qui compte, c'est que le build réussisse, ce qui prouve que les modules et paquets Python s'installent correctement sur la plateforme.

3. Exporter une sauvegarde propre​

L'import prend la sauvegarde .zip native d'Odoo : dump.sql, un dossier filestore/ et manifest.json. Voir Importer une sauvegarde Odoo existante pour le format et la limite de taille.

D'où vient la sauvegarde​

  • Le gestionnaire de bases de données d'Odoo (/web/database/manager, puis Backup au format zip) est la source la plus simple lorsqu'il est activé chez l'ancien hébergeur.

  • La fonction de sauvegarde de votre hébergeur produit généralement la même structure de zip. Vérifiez que l'archive contient dump.sql à sa racine avant de l'envoyer.

  • Un pg_dump manuel si vous avez un accès shell à l'ancien serveur. Ces options évitent toute référence aux rôles de votre ancien serveur dans le dump, même si l'import tolère aussi les dumps faits sans elles :

    pg_dump --no-owner --no-privileges --format=p votre_base > dump.sql

    Copiez ensuite le dossier filestore de cette base (<data_dir>/filestore/<nom de la base> d'après l'ancien odoo.conf) à côté, sous le nom filestore/.

Instructions de propriété et de privilèges​

Un dump fait sans --no-owner ou --no-privileges contient des instructions ALTER ... OWNER TO, GRANT, REVOKE et ALTER DEFAULT PRIVILEGES qui nomment des rôles PostgreSQL de votre ancien serveur, par exemple un lecteur Power BI ou un utilisateur technique issu d'une migration antérieure. Le gestionnaire de bases de données d'Odoo passe --no-owner mais pas --no-privileges, ses sauvegardes gardent donc les lignes GRANT dès que des utilisateurs supplémentaires avaient accès à la base.

Vous n'avez rien à nettoyer. L'import retire les instructions de propriété et de privilèges à la volée pendant la restauration, une sauvegarde venant de n'importe quel hébergeur s'importe donc telle quelle. Après l'import, la base appartient au rôle propre de la branche et aucun autre rôle n'existe, rien n'est perdu. Le log de restauration indique combien de lignes ont été ignorées.

4. Répéter sur une branche staging​

Importez d'abord la sauvegarde sur une branche staging, en suivant Importer une sauvegarde Odoo existante. Une restauration sur une branche staging est neutralisée automatiquement : les serveurs de messagerie sortante et les actions planifiées sont désactivés, la répétition ne peut donc ni envoyer d'e-mails ni appeler d'intégrations en production.

Vérifiez ensuite :

  • Les utilisateurs peuvent se connecter et la liste Applications montre les mêmes modules installés que l'ancienne instance.
  • Le log d'exécution ne contient aucun avertissement missing module ou module not found, voir Consulter les logs.
  • Les pièces jointes, images de produits et rapports PDF s'ouvrent, ce qui prouve que le filestore est bien passé.
  • Vos flux métier personnalisés se comportent comme avant.

Corrigez maintenant tout problème de module ou de dépendance dans le dépôt et redéployez. Répétez l'import jusqu'à ce que la répétition soit propre.

5. Basculer en production​

  1. Abaissez le TTL de l'enregistrement DNS de votre domaine la veille, pour que la bascule se propage vite.
  2. Annoncez une fenêtre de maintenance. L'ancienne instance continue de servir jusque-là.
  3. Arrêtez les écritures sur l'ancienne instance : arrêtez le service Odoo, ou bloquez les connexions.
  4. Faites une sauvegarde finale comme à l'étape 3.
  5. Importez-la sur la branche production. Une restauration en production n'est pas neutralisée, la base revient exactement telle qu'exportée.
  6. Passez en revue les vérifications post-import ci-dessous.
  7. Faites pointer votre domaine vers Skysize, voir Ajouter un domaine personnalisé.
  8. Gardez l'ancienne instance arrêtée mais intacte quelques jours avant de la décommissionner.

6. Après l'import​

  • URL de base : Odoo met à jour le paramètre système web.base.url à la prochaine connexion d'un administrateur, sauf si web.base.url.freeze est défini. Vérifiez-le dans Configuration → Technique → Paramètres système, sinon les liens dans les e-mails continuent de pointer vers l'ancien hébergeur.
  • E-mail sortant : le port 25 est bloqué, utilisez un relais SMTP chiffré sur le port 587 ou 465, voir Configurer l'e-mail sortant (SMTP).
  • Listes d'IP autorisées : l'adresse depuis laquelle votre Odoo se connecte a changé. Mettez à jour toute banque, prestataire de paiement ou API qui filtre sur l'IP source.
  • Intégrations entrantes : les webhooks, URL de retour des prestataires de paiement et URL de rappel SSO ou OAuth doivent pointer vers le nouveau domaine.
  • Accès direct à la base pour les outils BI : sur l'hébergement managé, il n'y a pas de connexion PostgreSQL directe. Utilisez l'API XML-RPC ou JSON-RPC d'Odoo, ou un connecteur pour votre outil BI. Sur les projets Bring Your Own Server, voir Accès direct à la base de données (lecture seule).
  • Actions planifiées : sur un import en production, elles sont actives dès le démarrage d'Odoo. Assurez-vous que rien ne s'exécute deux fois contre un système externe tant que l'ancienne instance est encore en marche.
  • Sauvegardes : les sauvegardes automatiques démarrent la première nuit. Consultez l'onglet Sauvegardes le lendemain, voir Gérer les sauvegardes.

Notes selon l'origine​

CloudPepper​

CloudPepper exécute Odoo sur un serveur qui vous appartient, vous pouvez donc utiliser le gestionnaire de bases de données d'Odoo ou lancer pg_dump vous-même comme à l'étape 3. Les bases issues de ces installations ont souvent des utilisateurs PostgreSQL supplémentaires (un utilisateur Power BI ou de reporting, un utilisateur technique créé pour une migration antérieure). Leurs sauvegardes contiennent des instructions GRANT pour ces utilisateurs, que l'import retire automatiquement : la sauvegarde s'importe telle quelle. Ce qu'il faut prévoir pour ces outils, c'est un nouveau chemin d'accès après le déménagement, voir l'étape 6.

Odoo.sh​

L'onglet Backups de votre projet Odoo.sh propose un téléchargement qui inclut le filestore. C'est le format zip natif d'Odoo, il s'importe directement. Votre code personnalisé est déjà dans le dépôt GitHub connecté à Odoo.sh : connectez le même dépôt à Skysize. S'il utilise des sous-modules, voir Inclure un dépôt externe (sous-modules).

Odoo Online​

Téléchargez une sauvegarde depuis le gestionnaire de bases sur odoo.com (Mes bases de données, puis Télécharger). Les bases Odoo Online tournent en édition Enterprise sans code personnalisé, un projet sans dépôt avec une branche Enterprise suffit donc.

Serveur auto-géré ou instance locale​

Utilisez le gestionnaire de bases de données s'il est activé, ou pg_dump avec les options de l'étape 3 plus le dossier filestore du répertoire de données.