Vous avez migré votre site — changement de CMS, passage Shopify → PrestaShop, refonte sur mesure — et depuis la mise en ligne, des commandes n'apparaissent plus dans l'ERP, des champs produits ont disparu, un formulaire ne déclenche plus de notification. Une perte de données ou de fonctionnalités après migration est presque toujours récupérable, mais chaque jour sans diagnostic précis aggrave la facture : données incohérentes, clients mécontents, équipes qui repassent en saisie manuelle.
Chez Apresta, nous intervenons régulièrement sur des migrations pour des PME en Hauts-de-France. Le scénario est récurrent : la migration « technique » est considérée comme terminée parce que le site s'affiche, alors que les flux métier — export comptable, synchronisation stock, webhooks CRM — n'ont jamais été testés en conditions réelles. Ce guide vous donne la méthode pour identifier ce qui manque, prioriser les corrections et éviter que cela se reproduise.
Symptômes : comment reconnaître une migration incomplète
Une migration réussie ne se juge pas à l'écran d'accueil. Les signaux d'alerte les plus fréquents concernent les données manquantes (produits sans variantes, clients sans historique de commandes, articles de blog absents, médias non importés), les données corrompues (prix à 0 €, descriptions tronquées, caractères spéciaux illisibles, doublons massifs), et les fonctionnalités silencieusement cassées : formulaire de contact qui ne notifie personne, tunnel de paiement qui fonctionne mais n'envoie pas la confirmation email.
Les intégrations déconnectées sont un autre marqueur : ERP, CRM, outil de facturation ou logistique qui ne reçoit plus les flux. Les comportements diffèrent aussi : filtres catalogue inopérants, recherche interne vide, codes promo qui ne s'appliquent plus. Côté client, les avis produits disparaissent, la wishlist est perdue, les comptes clients sont incomplets.
Certains délais restent temporaires et attendus : synchronisation initiale de 24 à 72 h selon le volume, réindexation du moteur de recherche interne, recalcul des caches CDN ou des agrégats statistiques. Mais si une fonctionnalité critique (commande, paiement, export comptable) n'a pas été testée avec un scénario réel end-to-end dans les 48 h suivant la mise en ligne, considérez qu'il y a un risque non couvert.
Règle pratique : si une fonctionnalité critique n'a pas été testée end-to-end dans les 48 h post-bascule, le risque est réel.
Causes fréquentes de perte de données ou de fonctionnalités
Inventaire incomplet avant migration
Beaucoup de projets partent d'un export produits et oublient les métadonnées : attributs personnalisés, règles de taxe, relations cross-sell, tags marketing, champs ACF ou custom fields. Ce qui n'est pas listé n'est pas migré.
Mapping de champs approximatif
Un champ « description courte » source peut devenir un champ « meta SEO » cible par erreur. Les structures ne sont jamais identiques entre plateformes : un attribut « Taille » en select sur l'ancien CMS devient parfois un texte libre sur le nouveau, ce qui casse les filtres.
Scripts d'import exécutés une seule fois sans delta
La migration initiale importe 95 % des données. Les commandes, inscriptions ou contenus publiés entre le dernier export et la bascule tombent dans le vide. Sans procédure de delta ou de freeze des écritures, vous perdez des données en direct.
Plugins et extensions non réimplémentés
Sur WordPress/WooCommerce, PrestaShop ou Shopify, une fonctionnalité « standard » pour l'utilisateur repose souvent sur 3 à 8 extensions. Lors d'un changement de stack, ces briques doivent être remplacées par du natif, du sur-mesure ou des apps équivalentes — rarement automatiquement.
Intégrations API oubliées ou mal reconfigurées
Webhooks, clés API, URLs de callback, authentification OAuth : un caractère changé dans l'URL de prod suffit à couper un flux. Les intégrations tierces (Sendcloud, Pennylane, HubSpot, Sage) sont les premières victimes d'une migration mal documentée.
Tests limités au parcours « happy path »
L'équipe valide « ajouter au panier → payer → voir la confirmation ». Personne ne teste le retour SAV, l'export CSV comptable, le scénario B2B avec tarifs dégressifs, ou la commande avec produit en précommande.
Diagnostic : vérifications priorisées
Classez le travail en trois niveaux — urgent, important, plus tard.
Urgent (J+0 à J+3) : listez toutes les sources de vérité (ancien site, exports, base staging, ERP, emails transactionnels). Comparez les volumes : nombre de produits, clients, commandes, articles, médias — un écart supérieur à 2 % est une alerte. Testez end-to-end les trois flux critiques métier (commande → facture → expédition). Vérifiez les logs d'erreur serveur, les files d'attente, les webhooks en échec. Contrôlez les accès admin : rôles, permissions, comptes API.
Important (J+3 à J+14) : audit champ par champ sur un échantillon de 50 fiches produits et 20 clients. Recensement des extensions anciennes versus nouvelles — tableau de correspondance fonctionnelle. Tests des formulaires (contact, devis, newsletter) avec vérification réception et CRM. Crawl des URLs migrées versus inventaire pré-migration (404, contenu vide). Validation des emails transactionnels (confirmation, expédition, mot de passe oublié).
Plus tard (J+14+) : enrichissement des données incomplètes (SEO, visuels, attributs), optimisation des scripts de synchronisation continue, documentation des mappings pour les futures évolutions.
Pour structurer cette phase, appuyez-vous sur notre guide migration sans perte de trafic SEO pour la partie URLs et sur migration Shopify, PrestaShop, WooCommerce pour les spécificités plateforme.
Corrections : plan de récupération en 4 phases
Phase 1 — Stabiliser et colmater (semaine 1)
Gelez les modifications massives côté métier le temps du diagnostic. Réimportez les deltas manquants depuis la dernière sauvegarde fiable de l'ancien système. Réactivez ou recréez les webhooks et clés API des intégrations critiques. Corrigez les erreurs bloquantes : paiement, création compte, export comptable.
Ordre de grandeur : une PME e-commerce avec 2 000 références et 3 intégrations peut stabiliser les flux critiques en 5 à 10 jours ouvrés avec un audit structuré.
Phase 2 — Restaurer les données manquantes (semaines 2 à 4)
Lancez un script de réconciliation : comparez ID ou SKU entre source et cible. Importez ciblé les champs manquants (images, attributs, historiques). Nettoyez les doublons et normalisez les formats (dates, TVA, devises). Reconstruisez manuellement les cas limites (produits complexes, bundles, tarifs négociés B2B).
Ne tentez pas un réimport global sans backup : vous risquez d'écraser les données créées depuis la bascule.
Phase 3 — Réimplémenter les fonctionnalités perdues (semaines 2 à 6)
Pour chaque fonctionnalité absente, définissez le besoin métier réel (pas seulement « comme avant »). Choisissez entre natif plateforme, module marketplace ou développement sur mesure. Estimez le coût et le délai — certaines « petites » features cachent 40 h de dev. Testez avec des utilisateurs internes avant ouverture.
Budget réaliste France 2026 pour corriger une migration incomplète sur site PME : 3 000 à 15 000 €, selon l'ampleur des données perdues et le nombre d'intégrations à reconnecter.
Phase 4 — Validation et bascule définitive (semaine 4 à 8)
Checklist de recette signée par les métiers (commercial, compta, logistique, marketing). Période de double run si possible : ancien et nouveau système en parallèle 1 à 2 semaines. Formation des équipes sur les différences d'interface. Archivage en lecture seule de l'ancien environnement pendant 6 à 12 mois minimum.
Prévention : migrer sans perdre de données ni de fonctions
Avant la prochaine migration, construisez un inventaire fonctionnel exhaustif (données + comportements + intégrations). Réalisez un mapping champ par champ validé par le métier. Prévoyez des exports de référence datés et des sauvegardes testées en restauration. Planifiez une fenêtre de freeze ou une synchronisation delta pour les écritures. Impliquez les utilisateurs finaux dans la recette — pas seulement l'équipe technique. Documentez chaque webhook, cron job et script custom.
Consultez aussi sauvegardes et mises à jour : la routine et intégrations e-commerce ERP CRM logistique pour sécuriser l'aval de la migration.
FAQ
Peut-on récupérer des données perdues après une migration ?
Oui, dans la majorité des cas — à partir des sauvegardes de l'ancien système, des exports intermédiaires ou des bases de staging. Agissez vite : plus vous créez de nouvelles données sur un socle incomplet, plus la réconciliation devient complexe.
Combien de temps faut-il pour corriger une migration ratée ?
Comptez 2 à 8 semaines selon le volume de données et le nombre de fonctionnalités à réimplémenter. Les corrections urgentes (paiement, intégrations comptables) doivent être traitées en 48 à 72 h.
Faut-il revenir à l'ancien site si des données manquent ?
Pas systématiquement. Si les flux critiques fonctionnent et que les écarts sont identifiés, il est souvent plus rapide de corriger à forward qu de rollback. Le retour arrière se justifie surtout si le nouveau socle est structurellement inadapté.
Qui doit piloter la recette post-migration ?
Un chef de projet qui fait le lien entre technique et métier, avec des validateurs par domaine : e-commerce, compta, logistique, marketing. Sans ownership métier, les régressions passent inaperçues des semaines.
Comment savoir si toutes mes intégrations fonctionnent ?
Testez chaque flux avec une transaction réelle ou un jeu de données de test, puis vérifiez la réception côté outil tiers (ERP, CRM, email). Surveillez les logs de webhooks et configurez des alertes en cas d'échec.
Et maintenant ?
Une perte de données ou de fonctionnalités après migration n'est pas une fatalité technique — c'est le symptôme d'une bascule validée trop tôt. Les PME qui s'en sortent sont celles qui comparent les volumes, testent les flux métier et corrigent en jours, pas en mois. Si vous êtes dans cette situation à Lille, en Métropole Européenne de Lille ou ailleurs en Hauts-de-France, nous pouvons auditer votre migration, prioriser les récupérations et reconnecter vos intégrations.