↓

Passer à Business Central : réussir la reprise des données et la bascule

Migrer vers Business Central, c’est surtout décider quelles données reprendre, comment basculer et comment revenir en arrière si besoin. Voici la méthode, adaptée aux entreprises belges.

Mis à jour le 28 octobre 2026

Une migration vers Business Central n’est pas un simple transfert de fichiers. C’est un changement de socle pour votre comptabilité, vos achats, vos stocks et vos ventes, avec une date à laquelle l’ancien outil s’arrête et le nouveau prend le relais. Que vous passiez à Business Central depuis des tableaux Excel, un logiciel de comptabilité ou un ancien ERP, la réussite tient à trois choix : ce que l’on reprend, comment on bascule, et comment on revient en arrière si la bascule tourne mal.

Cette page détaille la méthode côté données et côté calendrier. Pour le cadrage global du chantier, voyez la page mise en place de Business Central et le guide général sur la migration d’un ERP.

Les trois situations de départ

Le point de départ détermine l’effort et les outils. Trois profils reviennent chez les entreprises belges.

Situation de départ Nature du travail Point de vigilance
Excel et fichiers dispersés Construire des données de base propres, qui n’existent nulle part en l’état Doublons, codes incohérents, absence d’identifiants stables
Logiciel de comptabilité seul Reprendre le plan comptable, les tiers et les soldes ; ajouter stocks, achats et ventes Cohérence des comptes auxiliaires avec la comptabilité générale
Ancien ERP ou solution maison Cartographier un modèle de données existant vers celui de Business Central Règles métier cachées dans l’ancien outil, développements spécifiques

Dans le premier cas, l’exercice est surtout un chantier de qualité de données. Dans le troisième, c’est un chantier de cartographie : chaque table de l’ancien système doit trouver sa destination, ou être écartée en connaissance de cause.

Migrer depuis Excel ou un logiciel comptable

Pour une source qui n’est pas une base SQL, Microsoft recommande de charger les données dans Business Central avec des packages et des modèles de configuration. Concrètement, vous remplissez des modèles structurés (clients, fournisseurs, articles, plan comptable), l’intégrateur les contrôle, puis les importe dans une société de test.

Les compétences de l’examen MB-800, celui des consultants fonctionnels Business Central, reflètent bien cette réalité : création d’une société avec l’installation assistée, feuilles et packages de configuration, écritures d’ouverture de journal, migration de données vers et dans Business Central. Demander à un intégrateur comment il pratique ces étapes est une bonne façon d’évaluer sa maîtrise, comme l’explique la page choisir un intégrateur Business Central.

Les soldes ne se « copient » pas : ils se reprennent par écritures d’ouverture. Votre comptable doit valider la balance d’ouverture, tiers par tiers, avant la première utilisation réelle.

Migrer depuis un système Microsoft existant

Si vous êtes déjà dans l’écosystème Microsoft, l’éditeur propose un outil de migration vers le cloud. Il permet d’aller 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 vers la version 25 au minimum ;
  • Dynamics GP 2015 et versions suivantes ;
  • Dynamics SL 2015 et versions suivantes ;
  • toute autre source SQL, via des migrations personnalisées.

La solution sur site doit tourner sur SQL Server 2016 ou plus récent, avec un niveau de compatibilité de base de données de 130 au minimum. Un client sous Dynamics NAV ne peut pas sauter l’étape : il passe d’abord à Business Central sur site, puis bascule en ligne.

Cas particulier : la version 14 sur site

Depuis la version 14 sur site, Microsoft décrit deux voies :

  1. La migration complète : mise à niveau sur site vers la version 25 au minimum, puis migration vers le cloud. Elle conserve davantage d’historique et de personnalisations, mais demande plus de tests.
  2. La réimplémentation avec l’outil dédié à la version 14 : il ne reprend que les données essentielles (données de base, soldes d’ouverture et paramétrage) directement vers le cloud.

Le choix dépend de la valeur réelle de votre historique et du nombre de développements spécifiques à conserver. Si votre installation actuelle est très personnalisée, un audit préalable évite de transposer à l’identique des écarts dont plus personne ne se sert.

Quelles données reprendre, lesquelles laisser

Reprendre tout l’historique est rarement judicieux : cela coûte du temps, fait reprendre des erreurs anciennes et allonge les tests. Une règle simple aide à trier.

