Changer de logiciel métier, c'est rarement le développement qui coince : c'est la migration de données. Quinze ou vingt ans d'historique, des champs détournés de leur usage d'origine, des doublons, des clients partis depuis longtemps. La tentation est de tout recopier pour ne rien perdre, et c'est précisément ce qui fait déraper les reprises. Voici comment traiter la reprise de l'existant comme un chantier à part entière.

Une migration de données n'est pas une copie, c'est un tri

Dans un projet de remplacement d'application métier, le budget se concentre sur les écrans, les règles de gestion et les intégrations. La reprise arrive en fin de parcours, traitée comme une formalité : on exporte, on transforme, on importe. C'est là que la mise en service se décale de plusieurs semaines.

La difficulté n'est pas de déplacer les octets. Elle est de décider ce qui mérite de vivre dans le nouveau système. Une base ancienne contient des tiers qui n'existent plus, des champs commentaire où trois générations d'utilisateurs ont rangé des informations différentes, des codes articles réattribués, des statuts que plus personne ne sait interpréter. Recopier tout cela revient à payer un logiciel neuf pour y réinstaller les problèmes de l'ancien. La bonne question n'est donc pas comment transférer ? mais qu'est-ce qui doit partir, sous quelle forme, et qui en décide ? C'est une question métier avant d'être une question d'outil.

Pourquoi les migrations s'accélèrent en 2026

Beaucoup de reprises ne sont pas choisies : une échéance de support les déclenche. Deux dates structurent l'année.

  • SQL Server 2016 est sorti du support le 14 juillet 2026. Microsoft l'a confirmé le jour même sur son blog SQL Server : plus de mises à jour de sécurité régulières ni de support technique, la politique de cycle de vie prévoyant dix ans par version. Restent Azure SQL, SQL Server 2025, ou des mises à jour de sécurité étendues (ESU) présentées comme un pont temporaire.
  • SAP ECC 6.0 arrive au bout. La maintenance standard des versions EHP 6 à 8 court jusqu'au 31 décembre 2027, celle des EHP 0 à 5 s'est arrêtée le 31 décembre 2025, avec une maintenance étendue à plus 9 % jusqu'au 31 décembre 2030.

Une fin de support ne force pas seulement à changer de socle : elle ouvre une fenêtre de tir. C'est le moment où l'entreprise accepte enfin de toucher à ses données.

Le tri : quatre questions par ensemble de données

Prenez la liste des objets de l'application actuelle (tiers, contrats, commandes, interventions, documents, facturation) et posez quatre questions sur chacun, avec le responsable métier et non avec l'informaticien.

  1. Qui s'en sert, et à quelle fréquence ? Un historique consulté trois fois par an n'a pas à vivre dans la base active du nouvel outil : une lecture seule sur un espace séparé suffit, pour une fraction du coût.
  2. Quelle est la période réellement utile ? Reprendre trois ans de commandes plutôt que quinze divise le volume, les tests et les surprises. Fixez la borne par écrit, service par service.
  3. Quelle est la version qui fait foi ? Quand la même donnée existe dans l'application, dans un tableur et dans une boîte aux lettres, il faut nommer une source unique objet par objet. Sans cette décision, la migration recopie le désaccord.
  4. Qu'est-ce qui demande une main humaine ? Les doublons de tiers, les adresses incomplètes et les champs libres ne se nettoient pas par script : prévoyez une charge de saisie et un propriétaire nommé.

Purger au passage : le cadre l'impose déjà

La migration est le seul moment où la purge devient indolore, puisque l'on choisit ce que l'on emporte. La CNIL, sur sa page consacrée aux durées de conservation mise à jour le 2 avril 2026, décrit un cycle de vie en trois phases : la base active, le temps de la finalité poursuivie ; l'archivage intermédiaire, quand le dossier est clos mais présente encore un intérêt administratif ou répond à une obligation légale ; l'archivage définitif, réservé aux données à valeur patrimoniale. Trois exemples : dix ans pour les données de facturation au titre du code de commerce, cinq ans pour le double du bulletin de paie selon l'article L3243-4 du code du travail, deux ans au maximum pour les candidatures non retenues.

Point souvent manqué en migration : l'archivage intermédiaire suppose une séparation d'avec la base active, physique par extraction vers une base dédiée accessible aux seules personnes habilitées, ou logique par limitation des habilitations. Recopier un historique de dix ans dans un outil ouvert à tous n'est donc pas une conservation conforme, c'est une base active gonflée.

