Non. Nous travaillons toujours sur une copie du système source, jamais sur l'environnement de production. Avant la mise en production, nous réalisons une migration de test complète, nous comparons le nombre d'enregistrements et des échantillons de contenu entre la source et la cible, et nous n'avançons qu'après votre validation. L'ancien système reste intact et accessible comme solution de repli pendant tout le processus.

Presque pas. L'extraction et la transformation s'exécutent en parallèle de l'activité normale, sans impacter les utilisateurs. Il n'y a qu'une courte fenêtre de bascule lors de la mise en production pour migrer les enregistrements créés depuis le dernier chargement (delta) et orienter l'équipe vers le nouveau système. Nous planifions cette fenêtre en période de faible activité, avec un plan de retour arrière défini.

Lors de la planification, nous établissons une correspondance champ par champ entre la source et la cible. Les champs sans équivalent direct sont traités au cas par cas : nous créons des champs personnalisés, les convertissons vers le modèle cible ou conservons la donnée dans un champ d'historique. Les statuts, priorités, catégories et dates sont normalisés afin de ne pas perdre le sens original de chaque enregistrement.

ServiceNow, BMC Helix (Remedy), TOPdesk, Jira Service Management, Zendesk, Freshdesk, Freshservice, ManageEngine, SysAid, Movidesk, OTRS/Znuny, osTicket, Zammad, GLPI hérité et autres. Nous migrons aussi depuis des feuilles de calcul, des bases de données et des systèmes internes personnalisés via API ou accès direct à la base de données source.