Catégorie Reprise conseillée Remarque
Plan comptable, codes TVA, journaux Oui Base de tout le reste ; à valider avec le comptable
Clients, fournisseurs, adresses, conditions de paiement Oui, après nettoyage Fusionner les doublons avant import
Articles, nomenclatures, tarifs Oui, après nettoyage Voir stocks et achats
Soldes d’ouverture comptables Oui Par écritures d’ouverture de journal
Factures ouvertes, commandes en cours Oui Évite de suivre deux outils en parallèle
Historique comptable détaillé des exercices clos Selon besoin Souvent conservé dans l’ancien système en lecture seule
Pièces jointes, documents Au cas par cas Peuvent rester dans la GED existante

Le nettoyage commence bien avant l’import. Des clients saisis trois fois sous des orthographes différentes, des articles sans unité de mesure, des numéros de TVA erronés : tout cela se répare dans la source, pas après coup dans le nouvel ERP.

Reprendre sans casser la TVA belge ni Peppol

Deux sujets belges méritent une attention particulière. Le premier est la TVA : codes, régimes, comptes associés et numéros d’entreprise des tiers doivent être corrects pour que la déclaration à la TVA reste juste dès la première période. Le second est l’échange de factures électroniques via Peppol, qui suppose des identifiants de tiers fiables. Les pages sur la TVA belge dans un ERP et sur la facturation électronique Peppol détaillent ces obligations.

Microsoft fournit directement la localisation de Business Central pour la Belgique, ce qui évite de passer par une application tierce pour les fonctions locales. Le détail pour votre contexte se trouve sur la page Business Central en Belgique. Faites relire le paramétrage fiscal par votre expert-comptable avant la bascule, pas après la première déclaration.

La stratégie de bascule

Deux grandes approches existent, et le bon choix dépend de votre activité.

  • Bascule en une fois (« big bang ») : l’ancien système s’arrête un jour donné, Business Central devient l’outil unique. C’est plus net et évite la double saisie, mais le risque est concentré sur une seule date.
  • Bascule par étapes : on démarre par un périmètre (par exemple la comptabilité, puis les ventes, puis les stocks). Le risque est réparti, mais il faut gérer des interfaces temporaires entre l’ancien et le nouveau système.

La date de bascule se choisit avec le calendrier comptable : un début de période comptable ou de trimestre TVA facilite les soldes d’ouverture. Évitez les pics d’activité (inventaire, fin d’année, soldes pour un commerce). Si votre activité repose sur un site marchand ou des échanges de données, prévoyez aussi les connecteurs à rebrancher le jour de la bascule.

Tester avant de basculer

Une migration sérieuse se répète plusieurs fois avant la reprise définitive. La séquence type :

  1. une première reprise de données sur un environnement de test, pour détecter les rejets et les incohérences ;
  2. un contrôle chiffré : balance, soldes clients et fournisseurs, valeur de stock, comparés à l’ancien système ;
  3. une recette par les utilisateurs, avec leurs vrais cas : commande, réception, facture, encaissement, clôture mensuelle ;
  4. une répétition générale de la bascule, chronométrée, pour savoir combien de temps la reprise prend réellement ;
  5. la reprise définitive, suivie d’un nouveau contrôle chiffré.

Le contrôle chiffré est la preuve que rien n’a été perdu. Il doit être signé côté finance, pas seulement côté technique. La formation des utilisateurs se place avant la recette : des équipes qui découvrent l’outil le jour de la recette valident mal.

Plan de retour arrière

Un plan de retour arrière se prépare avant la bascule, avec trois éléments : des critères d’arrêt écrits (quels écarts justifient de renoncer ?), un ancien système conservé intact et en lecture seule jusqu’à la clôture de la première période, et une personne désignée pour décider.

Côté Business Central en ligne, la restauration d’environnement offre un filet complémentaire : 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, avec un abonnement payant. C’est utile pour revenir à l’état d’avant une reprise ratée, mais cela ne remplace pas l’ancien système : si des utilisateurs ont saisi des opérations réelles depuis la bascule, restaurer les efface.

Migrer entre versions de Business Central

Une fois dans Business Central en ligne, vous n’avez plus de « grande migration » à planifier : le service relève de la Modern Lifecycle Policy de Microsoft, avec des mises à jour continues et une mise à jour majeure tous les six mois. Les versions majeures paraissent en avril et en octobre, et des mises à jour mineures arrivent chaque mois sans version majeure ; elles contiennent notamment des correctifs critiques et des évolutions réglementaires.

