Migrer un business en ligne acquis en 2026 : le playbook technique et opérationnel

Tu l'as acheté. Maintenant, ne le casse pas en le déplaçant.

Le deal s'est fermé mardi dernier. Le vendeur t'a remis une boutique Shopify, un blog WordPress et une intégration Stripe douteuse. Tu sais déjà que tu veux migrer la boutique sur ton infra, refaire le stack email et remplacer l'analytics que personne ne croit. Huit semaines plus tard, la moitié de ces chantiers sont à l'arrêt, le trafic organique a perdu 23 % et un enregistrement DNS oublié pointe toujours vers l'ancien fournisseur email du vendeur.

Bienvenue dans le risque le moins discuté des acquisitions de business en ligne : la migration. Flippy a vu des dizaines d'acheteurs réussir le deal et brûler 6 mois de cash flow en essayant de « moderniser » l'actif. Voici le playbook pour déplacer un business en ligne acquis sans le casser.

Pourquoi la migration est le risque caché

La couverture éditoriale obsède sur la due diligence et la négociation. La migration n'a droit qu'à une note de bas de page. Pourtant, c'est là que la plupart des dégâts opérationnels arrivent :

• La continuité SEO est fragile. Une chaîne de 301 mal gérée peut effacer des années d'autorité en une nuit.
• Les données client ont des falaises. Des comptes mal importés créent des orphelins invisibles.
• La réputation email se transfère mal. Les domaines d'envoi se réchauffent lentement. Tu peux perdre la délivrabilité pendant des mois.
• Les intégrations cassent en silence. Pixels pub, webhooks, prestataire de fulfillment — tout ce qui est branché à l'ancien environnement peut s'arrêter sans message d'erreur.

Bonne nouvelle : le risque de migration est en grande partie mécanique. Il se mitige en découpant le travail en phases et en refusant de faire deux cutovers en parallèle.

Phase 0 : Auditer avant de bouger quoi que ce soit

Avant de toucher un seul paramètre, construis une carte complète de l'existant. Tu ne peux pas migrer ce que tu n'as pas inventorié.

• Domaines et DNS. Tous les enregistrements A, AAAA, MX, TXT, CNAME et SPF/DKIM/DMARC. Screenshots de chaque dashboard registrar.
• Plateformes utilisées. CMS, e-commerce, ESP, CRM, helpdesk, analytics, comptes pub, processeur de paiement, fulfillment, comptabilité.
• Intégrations. Chaque webhook, flow Zapier/n8n, appel API custom. La plupart des business acquis ont au moins une automatisation type « je sais pas ce que ça fait mais c'est branché à la prod ».
• Assets statiques. Où sont hébergées les images produits ? Les PDFs ? Les téléchargeables ? Les URL sont-elles absolues, relatives ou CDN-prefixées ?
• Abonnements et facturations actives. Stripe, apps Shopify, SaaS, renouvellements de domaine, SSL. Liste-les avec date de renouvellement et email propriétaire.

Passe une semaine sur ça avant de toucher au reste. L'audit révèle souvent des deal-breakers que le vendeur a oublié de mentionner.

Phase 1 : Continuité SEO et domaine en premier

Si tu rates tout le reste, ne rate au moins pas ça. Le trafic search est fragile, et Google ne donne pas de seconde chance.

• Garde le même domaine. Ne fais pas rebrand + migration la même semaine. Si le rebrand est obligatoire, fais d'abord la migration, attends 60 jours, puis rebrand avec une stratégie 301 propre.
• Mappe chaque URL en 1-pour-1. Construis un CSV de chaque URL existante à fort trafic, chaque URL qui répond 200, et l'URL cible sur la nouvelle plateforme. Ancienne URL sans équivalent → 301 vers la page parente la plus pertinente.
• Les chaînes de 301 tuent les signaux de ranking. Une URL qui passe par 2 ou 3 redirections perd son autorité. Toujours 301 directement vers la destination finale.
• Soumets un nouveau sitemap le jour du cutover. Puis surveille Google Search Console pour les erreurs de crawl pendant 30 jours.
• Garde les règles robots.txt existantes. Passer d'`Allow: /` à plus restrictif le jour du cutover est le moyen le plus rapide de te désindexer.

Tu peux parcourir les opportunités d'acquisition sur la page deals — la plupart des sites listés ont au moins une mine SEO à désamorcer le jour de la migration.

Phase 2 : Migration de données avec preuves

Quoi que tu migres — clients, commandes, produits, abonnements — ne fais jamais confiance à l'import sans réconciliation.

• Compte avant, compte après. Avant l'export, note le nombre exact d'enregistrements par table. Après import, le compte doit matcher. Sinon, trouve chaque enregistrement manquant et explique pourquoi.
• Échantillonne 20 enregistrements et compare champ par champ. Diff visuel sur nom, email, adresse, historique de commandes. Les noms de champs diffèrent entre plateformes (Shopify "first_name" vs WooCommerce "billing_first_name") et les troncations silencieuses arrivent.
• Préserve les timestamps historiques. Un client inscrit en 2019 doit garder cette date. Les nouvelles plateformes adorent écraser `created_at` avec la date d'import — désactive ça si possible.
• Teste le login d'un compte échantillon. Les hashes de mot de passe se transfèrent rarement — la plupart des migrations imposent un envoi de reset au cutover.

