Passer au contenu principal

Sage 100 FR: Migration ou réinstallation d’un environnement connecté à SSM

Comprendre les impacts d’une migration, d’une réinstallation ou d’un changement d’infrastructure d’un environnement Sage 100 FR connecté à Sage Sales Management afin de préserver la synchronisation et l’historique des données.

Écrit par Training

Migrer ou réinstaller un environnement Sage 100 FR connecté à Sage Sales Management tout en préservant la synchronisation et, si nécessaire, l’historique des données.

Vue d’ensemble

Cet article explique les points à prendre en compte lors d’une migration, d’un changement de serveur, d’un changement de machine virtuelle ou d’une réinstallation d’un environnement connecté à SSM.

Ces scénarios peuvent se présenter, par exemple, dans les cas suivants :

  • Migration d’une machine virtuelle vers une machine plus récente ou plus puissante.

  • Changement du serveur sur lequel le connecteur est installé.

  • Réinstallation du connecteur sur une nouvelle machine.

  • Installation à partir de zéro après une migration technique.

  • Migration d’un environnement On-Premise vers SPC.

  • Migration d’un environnement SPC vers On-Premise.

  • Déplacement d’une société Sage vers un nouveau dossier, une nouvelle base de données ou une nouvelle infrastructure.

L’objectif est de s’assurer que le nouvel environnement est correctement connecté à SSM et que, si nécessaire, l’historique d’activité reste rattaché aux enregistrements correspondants.


Avant de commencer

Avant de commencer la migration, gardez à l’esprit que SSM utilise plusieurs informations techniques pour relier les enregistrements Sage aux enregistrements existants dans SSM.

Cette relation peut dépendre de plusieurs éléments :

  • Le dossier ou l’identifiant technique de l’environnement Sage.

  • Les identifiants uniques des entités intégrées.

  • Les codes client, contact, prospect ou autres entités.

  • La configuration du connecteur.

  • Les tables ou données intermédiaires du connecteur.

  • Les clés API utilisées pour la reconnexion avec SSM.

Les données intermédiaires du connecteur se trouvent dans le dossier d’installation, plus précisément dans la base de données propre au connecteur.

Ces données contiennent la relation entre les enregistrements existants dans Sage et les enregistrements précédemment synchronisés dans SSM.

Il est donc important de vérifier, avant toute migration, si toutes les informations techniques de l’environnement précédent seront conservées ou si une nouvelle installation partielle ou complète sera réalisée.


Scénarios de migration

Scenario 1. Migration complète de l’environnement (recommandé)

Le scénario le plus simple et recommandé consiste à réaliser une migration complète de l’environnement précédent.

Cela inclut :

  • Les données Sage.

  • La configuration du connecteur.

  • La base de données propre au connecteur.

  • Les tables ou données intermédiaires du connecteur.

  • Les clés API nécessaires à la reconnexion.

  • Les identifiants techniques du dossier ou de l’environnement.

  • Les identifiants uniques des clients, contacts, prospects et autres entités intégrées.

  • La relation existante entre les enregistrements Sage et les enregistrements SSM.

Lorsque ces informations sont correctement conservées, lors de la réinstallation ou du redémarrage du connecteur sur la nouvelle machine et de la reconnexion à l’aide des clés API, le connecteur devrait continuer à fonctionner normalement.

Aucun service additionnel ne devrait être nécessaire à condition que :

  • L’environnement ait été migré complètement.

  • Le dossier conserve le même identifiant technique.

  • Les enregistrements Sage conservent leurs identifiants uniques.

  • Les codes client, contact, prospect et autres entités intégrées soient conservés.

  • La configuration du connecteur ait été conservée.

  • Les tables intermédiaires du connecteur soient disponibles.

  • La structure des données soit équivalente à celle de l’environnement précédent.


Scenario 2. Reconnexion sans migration de la configuration précédente

Il peut arriver que la configuration précédente du connecteur et ses tables intermédiaires n’aient pas été migrées, mais que les données Sage restent les mêmes.

Cela signifie que :

  • Le connecteur est installé à nouveau.

  • Les anciennes tables intermédiaires ne sont pas conservées.

  • Les environnements existent déjà dans SSM.

  • Les enregistrements SSM disposent déjà d’informations d’identification Sage.

  • Les données Sage n’ont pas changé.

  • Les clients, contacts, prospects et autres entités conservent leurs identifiants ou codes clés.

Le comportement attendu est le suivant :

  1. Le connecteur est installé sur la nouvelle machine.

  2. La reconnexion avec SSM est configurée à l’aide des clés API.

  3. Le connecteur consulte les informations existantes dans SSM.

  4. SSM dispose déjà d’enregistrements synchronisés avec des identifiants Sage.

  5. Le connecteur utilise ces informations pour recréer les tables intermédiaires.

  6. Une fois la relation reconstruite, le connecteur relie à nouveau les données existantes dans Sage.

  7. Les nouvelles données ou les données en attente sont ensuite synchronisées entre les deux systèmes.

Il est important de vérifier que :

  • Le dossier représente toujours le même environnement fonctionnel.

  • Les clients conservent leurs identifiants ou codes clés.

  • Les contacts conservent leurs identifiants ou codes clés.

  • Les prospects conservent leurs identifiants ou codes clés.

  • Les autres entités intégrées conservent leurs références.

  • Les enregistrements Sage n’ont pas été recréés.

  • Les codes ou identifiants utilisés pour la synchronisation n’ont pas été modifiés.