Pour arbitrer, appuyez-vous sur le référentiel des durées de conservation en gestion des ressources humaines publié par la CNIL le 2 avril 2026 et mis à jour le 20 mai 2026, qui couvre dix domaines du recrutement aux alertes professionnelles : les durées recommandées y valent présomption de conformité, et l'on peut s'en écarter à condition de documenter son choix.

La méthode en six étapes

  1. Cartographier avant de chiffrer. Volumes par table, enregistrements actifs sur douze mois, taux de champs vides, doublons détectés. Sans ces chiffres, un devis de reprise est une estimation au doigt mouillé.
  2. Écrire les règles de correspondance champ par champ. Quatre colonnes : champ source, champ cible, règle de transformation, cas non traités. La dernière est la plus importante.
  3. Nettoyer dans l'ancien système quand c'est possible. Une fusion de doublons faite dans l'outil d'origine profite aux deux mondes et évite un script jetable.
  4. Répéter la migration à blanc, au moins trois fois. La première passe révèle les erreurs de format, la deuxième les erreurs de règle, la troisième mesure la durée réelle de la bascule, celle qui conditionne le week-end de mise en service.
  5. Faire recetter par ceux qui utilisent les données, pas par l'équipe projet : le comptable, le responsable d'atelier, l'assistante qui connaît les dossiers sensibles, avec une liste de dossiers à vérifier.
  6. Garder l'ancien système accessible en lecture six à douze mois, avec une date d'extinction écrite et un jeu d'exports conservé à part : l'assurance la moins chère du projet.

La recette : trois contrôles non négociables

Une reprise se valide avec des nombres, pas avec une impression.

  • La volumétrie : enregistrements attendus par objet, enregistrements obtenus, écart expliqué ligne à ligne. Un écart non expliqué est un rejet, jamais un arrondi.
  • Les totaux métier : encours client, valeur de stock, chiffre d'affaires du dernier exercice. Ils doivent correspondre au centime près avec la comptabilité.
  • L'échantillon dirigé : trente à cinquante dossiers choisis pour leur difficulté, le client à dix adresses de livraison, la commande partiellement soldée, le contrat résilié puis repris, vérifiés un par un.

Deux oublis reviennent ensuite : les documents (pièces jointes, contrats scannés, photos d'intervention), qui pèsent souvent l'essentiel du volume ; et les accès laissés chez le prestataire sortant, alors que les identifiants de l'ancienne base doivent être au nom de l'entreprise avant la bascule.

Une reprise réussie se reconnaît à un signe : trois mois après la mise en service, personne ne demande à rouvrir l'ancien outil. Si vous préparez le remplacement d'une application métier ou la modernisation d'un existant, la reprise mérite sa ligne de budget dès le premier chiffrage.

Questions fréquentes

Combien de temps faut-il prévoir pour une migration de données ?

Comptez rarement moins de six à huit semaines entre la cartographie et la recette pour une application métier de PME, répétitions à blanc comprises. La durée dépend du nombre d'objets et de l'état des données, pas du volume en gigaoctets.

Faut-il reprendre tout l'historique dans le nouveau logiciel ?

Non, et c'est rarement souhaitable. Une période active courte dans le nouvel outil, doublée d'un accès en lecture à l'ancien, couvre la majorité des besoins réels pour un coût bien inférieur.

Qui doit valider la reprise de données ?

Les responsables métier de chaque domaine, sur des totaux chiffrés et un échantillon de dossiers difficiles. L'équipe projet prépare et mesure, elle ne peut pas se valider elle-même.

Que dit le RGPD sur les données reprises lors d'une migration ?

Les durées de conservation continuent de s'appliquer après la bascule. La CNIL distingue base active, archivage intermédiaire et archivage définitif, et demande une séparation physique ou logique de l'archivage intermédiaire : la migration est le bon moment pour purger et cloisonner.

Que faire si l'éditeur de l'ancien logiciel refuse de fournir un export ?

Vérifiez le contrat, qui prévoit souvent une clause de réversibilité. À défaut, une extraction directe depuis la base reste possible mais coûteuse : c'est l'argument pour inscrire un test de restitution au contrat du prochain outil, dès la signature.

Parlons de votre projet : nous cadrons la reprise de vos données avant la première ligne de code.