Le calendrier laisse du temps pour se préparer :

  • les environnements d’aperçu (bacs à sable) s’ouvrent environ un mois avant la sortie, en mars et en septembre, et sont supprimés 30 jours après la disponibilité officielle ;
  • la période de mise à jour d’une version majeure commence à sa disponibilité générale 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 ;
  • chaque environnement a par défaut une fenêtre de mise à jour entre 20 h et 6 h, heure locale du pays ; l’administrateur peut la modifier, avec une durée minimale de six heures. Une mise à jour non terminée dans la fenêtre est annulée puis reprogrammée sept jours plus tard.

Le bon réflexe : tester vos extensions et vos intégrations dans un bac à sable d’aperçu avant chaque version majeure. Un contrat de support et de maintenance peut couvrir ces contrôles, et la page versions et éditions précise ce qui distingue les déploiements.

Un point à connaître : dans la vague 2026 release wave 2 (version 29), la version française de Business Central devient un ensemble d’extensions posé sur la base applicative internationale W1. Cela illustre la direction prise par l’éditeur ; pour une société belge, vérifiez avec votre intégrateur ce que cela implique pour la localisation et vos extensions.

Les erreurs à éviter

  • Reprendre des données sales. Nettoyer d’abord, importer ensuite.
  • Reprendre tout l’historique « au cas où ». Chaque donnée reprise est une donnée à tester.
  • Oublier le comptable. Plan comptable, TVA et soldes d’ouverture se valident avec lui.
  • Sauter la répétition générale. La première reprise ne doit jamais être la définitive.
  • Fixer la date avant d’avoir testé. La date suit les résultats des tests, pas l’inverse.
  • Éteindre l’ancien système trop tôt. Gardez-le en lecture seule jusqu’à la clôture de la première période.
  • Négliger la conduite du changement. Les utilisateurs formés tard contournent le nouvel outil.

Pour situer l’effort dans votre budget, consultez la page prix de Business Central : les prix publiés par Microsoft varient selon la devise, le pays et la variante régionale, et le prix final apparaît au paiement. Le coût de la migration elle-même dépend du périmètre et de la qualité de vos données ; il se chiffre avec un intégrateur, pas avec une grille.

Pour être mis en relation avec un intégrateur Business Central en Belgique qui a l’habitude des reprises de données, voyez comment fonctionne la mise en relation. Le service est gratuit pour votre entreprise.

Questions fréquentes

Peut-on migrer directement depuis Dynamics NAV vers Business Central en ligne ?

Non. Selon la documentation de Microsoft, un client sous Dynamics NAV doit d’abord passer à Business Central sur site avant de basculer en ligne. L’intégrateur planifie donc deux étapes distinctes, chacune avec ses tests et sa recette.

Faut-il reprendre tout l’historique de l’ancien système ?

Rarement. Dans la plupart des projets, on reprend les données de base, les soldes d’ouverture et les écritures ouvertes (factures clients et fournisseurs non soldées, stocks, immobilisations). L’historique détaillé reste consultable dans l’ancien système, conservé en lecture seule, ou dans une archive que votre comptable peut interroger.

Comment migrer depuis Excel ou un logiciel de comptabilité vers Business Central ?

Les données sont nettoyées, mises au format attendu puis chargées avec les feuilles et packages de configuration de Business Central. Les soldes se reprennent par écritures d’ouverture de journal. Une première reprise sur un environnement de test sert à corriger les erreurs avant la reprise définitive.

Que se passe-t-il si la bascule échoue le jour J ?

C’est le rôle du plan de retour arrière, décidé avant la bascule : critères d’arrêt, ancien système conservé intact, et reprise de l’activité sur celui-ci le temps de corriger. Côté Business Central en ligne, un environnement peut aussi être restauré à un instant des 28 derniers jours, dans la limite de 10 restaurations par mois calendaire.

Qu’est-ce qui change pour la TVA et Peppol après la migration ?

Vos codes TVA, vos régimes et vos données de facturation doivent être repris avec soin, car ils conditionnent la déclaration à la TVA et l’échange de factures électroniques. Microsoft fournit directement la localisation belge de Business Central ; l’intégrateur vérifie le paramétrage avec votre comptable avant la bascule.

Sources

  1. Microsoft Learn — Migrer des données vers Business Central en ligne
  2. Microsoft Learn — Sauvegarde et restauration d’un environnement
  3. Microsoft Learn — Calendrier de déploiement des mises à jour
  4. Microsoft Learn — Gestion des mises à jour dans le centre d’administration
  5. Microsoft Learn — Localisation de Business Central
  6. 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.