Reprise après migration Enterprise

Récupérer les données qu'une migration d'Odoo Enterprise vers Community a laissées de côté, les reloger quand c'est possible, et contrôler ce qui reste à régler.

Symbifox 18.0 (catalogue de septembre 2026) · Modules : Reprise après migration Enterprise · Révisé le 2026-09-19

L'application Reprise Enterprise sert une seule fois dans la vie d'une organisation, le jour où elle quitte Odoo Enterprise pour Community. Une migration abandonne une partie des données par construction, parce qu'une base Community n'a tout simplement pas de place pour elles. Cette application reçoit ce que la migration a mis de côté, le garde, le reloge vers son équivalent libre quand il en existe un, et passe ensuite l'instance en revue pour dire ce qui reste à finir. Elle s'adresse à la personne qui pilote la migration, pas à l'équipe qui utilisera le résultat.

Vue d'ensemble#

Trois mots reviennent dans toute l'application et valent la peine d'être posés. Une reprise est un dépôt : un fichier reçu de l'outil de migration, avec tout ce qu'il n'a pas pu placer. Une table reprise est un ensemble de données de même nature à l'intérieur de ce dépôt, par exemple les billets d'assistance ou les articles de la base de connaissances. Reloger veut dire recréer ces données dans l'application Symbifox qui correspond, quand une correspondance existe.

L'ordre compte, et il est délibéré. L'application garde d'abord, elle reloge ensuite. Tout ce qui arrive dans le dépôt devient consultable et cherchable, qu'une destination existe ou non : avant de savoir où mettre un billet d'assistance, il faut ne pas l'avoir perdu. C'est ce qui distingue l'approche des scripts de migration habituels, qui traitent ce qu'ils savent traiter et laissent le reste disparaître avec la copie de départ.

La fiche d'une reprise réunit tout ce qu'il faut savoir : d'où vient le fichier, ce qu'il contient, et ce que chaque table est devenue.

Cette application touche à plusieurs autres, sans jamais s'y substituer. Les billets repris arrivent dans Assistance, les articles dans Base de connaissances, les modèles de signature dans Signatures électroniques et les plans d'abonnement dans Abonnements. Les contrôles d'après-migration, eux, regardent la configuration générale de l'instance et recoupent ce qui se règle dans Paramètres et identité de marque.

Configuration#

Accès et droits#

Un seul groupe, Gestion de la reprise, et il est haut placé : l'administration système l'ouvre automatiquement. Ce choix est volontaire. Reloger écrit des enregistrements dans les applications métier à partir d'un fichier déposé, et les contrôles lisent la configuration de l'instance : ce n'est pas un droit qui se distribue à l'équipe. Une personne qui n'a pas ce groupe ne voit ni le menu ni les données.

Les reprises sont cloisonnées par société : une reprise appartient à la sienne et reste invisible des autres.

Paramètres#

Aucun. L'application ne pose aucun réglage dans Paramètres et n'a pas de menu de configuration. Tout ce dont elle a besoin voyage dans le fichier déposé.

Données de base#

Rien à créer d'avance non plus, à une exception près : les applications d'arrivée doivent être installées pour que le relogement correspondant soit possible. Si la base de connaissances n'est pas installée, par exemple, les articles sont conservés et mis de côté, nommément, plutôt que de faire échouer le reste. L'application le dit sur la table concernée et poursuit avec les autres.

Premiers pas#

Ce parcours part du fichier que l'outil de migration a écrit à côté de la copie de départ, et va jusqu'à une première table relogée. Sur la démonstration de Boréal Services-conseils, il porte dix tables et soixante et un rangs.

1. Ouvrez Reprise Enterprise › Reprises, puis Nouveau.
2. Donnez un nom à la reprise, par exemple « Migration Boréal Services-conseils », et déposez le fichier reçu de l'outil de migration.
3. Sélectionnez Lire le fichier. L'application vérifie qu'il s'agit bien d'un fichier de reprise, en relève la provenance, et crée une entrée par table trouvée.
4. Parcourez l'onglet Tables. Chaque ligne dit combien de rangs elle porte, vers quoi elle irait, et où elle en est.
5. Sur une table qui a une correspondance, sélectionnez Aperçu. Les dix premiers enregistrements s'affichent tels qu'ils seraient créés, avec la liste de ce qui a été écarté et pourquoi. Rien n'est encore écrit.
6. Si l'aperçu vous convient, sélectionnez Reloger. Les enregistrements sont créés, et la fiche d'origine garde le lien vers ce qu'elle est devenue.
7. Répétez pour les autres tables, ou revenez sur la reprise et sélectionnez Reloger tout ce qui a une correspondance une fois les aperçus passés.

Le résultat visible : la reprise passe à l'état Traité, le compteur Relogés monte, et chaque table porte son état.

Tâches courantes#

Déposer un fichier de reprise#

L'outil de migration écrit son fichier à côté de la copie de départ. Il se dépose ici comme n'importe quelle pièce jointe, sans accès particulier au serveur.

1. Ouvrez Reprise Enterprise › Reprises, puis Nouveau.
2. Nommez la reprise et déposez le fichier.
3. Sélectionnez Lire le fichier.

La provenance apparaît : la base d'origine, sa version, le nom du fichier source et la date d'export. Le fil de la fiche note ce qui a été lu.

Regarder avant d'écrire#

L'aperçu est la seule façon de savoir ce qu'une correspondance donnera chez vous, parce qu'il dépend de vos données.

1. Ouvrez Reprise Enterprise › Tables reprises.
2. Ouvrez une table qui porte une correspondance.
3. Sélectionnez Aperçu.

