Réussir sa migration vers SAP Business One, de la reprise des données à la bascule

Une migration SAP Business One recouvre en réalité deux projets distincts. Le premier consiste à passer à SAP Business One depuis des fichiers Excel, un logiciel de comptabilité ou un ancien ERP. Le second consiste à faire évoluer une installation existante d’une version à une autre. Les risques, la méthode et les interlocuteurs diffèrent ; cette page détaille les deux.

SAP annonce plus de 83 000 clients et 1,2 million d’utilisateurs pour la solution, distribuée via 850 partenaires. Vous n’êtes donc pas dans une situation inédite : la migration vers SAP Business One est un exercice courant pour les intégrateurs du réseau, à condition de choisir celui qui connaît votre métier.

Migrer vers SAP Business One : quels points de départ ?

Le point de départ conditionne tout le reste. Voici les trois cas les plus fréquents.

Depuis Excel ou des outils dispersés

C’est le cas où la donnée est la plus fragile. Les mêmes clients apparaissent sous plusieurs orthographes, les références articles ne suivent pas de règle, et certaines règles de calcul n’existent que dans la tête d’un collaborateur. Le temps gagné à structurer ces informations en amont se retrouve ensuite à la recette.

Depuis un logiciel de comptabilité ou de gestion

Vous disposez en général d’une base propre côté comptabilité, mais les flux commerciaux, les stocks et les achats sont à construire. La reprise porte surtout sur le plan comptable, les tiers et les soldes. Pour mesurer ce que l’ERP apporte au-delà, consultez les modules de SAP Business One.

Depuis un ancien ERP

C’est le cas le plus riche en pièges. Un ancien système contient des années de personnalisations dont certaines n’ont plus de raison d’être. Profitez de la migration pour décider ce qui est reproduit, ce qui est remplacé par le standard et ce qui est abandonné. Si le système cible ne vous est pas encore acquis, comparez d’abord les alternatives à SAP Business One.

Les outils et la méthode de l’éditeur

Le document d’implémentation de SAP prévoit la migration des données de l’ancien système pendant la phase de réalisation du projet. Un guide de migration des données figure parmi les outils de la méthodologie fournie aux partenaires.

Cela a une conséquence pratique : la reprise de données n’est pas une opération de dernière minute. Elle s’inscrit dans le calendrier de la mise en place de SAP Business One, avec ses jalons, ses responsables et ses validations. Si votre intégrateur la présente comme un simple import final, posez des questions.

Quelles données reprendre ?

Reprendre « tout » est rarement une bonne idée. Chaque donnée reprise doit être contrôlée, rapprochée et assumée. Classez-les en trois catégories.

Les données de base, indispensables

• les articles, leurs unités, leurs familles et leurs nomenclatures ;
• les clients et les fournisseurs, avec leurs coordonnées, conditions de paiement et références bancaires ;
• le plan comptable, les journaux et les codes de TVA ;
• les entrepôts et emplacements.

Les données en cours, à reprendre avec soin

• les soldes d’ouverture comptables et les balances tiers ;
• les commandes clients et fournisseurs non soldées ;
• les stocks valorisés à la date de bascule ;
• les immobilisations, si le périmètre les inclut.

L’historique, à décider au cas par cas

L’historique complet des ventes, des écritures ou des mouvements de stock alourdit la reprise et complique les contrôles. Posez-vous trois questions : en avez-vous besoin pour la statistique, pour l’obligation de conservation, pour le service client ? Dans bien des cas, conserver l’ancien système en consultation ou archiver l’historique suffit. Les exigences de conservation comptable relèvent de votre expert-comptable.

Nettoyer avant de migrer

Un ERP ne corrige pas des données médiocres, il les rend visibles partout. Le nettoyage comprend :

1. la déduplication des tiers et des articles ;
2. l’harmonisation des codes, des libellés et des unités ;
3. la désactivation des fiches obsolètes plutôt que leur reprise ;
4. la vérification des coordonnées, des numéros de TVA et des conditions de règlement ;
5. la validation métier par un référent identifié pour chaque domaine.

Ce travail incombe en grande partie à votre entreprise : l’intégrateur fournit les gabarits et les contrôles, mais seuls vos équipes savent quel client est actif ou quel article est encore vendu.

La stratégie de bascule

Deux approches dominent, et le bon choix dépend de la taille de l’entreprise, de la saisonnalité et du niveau de risque acceptable.

Quelques principes s’appliquent dans les deux cas :

• choisissez une date de bascule cohérente avec votre activité et votre clôture comptable, en évitant les pics de charge ;
• prévoyez un gel des saisies dans l’ancien système pendant la coupure ;
• planifiez la présence renforcée de l’intégrateur et des utilisateurs clés les premiers jours ;
• anticipez la gestion des flux entrants : commandes en ligne, EDI, banque, voir les intégrations et connecteurs.

Tests et recettes : le vrai filet de sécurité

La qualité d’une bascule se joue avant la bascule. Une démarche solide comprend plusieurs étapes.

