Parler de migration SAP Business One, c’est en réalité parler de deux projets différents. Le premier consiste à passer à SAP Business One depuis des fichiers Excel, un logiciel de comptabilité ou un ancien ERP. Le second consiste à faire monter de version une installation existante. Les deux reposent sur les mêmes réflexes : décider de ce que l’on reprend, tester avant de basculer, garder une porte de sortie.
Cette page s’adresse aux dirigeants, DAF et DSI belges qui préparent une migration vers SAP Business One et veulent savoir à quoi s’attendre avant de solliciter un intégrateur. Pour la vue d’ensemble du projet, lisez d’abord notre page sur la mise en place de SAP Business One ; pour la méthode générale, le guide de la migration d’un ERP pose les principes communs à tous les éditeurs.
Quel type de migration vers SAP Business One ?
Le point de départ détermine le travail à fournir. Le tableau ci-dessous résume les situations rencontrées en Belgique.
| Situation de départ | Ce qui pèse le plus | Point de vigilance |
|---|---|---|
| Fichiers Excel et tableaux maison | Qualité et unicité des données | Une même société saisie de trois façons, des articles sans code stable |
| Logiciel de comptabilité seul | Reprise des tiers et des soldes | Les stocks, achats et ventes n’existent pas encore sous forme structurée |
| Ancien ERP vieillissant | Volume d’historique et processus spécifiques | Développements sur mesure à refaire ou à abandonner |
| Autre ERP en cours d’abandon | Cohabitation pendant la bascule | Écarts de logique (lots, séries, unités, comptes) |
| SAP Business One d’une version ancienne | Chaîne de montées de version | Compatibilité des extensions et des développements |
Dans les quatre premières lignes, vous changez de logiciel. Dans la dernière, vous gardez le même éditeur mais vous traversez des versions, ce qui ne dispense ni de tests ni de plan de retour.
Ce que fournit SAP pour migrer
L’éditeur ne laisse pas la reprise des données au hasard. Dans son document d’implémentation, SAP prévoit la migration des données de l’ancien système pendant la phase de réalisation du projet, et fournit un guide de migration des données parmi les outils de sa méthodologie. Ce point est important pour vous : la reprise n’est pas une corvée de fin de projet, elle s’inscrit dans un calendrier balisé, avec ses jalons.
Concrètement, c’est votre intégrateur qui choisit les outils d’import adaptés à votre volume et à vos données. Ce que vous lui devez, c’est un périmètre clair et des données dont quelqu’un, chez vous, assume la justesse.
La reprise des données : quoi migrer, quoi laisser
La question n’est pas « comment tout reprendre » mais « qu’avons-nous réellement besoin de retrouver le jour de la bascule ».
Les données de base
Ce sont celles qui font tourner le quotidien :
- les clients et fournisseurs, avec leur numéro d’entreprise et leur numéro de TVA belge, leur langue de correspondance (français, néerlandais) et leurs conditions de paiement ;
- les articles, avec leurs unités, leurs familles et leurs codes de référence ;
- les nomenclatures et gammes si vous produisez ;
- le plan comptable, qui doit rester aligné sur le plan minimum normalisé et sur les besoins de votre comptable ;
- les comptes bancaires et les modes de paiement.
Ces données alimentent les modules décrits dans notre page sur les modules de SAP Business One. Une erreur à la source se retrouve ensuite dans chaque document généré.
Les soldes et les documents en cours
Au minimum, vous reprenez les soldes d’ouverture de la comptabilité, les factures clients et fournisseurs non soldées, ainsi que les commandes ouvertes. Pour la partie finance, la comptabilité dans SAP Business One détaille ce que le logiciel attend ; faites valider vos balances par votre expert-comptable avant tout import, car c’est lui qui signera la clôture suivante.
Côté logistique, l’inventaire de départ se fait par entrepôt et, le cas échéant, par lot ou numéro de série. La page consacrée aux stocks et achats montre pourquoi un stock initial faux se paie pendant des mois : chaque mouvement suivant repose dessus.
L’historique : jusqu’où remonter
Reprendre dix ans de pièces dans un ERP neuf est rarement utile et souvent coûteux. Une approche plus saine consiste à :
- reprendre l’historique de ventes nécessaire aux analyses et aux prévisions ;
- conserver les pièces comptables dans une archive consultable, dans le respect de vos obligations légales de conservation ;
- laisser l’ancien système en lecture seule pendant la période convenue.
La durée légale de conservation relève de votre comptable : ne la fixez pas dans le projet sans son avis.
Nettoyer avant d’importer
Importer des données sales dans un ERP propre, c’est installer le désordre dans un outil plus rapide. Avant la reprise, prévoyez un vrai travail de nettoyage :
- fusionner les doublons de tiers (même société sous plusieurs graphies, anciennes adresses) ;
- désactiver les articles et clients inactifs plutôt que de les migrer ;
- harmoniser les unités de mesure et les codes ;
- corriger les formats de numéro de TVA et d’adresse ;
- vérifier les soldes tiers contre la balance générale.
Ce nettoyage se fait dans l’ancien système ou dans un fichier intermédiaire, jamais directement dans SAP Business One après import. Il demande des gens de métier : le responsable des achats connaît ses fournisseurs, la comptabilité ses créances douteuses. L’intégrateur ne peut pas deviner à votre place quel client est un doublon.
Les raccordements à reprendre ou à recréer
Une migration ne se limite pas aux données. Les flux qui entouraient l’ancien outil doivent être reconstruits : banque (relevés de type CODA, paiements), boutique en ligne, outil de transport, EDI avec de gros clients. La page sur les connecteurs et intégrations vous aidera à inventorier ce qui doit être branché avant la bascule.
En Belgique, un point mérite une attention particulière : la facturation électronique B2B via Peppol. Si votre ancien système l’assurait, il faut prouver que la chaîne fonctionne dans le nouveau avant la bascule, et non après la première facture refusée. Notre guide sur la facturation électronique Peppol et celui sur la TVA belge dans l’ERP listent les contrôles à prévoir : codes TVA, déclarations, listings clients.
La stratégie de bascule
Trois grandes approches coexistent, et le choix dépend de votre tolérance au risque et de la saisonnalité de votre activité.
| Stratégie | Principe | Quand la retenir |
|---|---|---|
| Bascule en une fois | L’ancien système s’arrête, le nouveau démarre | Activité simple, peu d’interfaces, équipe resserrée |
| Bascule par étapes | Un périmètre après l’autre (finance, puis ventes, puis stock) | Organisation multi-sites ou processus très séparés |
| Fonctionnement en parallèle | Les deux systèmes vivent ensemble pour un temps limité | Activité critique, mais au prix d’une double saisie |
Le parallèle rassure mais fatigue les équipes : la double saisie fait naître des écarts qu’il faut ensuite expliquer. Réservez-le à une période courte et à un périmètre précis.
Choisissez la date de bascule en fonction de votre comptabilité, pas de l’agenda de l’intégrateur. Une bascule en début de période comptable ou après une clôture TVA simplifie les soldes d’ouverture. Évitez les pics d’activité de votre secteur, qu’il s’agisse d’une saison de livraison, d’un inventaire annuel ou d’une période de congés.
Les tests avant la bascule
Un test sérieux ne consiste pas à cliquer dans quelques écrans. Il suit vos processus réels de bout en bout :
- Répétition de la reprise : l’import est rejoué plusieurs fois sur un environnement de test, jusqu’à ce que les écarts soient expliqués et soldés.
- Réconciliation : la balance, les soldes tiers et la valeur du stock après import sont comparés à l’ancien système, ligne par ligne si nécessaire.
- Scénarios de bout en bout : de la commande à l’encaissement, de l’achat au paiement fournisseur, avec les cas particuliers de votre métier.
- Recette par les utilisateurs : ceux qui travailleront dans l’outil valident, pas seulement le chef de projet.
- Contrôle des documents : factures, bons de livraison, relances, dans la langue de chaque destinataire.
La formation des utilisateurs doit se dérouler pendant cette phase, sur des données proches des vôtres. Un utilisateur qui découvre l’outil le jour de la bascule apprend sur vos vrais clients.
Le plan de retour arrière
Un plan de retour arrière n’est pas un aveu de défiance, c’est une assurance. Il se décide avant la bascule et se documente :
- Un point de non-retour défini : à partir de quel événement (première facture émise, première clôture, premier paiement envoyé) revenir en arrière devient impossible ou coûteux.
- Des critères d’abandon écrits à l’avance : anomalies bloquantes, soldes irréconciliables, flux de facturation en panne.
- Une sauvegarde complète de l’ancien système et des données migrées, prise juste avant la bascule.
- Un décideur identifié, disponible pendant la bascule, qui peut dire « on revient ».
- Une procédure de ressaisie des opérations réalisées dans le nouveau système si l’on retourne à l’ancien.
L’ancien système reste intact et accessible tant que les premières clôtures ne sont pas validées. Le résiliant trop tôt, vous supprimez votre propre filet.
Migrer entre versions de SAP Business One
Si vous utilisez déjà SAP Business One, votre migration est une montée de version. Les règles de SAP, d’après ses pages officielles, sont précises.
Ce que dit l’éditeur
- Les montées de version directes ne sont prises en charge qu’entre versions consécutives, par exemple de la 9.3 à la 10.0. Une montée non consécutive demande plusieurs étapes.
- Les clients disposant d’un contrat de maintenance valide reçoivent gratuitement les mises à niveau de version.
- SAP garantit au moins cinq ans de maintenance standard par famille de versions, à compter de la disponibilité générale de la version majeure.
- La version 10.0 est en maintenance standard jusqu’au 31 décembre 2028, les dates étant sujettes à modification. Les versions 8.8, 8.81, 8.82, 9.0, 9.1, 9.2 et 9.3 ont terminé leur maintenance standard.
- La version 11 est annoncée comme devant suivre la version 10, sans date publiée sur la page de maintenance.
- Depuis la version 10.0, SAP livre l’innovation en continu par des feature packages cumulatifs, avec des interfaces stables entre la version majeure et ces packages.
- SAP ne fournit ni corrections ni correctifs de sécurité pour les anciens feature packages, support packages, patches ou hotfixes.
Les conséquences pratiques sont claires : plus l’écart avec la version courante est grand, plus la chaîne de montées s’allonge, et plus la préparation devient lourde. Un client resté sur une version dont la maintenance standard est terminée n’a plus de corrections de l’éditeur ; la planifier devient une question de risque, pas de confort. Notre page sur les versions et éditions détaille la logique des livraisons.
Ce qui se prépare côté entreprise
Une montée de version n’est pas une simple mise à jour technique. Avant de la lancer :
- inventoriez les extensions et développements : chacun doit être déclaré compatible avec la version cible, ou refait ;
- testez les états, formulaires et flux personnalisés sur une copie de votre base ;
- vérifiez les interfaces (banque, e-commerce, Peppol) après la montée ;
- prévoyez une fenêtre d’arrêt hors période de clôture.
Si votre installation est ancienne, mal documentée ou déjà en difficulté, un audit ou une reprise de projet en amont évite de monter de version sur une base fragile.
Les erreurs à éviter
Les migrations qui tournent mal ont souvent les mêmes causes :
- Migrer tout, y compris le superflu. Les données obsolètes alourdissent l’outil et compliquent les contrôles.
- Laisser le nettoyage à l’intégrateur. Il ne connaît pas vos clients ; l’arbitrage appartient à vos équipes.
- Réduire les tests à une démonstration. Une démonstration montre que l’outil marche, pas que vos données y entrent juste.
- Fixer la date de bascule avant de savoir si les reprises sont fiables. La date suit les tests, pas l’inverse.
- Oublier les flux réglementaires. Facturation électronique, TVA, rapports bancaires : un blocage ici se voit tout de suite dans la trésorerie.
- Négliger le plan de retour. Sans lui, chaque incident devient une crise de gouvernance.
- Arrêter le support après la bascule. Les premières semaines révèlent les écarts qui n’apparaissent qu’en réel ; prévoyez un accompagnement, comme décrit dans la page sur le support et la maintenance.
Ce que vous devez demander à votre intégrateur
Avant de signer, demandez à l’intégrateur comment il traite chacun de ces points : jeu de reprise répété, rapport de réconciliation, calendrier de bascule, plan de retour arrière, répartition des tâches de nettoyage entre vous et lui. Un intégrateur qui répond « on verra au moment de la bascule » à ces questions vous expose.
Sachez aussi à qui vous parlez : nous ne sommes pas intégrateur et nous ne réalisons pas votre migration. Nous mettons gratuitement en relation votre entreprise avec un intégrateur adapté à votre projet. Si vous hésitez encore sur le logiciel cible, la page sur SAP Business One en Belgique précise ce que l’outil apporte au contexte belge, et vous trouverez dans la section comment ça marche la démarche de mise en relation.
Questions fréquentes
Peut-on migrer vers SAP Business One depuis Excel ou un simple logiciel de comptabilité ?
Oui, c’est même le cas de figure le plus courant pour une PME belge qui change de taille. La difficulté n’est pas l’outil mais la qualité des fichiers : doublons de clients, articles sans référence stable, soldes qui ne correspondent pas à la comptabilité. Un nettoyage préalable, validé avec votre comptable, conditionne la réussite.
Quelles données faut-il reprendre dans SAP Business One ?
Les données de base (clients, fournisseurs, articles, nomenclatures, plan comptable) et les soldes d’ouverture doivent être repris. Les documents en cours (commandes ouvertes, livraisons non facturées, factures impayées) sont repris selon leur utilité. L’historique complet ne se reprend pas toujours : il peut rester consultable dans l’ancien système ou dans une archive.
Comment monter de version dans SAP Business One ?
Selon SAP, les montées de version directes ne sont prises en charge qu’entre versions consécutives, par exemple de la 9.3 à la 10.0. Une montée non consécutive se fait donc en plusieurs étapes, ce qui allonge la préparation et les tests. Les clients disposant d’un contrat de maintenance valide reçoivent les mises à niveau gratuitement.
Faut-il changer de version de SAP Business One avant la fin de la maintenance standard ?
Selon la page de maintenance de SAP, la version 10.0 est en maintenance standard jusqu’au 31 décembre 2028, sous réserve de modification, alors que les versions 8.8, 8.81, 8.82, 9.0, 9.1, 9.2 et 9.3 ont terminé cette période. Si vous êtes encore sur l’une de ces anciennes versions, la montée se planifie sans attendre, car SAP ne fournit plus de corrections pour elles.
Que se passe-t-il si la bascule échoue ?
C’est le rôle du plan de retour arrière, défini avant la bascule : l’ancien système reste intact et accessible, les critères d’abandon sont fixés à l’avance, et une personne a le pouvoir de décider. Tant que les premières factures et les premières clôtures n’ont pas été validées dans le nouvel outil, revenir en arrière doit rester possible.
Sources
- SAP — Mises à niveau et correctifs de SAP Business One
- SAP — Maintenance de SAP Business One
- SAP Learning — Méthodologie du projet d’implémentation de SAP Business One
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.