Les dix premiers enregistrements s'affichent avec les valeurs qui seraient écrites, et, pour chacun, ce qui a été écarté. Une référence vers un contact qui n'existe plus est nommée plutôt que devinée, et une valeur que le champ d'arrivée n'offre pas est signalée. Fermez la fenêtre : rien n'a été créé.

Reloger une table#

Une fois l'aperçu passé, le relogement crée les enregistrements dans l'application d'arrivée.

1. Depuis la table, sélectionnez Reloger.
2. Confirmez.

Le compteur Relogés de la table monte, son état passe à Relogée, et chaque rang garde le lien vers la fiche qu'il est devenu. Si un rang échoue, il est le seul : son message est consigné sur lui, l'état de la table devient Partielle, et les autres sont passés.

Reprendre les tables qui n'ont pas de destination#

Six tables de la démonstration n'ont aucune correspondance, et c'est normal : rien dans Community ne leur ressemble. Elles restent consultables, cherchables et exportables comme n'importe quelle liste, ce qui permet de les traiter à la main, de les verser ailleurs, ou simplement de les garder le temps d'un doute.

Passer les contrôles d'après-migration#

À faire une fois la reprise traitée, et à refaire après chaque correction.

1. Ouvrez Reprise Enterprise › Tout vérifier.
2. Lisez la colonne Constat de chaque ligne.
3. Corrigez ce qui est à corriger, puis relancez le contrôle concerné avec Vérifier.
4. Pour les deux contrôles qui se font à la main, faites le geste puis sélectionnez Réglé.

Les menus, un à un#

Reprise Enterprise est le menu racine de l'application. Il ne porte pas d'écran : il regroupe les quatre entrées qui suivent.

Reprise Enterprise › Reprises liste les fichiers déposés, avec leur base d'origine, le nombre de tables et de rangs, le nombre d'enregistrements relogés et l'état du dépôt. C'est l'entrée par laquelle on commence, et celle par laquelle on revient pour relancer un relogement.

Reprise Enterprise › Tables reprises liste toutes les tables de tous les dépôts, de la plus fournie à la plus légère, avec leur correspondance et leur état. C'est la vue de travail : on y ouvre une table, on regarde l'aperçu, on reloge.

Reprise Enterprise › Contrôles liste les dix contrôles d'après-migration avec leur catégorie, leur état, leur constat et la date de la dernière vérification. Chaque ligne porte Vérifier pour relancer le contrôle et Réglé pour le marquer traité.

Reprise Enterprise › Tout vérifier n'ouvre pas d'écran à proprement parler : l'entrée relance les contrôles automatiques et affiche aussitôt leur liste à jour.

Référence#

Champs du formulaire Reprise#

Champs du formulaire Table reprise#

Rapports et exports#

Aucun rapport imprimable. Les tables et les rangs repris s'exportent comme n'importe quelle liste de Symbifox, ce qui est la voie de sortie pour les données qui n'ont pas de destination.

Automatisations#

Aucune. Rien ne se déclenche tout seul, et c'est voulu : l'application écrit dans vos données métier à partir d'un fichier, et chaque écriture part d'un geste. Les contrôles eux-mêmes ne tournent que lorsqu'on les lance.

Modules qui enrichissent cette application#

Comprendre#

Pourquoi un deuxième outil plutôt qu'un seul. La migration démolit la base de départ et en reconstruit une neuve : elle ne peut pas tourner depuis l'intérieur de celle qu'elle remplace. Cette application, elle, vit dans l'instance d'arrivée une fois que celle-ci existe. C'est ce qui lui permet de se contenter d'un fichier déposé sur un formulaire, sans accès à vos serveurs ni à vos bases.

Pourquoi les données ne sont pas simplement importées. Une base Community n'a pas de place pour elles. Le nom d'une table de départ peut même exister des deux côtés en désignant deux choses différentes, et une importation directe écraserait alors des données saines. Passer par un fichier rend la chose visible et réversible.

Pourquoi chaque correspondance annonce ses limites. Une étape d'assistance, un délai de service, la position des cases d'une signature ou la récurrence d'un abonnement n'ont pas d'équivalent exact. Les recréer approximativement donnerait des fiches qui ont l'air complètes et ne le sont pas. L'application préfère le dire avant d'écrire, et laisser le travail de reconstitution à qui connaît le dossier.

Pourquoi les références sont vérifiées une par une. La migration conserve les identifiants, donc un contact repris pointe souvent encore sur la bonne fiche. Souvent n'est pas toujours : un responsable parti, une étape qui n'existe plus de ce côté-ci. Chaque référence est donc cherchée dans l'application d'arrivée, et écartée avec sa raison quand elle ne se résout pas.

Pourquoi un contrôle a trois réponses. « Rien à faire » veut dire qu'il a regardé. « À corriger » veut dire qu'il a trouvé. « Non vérifiable » veut dire qu'il n'a pas pu regarder, parce que l'application dont il a besoin n'est pas là ou que la donnée manque. Confondre la troisième avec la première est la façon la plus simple de croire une migration terminée alors qu'elle ne l'est pas.

Le contrôle qui passe en premier. Un code de langue ou de fuseau horaire qui n'existe pas ne se contente pas de déparer : l'instance lève une erreur à chaque opération qui le résout, et le message nomme le code plutôt que la fiche qui le porte. C'est le genre de défaut qui immobilise une migration une demi-journée, et il se détecte en une seconde.

Dépannage#

Voir aussi#

• Assistance (billets)
• Base de connaissances
• Signatures électroniques
• Abonnements
• Paramètres et identité de marque
• Gestion d'hébergement