La migration vers Business Central est moins un transfert de fichiers qu’un projet de reprise : on décide ce qui entre dans le nouvel ERP, sous quelle forme, à quelle date, et comment revenir en arrière si nécessaire. Que vous souhaitiez passer à Business Central depuis des tableurs, un logiciel de comptabilité ou un ancien ERP, ou que vous gériez une montée de version, la démarche repose sur les mêmes principes. Cette page détaille les cas de figure, les outils de l’éditeur, la reprise des données et la bascule.
Elle complète la page consacrée à la mise en place de Business Central et le guide général sur la migration d’un ERP.
Quatre situations de migration à distinguer
Le mot « migration » recouvre des chantiers très différents. Les identifier d’emblée évite de se tromper d’outil et de méthode.
| Situation de départ | Nature du chantier | Point d’attention |
|---|---|---|
| Fichiers Excel, tableurs | Première informatisation de la gestion | Qualité et unicité des données |
| Logiciel de comptabilité ou de gestion commerciale | Remplacement d’un outil par un ERP | Périmètre fonctionnel plus large |
| Ancien ERP (Dynamics NAV, GP, SL, autre) | Reprise structurée, parfois avec outils de l’éditeur | Écarts de modèle de données |
| Business Central sur site ou ancienne version | Changement d’hébergement ou de version | Extensions et développements spécifiques |
Chaque ligne appelle un cadrage différent. Une première informatisation exige surtout de construire les référentiels ; une reprise d’ERP demande de comprendre comment l’ancien système a stocké ses données, avec ses contournements historiques.
Les outils de l’éditeur pour migrer vers Business Central en ligne
Microsoft propose un outil de migration vers le cloud. D’après la documentation de l’éditeur, il permet de migrer vers Business Central en ligne depuis :
- Business Central sur site, directement à partir de la version 25 (les versions 15 à 24 doivent d’abord être mises à niveau en version 25 au minimum) ;
- Dynamics GP 2015 et versions suivantes ;
- Dynamics SL 2015 et versions suivantes ;
- toute autre source SQL, au moyen de migrations personnalisées.
Côté technique, la solution sur site doit utiliser SQL Server 2016 ou plus récent, avec un niveau de compatibilité de base de données de 130 minimum.
Cas particuliers à connaître
- Dynamics NAV : un client sous NAV doit d’abord passer à Business Central sur site avant de basculer en ligne. La migration se fait donc en deux temps.
- Version 14 sur site : deux options existent. La migration complète consiste à mettre à niveau sur site (version 25 minimum) puis à migrer. L’outil de réimplémentation Business Central 14 reprend seulement les données essentielles (données de base, soldes d’ouverture et paramétrage) directement vers le cloud.
- Source non SQL : Microsoft indique d’utiliser des packages et des modèles de configuration pour charger les données dans Business Central sur site, puis l’outil de migration cloud pour passer en ligne.
Le choix entre migration complète et réimplémentation est un arbitrage de fond. La première conserve davantage d’historique mais traîne aussi les anomalies passées ; la seconde repart plus propre, au prix d’un historique à conserver ailleurs. Un intégrateur Business Central vous aide à trancher selon vos obligations de conservation et la qualité de vos données.
Reprise des données : quoi migrer, quoi laisser
La reprise est le cœur du projet. Elle se prépare bien avant les premiers tests.
Les données à reprendre systématiquement
- les données de base : clients, fournisseurs, articles, comptes, dimensions analytiques, conditions de paiement ;
- les soldes d’ouverture : balance comptable, balances auxiliaires, stocks valorisés, immobilisations ;
- les documents en cours : commandes clients et fournisseurs non soldées, ordres de fabrication ouverts ;
- le paramétrage : plan de comptes, familles, tarifs, circuits de validation.
Sur ce dernier point, la reprise comptable s’articule avec les fonctions décrites dans la page comptabilité et finance de Business Central, et celle des flux physiques avec la gestion des stocks et des achats.
L’historique : un choix, pas un réflexe
Reprendre tout l’historique des écritures détaillées complique la migration, rallonge les tests et n’apporte pas toujours de valeur. Les questions utiles sont :
- Quelles obligations légales de conservation s’appliquent ? Elles se traitent souvent par un archivage consultable.
- Quels historiques servent réellement à piloter (ventes par client, consommations d’articles) ?
- L’ancien système restera-t-il accessible en lecture seule après la bascule ?
Bien souvent, on reprend les soldes d’ouverture et un historique limité, et l’on conserve l’ancien système en consultation.
Nettoyer avant de charger
Charger des données sales dans un ERP neuf reproduit les problèmes en les rendant plus visibles. Avant toute reprise :
- supprimer les doublons de tiers et d’articles ;
- désactiver les références obsolètes ;
- harmoniser les formats (adresses, codes, unités de mesure) ;
- vérifier les comptes tiers et les coordonnées bancaires, particulièrement sensibles pour les règlements ;
- faire valider les listes par les métiers, pas seulement par l’informatique.
Microsoft intègre d’ailleurs cette compétence à son examen MB-800 : création d’une société avec l’installation assistée, feuilles et packages de configuration, écritures d’ouverture de journal et migration de données vers et dans Business Central. Demandez à votre prestataire qui, dans l’équipe, maîtrise ces outils.
Construire la stratégie de bascule
La bascule est le moment où les utilisateurs cessent de travailler dans l’ancien système. Deux grandes stratégies coexistent.
| Stratégie | Principe | Avantage | Limite |
|---|---|---|---|
| Bascule unique (« big bang ») | Tous les périmètres passent en même temps | Une seule transition, pas de double saisie | Risque concentré sur une période |
| Bascule progressive | Par module, par société ou par site | Risque réparti, apprentissage graduel | Interfaces temporaires, coexistence des outils |
Le bon choix dépend de votre activité, de la saisonnalité, du nombre de sociétés et de la tolérance à l’arrêt. Une bascule à proximité d’une clôture annuelle ou d’une période de forte facturation est rarement judicieuse : choisissez une date où les équipes ont de la disponibilité.
Les répétitions de migration
Il est recommandé de réaliser plusieurs migrations à blanc dans un environnement de test : chargement complet, contrôle des écarts, mesure du temps nécessaire. La dernière répétition sert à fixer le calendrier précis de la bascule réelle. Un écart de balance constaté en répétition se corrige ; le même écart découvert le jour J devient une crise.
Le gel des saisies
Avant la bascule, une période de gel est nécessaire : plus de nouvelle saisie dans l’ancien système, extraction finale, chargement, rapprochement. Elle doit être annoncée aux équipes et aux interlocuteurs externes concernés (banques, clients, fournisseurs) pour qu’ils ne soient pas surpris.
Tester avant d’ouvrir le système
Les tests ne se limitent pas à vérifier que les données sont arrivées. On distingue :
- les contrôles de reprise : balance comptable identique à l’ancien système, stocks valorisés au même montant, soldes tiers rapprochés ;
- les tests de processus : une commande de bout en bout, de la saisie à l’encaissement, une réception, une clôture mensuelle ;
- les tests d’interfaces : échanges avec la banque, le site marchand, la paie, les outils de pilotage (voir les connecteurs Business Central) ;
- les recettes utilisateurs : des collaborateurs de terrain exécutent leurs tâches réelles et signent un procès-verbal.
Pour les entreprises françaises, ajoutez les obligations propres au pays, notamment la facture électronique : vérifiez avec votre intégrateur comment la version française de Business Central les prend en charge.
Prévoir un plan de retour arrière
Aucune migration sérieuse ne se lance sans plan de retour. Il doit être écrit, partagé et testé avant la bascule :
- Critères de décision : à partir de quel écart ou de quel blocage décide-t-on de revenir en arrière ?
- Décideur identifié : une personne désignée, joignable pendant toute la bascule.
- Point de non-retour : le moment après lequel les données saisies dans le nouveau système ne peuvent plus être rejouées dans l’ancien.
- Procédure : comment rouvrir l’ancien système, rattraper les saisies faites entre-temps, informer les équipes.
Sur Business Central en ligne, la restauration d’environnement apporte une sécurité supplémentaire. Selon Microsoft, un environnement peut être restauré jusqu’à 10 fois par mois calendaire et à n’importe quel moment des 28 derniers jours, dans la même région Azure et la même localisation. La restauration n’est possible qu’avec un abonnement payant. Elle protège le nouvel environnement, mais ne remplace pas le retour vers l’ancien système si la bascule échoue.
Migrer entre versions de Business Central
Une fois en ligne, vous n’avez plus de grande migration de version à planifier : le service évolue en continu. Business Central en ligne relève de la Modern Lifecycle Policy de Microsoft, avec des mises à jour continues et une mise à jour majeure tous les six mois. Concrètement, d’après la documentation :
- deux mises à jour majeures par an, en avril et en octobre, et des mises à jour mineures chaque mois sans mise à jour majeure, contenant notamment des correctifs critiques et des évolutions réglementaires ;
- la période de mise à jour d’une version majeure commence à sa disponibilité générale, en général le premier jour ouvré d’avril ou d’octobre, et dure cinq mois ; la version est proposée aux environnements existants environ une semaine après, puis un mois de période de grâce suit ;
- les environnements d’aperçu (bacs à sable) sont ouverts environ un mois avant la sortie, en mars et en septembre, et supprimés 30 jours après la disponibilité officielle ;
- chaque environnement a par défaut une fenêtre de mise à jour entre 20 h et 6 h (heure locale) ; l’administrateur peut la modifier, avec une durée minimale de six heures, et les mises à jour non terminées dans la fenêtre sont annulées puis reprogrammées sept jours plus tard.
Le bon réflexe : utiliser l’environnement d’aperçu pour tester vos extensions et vos développements sur mesure avant que la version n’arrive en production. Pour le détail des éditions et des cycles, consultez la page sur les versions de Business Central.
Un point propre à la France
Dans la vague de versions 2026 release wave 2 (version 29), la version française de Business Central est transformée en un ensemble d’extensions au-dessus de la base applicative internationale W1. Pour les trois versions suivant la 29, les clients français peuvent choisir d’activer les nouvelles fonctions sous forme d’extensions ; passé ce délai, Microsoft rendra obsolètes les anciennes fonctions et activera automatiquement l’extension. Si vous avez personnalisé la localisation française, ce calendrier mérite un audit dès maintenant.
Les erreurs à éviter
- Sous-estimer le nettoyage des données : c’est la première source de retards.
- Vouloir tout reprendre : l’historique complet alourdit sans toujours servir.
- Ne pas répéter la migration : une seule tentative, le jour J, est un pari.
- Négliger les utilisateurs : sans formation à Business Central, les erreurs de saisie dégradent vite les données fraîchement migrées.
- Oublier le retour arrière : un plan écrit et testé protège l’activité.
- Ignorer le coût total : voir la page sur le prix de Business Central pour le budget global.
Si une migration a déjà dérapé, un audit et une reprise de projet permettent de repartir sur des bases saines.
Faire accompagner votre migration
Une migration réussie demande un binôme : des métiers qui valident les données, et un intégrateur qui maîtrise les outils de reprise. Nous ne réalisons pas le projet : nous vous mettons en relation, gratuitement, avec un intégrateur adapté à votre situation. Décrivez votre point de départ et votre calendrier, nous nous chargeons du reste.
Questions fréquentes
Quelles données faut-il reprendre lors d’une migration vers Business Central ?
Reprenez en priorité les données de base (clients, fournisseurs, articles, plan comptable), les soldes d’ouverture et le paramétrage. L’historique détaillé n’est pas toujours utile : il peut rester consultable dans l’ancien système ou dans un entrepôt de données. La décision se prend avec la direction financière et les utilisateurs.
Peut-on migrer depuis Dynamics NAV directement vers Business Central en ligne ?
Non. Selon Microsoft, un client sous Dynamics NAV doit d’abord passer à Business Central sur site avant de basculer en ligne. Pour une version 14 sur site, l’éditeur propose soit une migration complète, soit un outil de réimplémentation qui ne reprend que les données essentielles.
Comment migrer depuis Excel ou un logiciel de comptabilité ?
Les données sont nettoyées, structurées dans des feuilles puis chargées à l’aide des feuilles et packages de configuration de Business Central. Les écritures d’ouverture de journal reprennent ensuite les soldes. Cette méthode fait partie des compétences évaluées par l’examen MB-800 de Microsoft.
Que faire si la bascule se passe mal ?
Il faut avoir défini un plan de retour arrière avant la bascule : critères d’échec, personnes qui décident, procédure pour rouvrir l’ancien système. Sur Business Central en ligne, un environnement peut aussi être restauré jusqu’à 10 fois par mois calendaire, à n’importe quel moment des 28 derniers jours, avec un abonnement payant.
Les mises à jour de Business Central sont-elles aussi des migrations ?
Pas au sens d’un changement de système. Business Central en ligne publie deux mises à jour majeures par an, en avril et en octobre, appliquées par Microsoft dans une fenêtre que l’administrateur peut régler. Elles demandent néanmoins des tests, surtout si vous avez des extensions ou des développements spécifiques.
Sources
- Microsoft Learn – Migrer les données vers Business Central en ligne
- Microsoft Learn – Calendrier de déploiement des mises à jour
- Microsoft Learn – Gestion des mises à jour dans le centre d’administration
- Microsoft Learn – Sauvegarde et restauration d’un environnement
- Microsoft Learn – Fonctions locales de la France
- Microsoft Learn – Guide d’étude de l’examen MB-800
Les noms de logiciels cités sont des marques de leurs éditeurs respectifs, mentionnées à titre d’information. Ce site est indépendant et n’est affilié à aucun éditeur.