1. Reprises à blanc. On rejoue l’import complet sur un environnement de test, plusieurs fois, jusqu’à obtenir des écarts nuls ou expliqués.
2. Rapprochements. Les balances comptables, les valeurs de stock, les encours clients et fournisseurs sont comparés entre l’ancien et le nouveau système.
3. Scénarios métier. Des utilisateurs réels déroulent leurs processus de bout en bout : devis, commande, livraison, facturation, encaissement, achat, réception, clôture.
4. Tests des interfaces et des éditions. Documents commerciaux, états de gestion, liens avec les autres outils.
5. Validation formelle. Un procès-verbal de recette signé par les responsables métier, qui conditionne la décision de bascule.

Pour les volets comptables et logistiques, les pages sur la comptabilité et la finance et sur les stocks et achats détaillent les contrôles à prévoir.

Le plan de retour arrière

Un plan de retour arrière n’est pas un aveu de pessimisme, c’est une condition de sérénité. Il précise :

• les critères objectifs qui déclenchent le retour (écart comptable bloquant, impossibilité de facturer, flux critique en panne) ;
• la date limite après laquelle le retour n’est plus possible sans perte de données ;
• la sauvegarde complète de l’ancien système et de la base cible juste avant la bascule ;
• la méthode pour ressaisir ou rejouer les opérations effectuées pendant la période d’essai ;
• les personnes qui décident, et comment elles sont jointes.

Conservez l’ancien système intact et consultable pendant une période convenue. C’est la meilleure assurance contre les surprises découvertes après coup.

Migrer entre versions de SAP Business One

Si vous utilisez déjà la solution, la question est différente : à quelle version vous situez-vous, et jusqu’à quand est-elle maintenue ?

Ce que dit SAP sur le cycle de vie

SAP garantit au moins cinq ans de maintenance standard par famille de versions, à compter de la date de disponibilité générale de la version majeure (x.0), les livraisons fonctionnelles ultérieures étant couvertes. 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. Les versions 8.8, 8.81, 8.82, 9.0, 9.1, 9.2 et 9.3 ont terminé leur période de maintenance standard. La même page indique seulement que la version 11 suivra la version 10, sans date.

En clair : si vous êtes sur l’une de ces anciennes versions, la montée vers la version 10.0 n’est plus une option de confort mais un sujet à traiter.

Un chemin par étapes

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. Plus votre version est ancienne, plus le chemin est long et plus il doit être testé sur une copie de la base.

Feature packages : l’innovation en continu

Depuis la version 10.0 d’avril 2020, SAP livre l’innovation par des feature packages cumulatifs, qui apportent nouveautés, corrections, correctifs de sécurité et mises à jour légales. Les interfaces restent stables entre la version majeure et les feature packages, ce qui limite l’impact sur les extensions. SAP distingue aussi les support packages (corrections, sécurité, mises à jour légales), les patches cumulatifs pour SAP Business One Cloud et les hotfixes, simples solutions temporaires hors cycle normal.

Point d’attention : SAP ne fournit ni corrections ni correctifs de sécurité pour les anciens feature packages, support packages, patches ou hotfixes. Rester sur un niveau ancien, c’est donc renoncer aux correctifs, y compris légaux.

Coût et conditions

Tous les clients disposant d’un contrat de maintenance valide reçoivent gratuitement les mises à niveau de version. Le coût réel se situe ailleurs : préparation, tests des personnalisations et des extensions, formation et déploiement. Pour comprendre les différences entre générations, consultez la page sur les versions et éditions ; pour l’exploitation courante, celle sur le support et la maintenance.

Si vous avez des développements spécifiques, leur compatibilité est le premier sujet à vérifier. Voyez à ce titre le développement sur mesure et, si l’installation actuelle pose problème, l’audit et la reprise de projet.

Erreurs à éviter

• Sous-estimer le nettoyage des données. C’est la première cause de retard à la recette.
• Reprendre tout l’historique par réflexe. Cela alourdit le projet sans valeur d’usage.
• Ne faire qu’une seule reprise d’essai. Les écarts se découvrent à la deuxième ou troisième répétition.
• Négliger les utilisateurs clés. Sans eux, la recette devient une formalité et les erreurs apparaissent en production. La formation à SAP Business One doit précéder la bascule, pas la suivre.
• Oublier le plan de retour arrière. Sans critères ni date limite, la décision se prend dans l’urgence.
• Reproduire l’ancien système à l’identique. Une migration est l’occasion de simplifier ; un clone coûte cher et n’apporte rien.
• Reporter une montée de version nécessaire. Les chemins s’allongent et les correctifs disparaissent.

Bien choisir son intégrateur pour migrer

La réussite d’une migration dépend moins de l’outil que de l’équipe qui la conduit. Demandez à l’intégrateur comment il organise les reprises à blanc, qui valide les rapprochements, comment il documente le retour arrière et s’il a déjà traité des cas comparables au vôtre, de même secteur et de même point de départ. Notre page sur le choix d’un intégrateur SAP Business One détaille les questions à poser, et le budget se cadre avec la page sur le prix de SAP Business One.

Intégrateurs ERP est un service gratuit de mise en relation : nous ne réalisons pas la migration, nous vous mettons en contact avec un intégrateur adapté à votre projet. Pour comprendre la démarche, voyez comment fonctionne la mise en relation.

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.