Scenario 3. Migration vers une nouvelle machine avec un nouveau dossier

Le scénario le plus sensible se produit lorsqu’une migration Sage est réalisée sans conserver la configuration précédente et qu’une nouvelle société ou un nouveau dossier est généré.

Le nouveau dossier peut disposer d’un identifiant technique différent.

Deux types d’environnements peuvent alors apparaître :

  • Les environnements existants dans SSM qui ne peuvent plus être reliés à la nouvelle machine.

  • Les nouveaux environnements détectés sur la nouvelle machine.

Dans ce scénario, SSM peut créer un nouvel environnement.

Il peut alors exister :

  • Un ancien environnement contenant l’historique.

  • Un nouvel environnement synchronisé avec la nouvelle infrastructure.

Le nouvel environnement fonctionnera normalement, mais l’historique précédent restera associé à l’ancien environnement.


Impact sur l’historique

Lorsque le connecteur identifie le dossier comme un nouvel environnement, SSM peut créer de nouveaux enregistrements synchronisés.

L’historique précédent restera associé aux anciens enregistrements.

Cela peut affecter notamment :

  • Les activités.

  • Les emails.

  • Les appels.

  • Les visites.

  • Les opportunités.

  • Les événements du calendrier.

  • Les relations entre sociétés et contacts.

  • Les autres données historiques.

Si cet historique doit être conservé dans le nouvel environnement, une migration des données historiques sera nécessaire.


Réaffectation de l’historique

Lorsque l’historique doit être conservé, des services additionnels peuvent être nécessaires afin de transférer les informations vers le nouvel environnement.

Cette réaffectation peut inclure :

  • Les activités commerciales.

  • Les emails.

  • Les appels.

  • Les visites.

  • Les opportunités.

  • Les événements du calendrier.

  • Les informations liées aux sociétés.

  • Les informations liées aux contacts.

  • Les autres données historiques.

Une fois cette opération réalisée :

  • Le nouvel environnement devient l’environnement actif.

  • Les utilisateurs travaillent avec les nouveaux enregistrements.

  • L’historique reste disponible.

  • L’ancien environnement peut être masqué ou déprécié.


Gestion de l’ancien environnement

Lorsque deux environnements coexistent, l’ancien environnement peut :

  • Être conservé temporairement.

  • Être masqué.

  • Être marqué comme inactif ou déprécié.

  • Conserver l’historique.

  • Servir de source pour une migration de l’historique.


Conserver des identifiants cohérents

L’un des points les plus importants d’une migration consiste à préserver la cohérence des identifiants.

Si les identifiants changent, plusieurs problèmes peuvent apparaître :

  • Création de doublons.

  • Perte de liaison entre les opportunités et les clients.

  • Activités rattachées au mauvais enregistrement.

  • Mélange d’informations entre plusieurs enregistrements.

L’idéal est de conserver :

  • L’identifiant unique.

  • Le code client.

  • Le code contact.

  • Le code prospect.

  • Les références des autres entités intégrées.


Cas alternatif : seuls les codes clés sont conservés

Même si les identifiants techniques internes changent, une réaffectation de l’historique peut rester possible lorsque les codes métier (client, contact, prospect, etc.) sont conservés.

Ces codes permettent d’établir une correspondance fiable entre les anciens et les nouveaux enregistrements.

Sans cette correspondance, il n’est pas possible de garantir une migration fiable de l’historique.


Quand des services additionnels sont nécessaires

Des services additionnels peuvent être nécessaires lorsque :

  • Un nouveau dossier est créé.

  • Un nouvel environnement apparaît dans SSM.

  • Les tables intermédiaires n’ont pas été migrées.

  • La configuration précédente n’a pas été conservée.

  • L’ancien environnement doit être masqué.

  • L’historique doit être transféré.

  • Les identifiants internes ont changé.


Recommandations

Avant de lancer une migration, vérifiez notamment :

  • Si la migration sera complète.

  • Si la configuration du connecteur sera conservée.

  • Si les tables intermédiaires seront migrées.

  • Si le dossier conservera son identifiant technique.

  • Si les identifiants Sage seront conservés.

  • Si les codes des entités resteront inchangés.

  • Si l’historique devra être conservé.

  • Si le nouvel environnement remplacera l’ancien.

  • Si des services additionnels devront être planifiés.

Une migration complète permet généralement une reconnexion simple.

Une migration partielle peut nécessiter des validations supplémentaires ou des services spécifiques.


Résultat

Selon la manière dont la migration est réalisée, trois scénarios principaux sont possibles :

Scenario

Résultat attendu

Migration complète

Reconnexion simple, continuité de la synchronisation et aucun service additionnel si les données restent identiques.

Reconnexion sans tables intermédiaires

Le connecteur reconstruit les tables intermédiaires à partir des informations déjà présentes dans SSM. L’opération peut prendre davantage de temps mais limite les risques de doublons lorsque les identifiants sont conservés.

Nouveau dossier ou nouvel environnement

SSM peut créer un nouvel environnement. L’ancien conserve l’historique et un service additionnel peut être nécessaire pour réaffecter cet historique au nouvel environnement.

Avez-vous trouvé la réponse à votre question ?