Phase 3 : Email et réputation domaine

C'est là que la plupart des opérateurs se brûlent. La réputation email ne se transfère pas avec le domaine — elle se transfère avec le pattern d'envoi.

• Si tu changes d'ESP (Klaviyo vers Mailchimp, Sendgrid vers Postmark), ne migre pas toute la liste du jour au lendemain. Warm-up le nouveau provider avec 1 000 à 5 000 envois par jour pendant 2 à 4 semaines avant de scaler.
• Garde SPF, DKIM et DMARC alignés. Ajouter un nouvel ESP sans mettre à jour SPF = tes emails tombent en spam silencieusement.
• Si tu changes le domaine d'envoi, tu démarres la réputation à zéro. Prévois 6 semaines minimum de warm-up.
• Surveille bounce rate et taux de plainte quotidiennement pendant les 60 premiers jours après cutover. Un pic au-delà de 0,3 % de plainte = ton pattern d'envoi est lu comme suspect.

Phase 4 : Intégrations et pixels

Chaque connexion tierce est un échec silencieux potentiel.

• Pixels de tracking (Meta, TikTok, Google Ads) : redéploie sur la nouvelle plateforme avec le même pixel ID, puis teste le parcours de conversion complet avec l'outil preview. Un pixel « installé » mais qui ne fire pas est un bug post-migration classique qui coûte des mois de données d'attribution.
• Webhooks : chaque webhook que l'ancienne plateforme envoyait doit être reconfiguré. Vérifie Stripe, Shopify, APIs de fulfillment, intégrations escrow.
• Helpdesk : Zendesk, Front, HelpScout se connectent souvent par clé API. Les anciennes clés continuent à fonctionner en lecture mais perdent les droits d'écriture. Teste l'envoi d'une réponse ticket dès le jour 1.
• Analytics : ne détruis pas l'historique de l'ancien GA4 / Plausible / Fathom. Garde-le en lecture seule et démarre une propriété parallèle. Tu voudras le baseline historique.

Phase 5 : Staging, cutover, rollback

Ne cutover jamais un vendredi. Ne cutover jamais avant une campagne majeure. Ne cutover jamais sans rollback documenté.

• Stage tout pendant au moins 7 jours. Fais tourner une copie complète du nouvel environnement avec trafic d'échantillon avant d'y diriger les vrais clients.
• Pré-chauffe les caches et le CDN. Crawl toutes les URL du nouvel environnement avec Screaming Frog la veille du cutover.
• Baisse de TTL DNS : 48 h avant cutover, baisse ton TTL à 300 s pour pouvoir rollback vite. Remonte-le à 3600+ après stabilisation.
• Fenêtre de cutover : vise la plage 4 h la plus calme (typiquement mardi 02:00-06:00 UTC pour un site global). Runbook de rollback prêt, ligne par ligne.
• Surveille en temps réel pendant les 48 premières heures. Taux d'erreurs, taux de conversion, volume support.

Les anti-patterns qui flinguent les deals

Vu dans trop de post-mortems :

• Le « tant qu'on y est ». Migrer la boutique, refaire le stack email et changer d'ESP en même temps. Choisis-en un. Livre. Puis passe au suivant.
• Le « l'ancien proprio nous aidera ». Les clauses de support transition expirent vite. Récupère chaque credential, chaque mot de passe d'intégration, chaque date de renouvellement SSL dès la semaine 1.
• La « dette SEO on verra plus tard ». Soft 404, canonicals cassées, alt manquants hérités. Ça compound, et c'est 10x moins cher à fixer pendant la migration qu'après.
• Le gros rebrand dans la migration. Changement de domaine + logo + couleurs + copy — tout en semaine 6. La récupération prend des mois.
• Le cutover juste avant un pic. Migrer mi-novembre alors que Black Friday est dans 2 semaines. Non. Juste non.

Un calendrier réaliste

Six à dix semaines, c'est la fenêtre réaliste pour une migration propre. Quiconque te vend une « migration en 2 semaines » te vend en réalité un projet de récupération 6 mois plus tard.

Points clés

• La migration est le risque le plus sous-estimé en acquisition.
• Audite avant de toucher à quoi que ce soit — la plupart des erreurs fatales viennent d'un inventaire manquant.
• La continuité SEO (mapping URL, 301, sitemap, robots.txt) mérite un chantier dédié.
• Réconcilie les imports de données par compte et échantillons, pas par messages de succès.
• La réputation email ne se transfère pas — warm-up lent du nouvel ESP.
• Ne combine jamais migration et rebrand. Ne cutover jamais avant un pic.

Pour un flux continu d'opportunités d'acquisition — y compris des cas post-migration — parcours les deals ou crée une alerte sur tes niches cibles.