Vous venez de recevoir un avis de fin de soutien de l’éditeur de votre ERP parce que vous avez trois versions de retard. Pour ajouter l’insulte à l’injure, vous devez payer un supplément pour le soutien. Vous savez que la mise à niveau d’un ERP, c’est tout ou rien : les finances, les stocks, les commandes et le plancher changent ensemble, ou pas du tout.
Deux vraies décisions en une. Restez-vous avec l’éditeur de votre ERP actuel? Vers quelle version migrez-vous? Nous vous aidons à répondre aux deux.
Proslat avait 60 jours pour quitter NetSuite avant une mise en production le 1er janvier, en pleine période des Fêtes, avec des liens EDI vers Home Depot, Costco, Canadian Tire et Amazon qui ne pouvaient pas tomber. Nous avons livré la migration à temps et dans le budget : plus de 100 personnalisations et intégrations, le tout dans la fenêtre de 60 jours, avec une décision ferme prise dès le départ sur ce qui devait fonctionner le premier jour et ce qui pouvait suivre après la mise en production. Selon les propres comparaisons du client, ce genre de migration fait généralement perdre environ 10 % des ventes pendant la transition. Proslat n’en a perdu aucune.
La pression d’une date pousse les équipes à imaginer une migration par morceaux : garder une partie de l’ancien système, mettre en place une partie du nouveau, gagner du temps. Un ERP ne fonctionne pas comme ça. C’est le seul système où tout doit concorder avec tout, à chaque minute, et le couper en deux signifie faire mal fonctionner deux systèmes pendant que l’échéance approche. Quand la migration a lieu, tout migre.
Le choix ne porte donc pas sur la quantité à migrer ; il porte sur le chemin. Les deux questions du début (rester avec votre éditeur ou changer, et vers quelle version aller) se résument à trois chemins honnêtes : une mise à niveau vers une version soutenue de votre éditeur actuel, un changement complet de plateforme, ou l’achat d’un soutien prolongé pour vous donner le temps de bien faire l’un ou l’autre. Ils mènent tous à la même fin, une bascule unique, mais diffèrent énormément en risque, en coût et en temps en cours de route. Et parfois, la réponse honnête est la troisième : gagner du temps pour ne pas précipiter une migration tout ou rien contre une date que vous n’avez pas choisie. Nous vous disons clairement ce que votre date permet.
Le système entier migre ; ce qui varie, c’est ce que vous emportez et ce que vous laissez derrière. L’Implementation Blueprint fait l’inventaire de ce que vous avez bâti : les personnalisations, les intégrations, les données et les contrôles de conformité. Il détermine ce qui passe proprement, ce qui doit être rebâti dans la nouvelle version et ce qui n’existait que pour contourner une limite que la nouvelle version règle déjà. Vous obtenez une architecture d’intégration qui montre les flux de données réels et les frontières des interfaces, ainsi qu’un plan de bascule avec rapprochement, validation, répétitions (des bascules simulées et chronométrées, reprises jusqu’à ce que la conversion des données tienne dans la fenêtre) et un déclencheur de retour arrière, le tout dimensionné selon votre date. Le plan précise aussi, heure par heure, ce qui arrive aux commandes prises pendant le gel et comment les bons de commande ouverts et les travaux en cours sont transférés. Vous choisissez un chemin avec les risques déjà sur la table. Le Blueprint lui-même est à prix fixe, convenu avant le début des travaux, et le plan vous appartient, peu importe le chemin choisi.
Voir comment le Blueprint cartographie votre migrationUne migration qui respecte l’échéance, mais qui laisse votre équipe incapable de maintenir ce qui a changé, n’est pas une réussite. Nous bâtissons le travail de rapprochement et d’intégration pour que vos gens puissent l’exploiter, et nous documentons ce qui a migré et pourquoi dans des guides d’exploitation qui appartiennent à votre équipe, pour que le savoir reste chez vous. Tout ce que vous préférez que nous continuions d’exploiter, nous l’exploitons selon une portée convenue. La plupart des équipes qui font un Blueprint nous gardent pour la migration elle-même, pour une raison qu’un architecte reconnaîtra : le plan résiste à l’examen.
Non, et méfiez-vous de quiconque vous dit le contraire. Les finances, les stocks et les commandes doivent concorder à chaque minute ; faites fonctionner la moitié de votre entreprise dans chacun de deux systèmes et ils cessent de concorder, alors que votre échéance approche toujours. (Les entreprises multisites migrent parfois leurs sites par vagues, mais chaque site migre quand même d’un seul coup. Il n’existe pas de scénario où une même entreprise fonctionne à moitié migrée.) Ce qui peut être étalé, c’est le travail autour de la migration : le nettoyage des données, la reconstruction des intégrations, la formation et les répétitions, le tout avant la bascule unique.
Cela dépend du chemin. Une mise à niveau sur place conserve la plus grande partie de ce que vous avez bâti. Un passage à une nouvelle génération ou à une autre plateforme rebâtit davantage, et certaines personnalisations ne devraient pas suivre du tout, parce qu’elles ne faisaient que masquer une limite que la nouvelle version règle. Le Blueprint vous dit lesquelles avant que vous vous engagiez, pour que vous ne le découvriez pas en plein projet, contre une échéance.
Des projets différents, une même fin : une bascule unique où toute l’entreprise migre. Une migration vous amène à une version plus récente chez l’éditeur que vous utilisez déjà et conserve la plus grande partie de ce que vous avez bâti. Un remplacement vous amène vers la plateforme d’un autre éditeur et rebâtit davantage. Nous vous dirons clairement ce que votre échéance permet, et nous ne gonflons pas une migration en remplacement.
Oui, dès la conception. Nous traitons les contrôles de conformité et leur traçabilité comme des éléments qui doivent migrer intacts, et nous planifions la bascule pour qu’il n’y ait aucune fenêtre où la piste d’audit est rompue. La continuité de la conformité est une exigence que nous intégrons dès la première séance de planification.
Un prix fixe, convenu avant le début des travaux. L’échéance change l’ordre du travail, et le prix reste celui qui a été convenu. Les détails sur les honoraires se trouvent sur la page de l’Implementation Blueprint. Et peu importe le chemin que la date permet, le plan vous appartient.
Parfois, attendre est la bonne décision, et le soutien prolongé est une façon légitime de se donner le temps d’une migration plus sûre. Nous vous présenterons ce que chaque chemin coûte et comporte comme risques, pour que la décision vous revienne, prise sur de vrais chiffres et selon votre propre calendrier.
Parce que la bascule est répétée avant d’avoir lieu pour vrai. Le plan est séquencé selon votre échéance avant que vous vous engagiez, les étapes de rapprochement et le déclencheur de retour arrière sont définis d’avance, et la mise en service est une décision prise sur la foi des résultats de ces répétitions. Proslat en est la version courte : une fenêtre de 60 jours, une mise en service ferme, aucune vente perdue.
L’échéance ne bougera pas, et quand la migration arrive, elle arrive d’un seul coup. Ce que vous pouvez encore choisir, c’est le chemin et le niveau de préparation de cette journée-là. En trente minutes, vous obtenez une lecture franche : faites-vous face à une mise à niveau, à un remplacement ou à un cas de soutien prolongé, et que faut-il pour respecter la date en toute sécurité. Sans engagement.
Amorcer la conversationUne vraie personne vous répondra en un jour ouvrable. Aucune séquence automatisée.
Entreprise appartenant à des vétérans. Certifiée Odoo, IFS Cloud et Acumatica, et tout est réalisé à l’interne.
Dernière mise à jour : juillet 2026.