Studio Pixel, agence web nantaise, nous a confié l’hébergement de 40 sites de leurs clients. Tous étaient sur un mutualisé OVH historique, devenu trop limité pour leur stack moderne. Délai souhaité : avant la fin du mois — soit 72 heures effectives.

Voici comment ça s’est passé. Sans embellissement.

Phase 0 — l’audit (jour J-7)

On ne migre rien à l’aveugle. Une semaine avant la bascule, on a auditté les 40 sites : versions PHP, plugins critiques, taille des bases, volumes de fichiers, traffic moyen, presence de cron jobs, configurations spécifiques (.htaccess complexes, redirections, etc.).

On a identifié :

  • 32 sites WordPress “standards” — migration triviale
  • 5 sites WordPress avec WooCommerce — attention aux sessions et au panier en cours
  • 2 sites Symfony — config spécifique à reproduire
  • 1 site avec un cron job critique de facturation à 03h du matin

Phase 1 — préparation (J-2)

On a provisionné les VMs cibles, configuré les VLANs, préparé les certificats Let’s Encrypt en wildcard sur les domaines de staging. Pour chaque site, on a fait une première copie complète vers la cible — pas la bascule, juste la copie.

Cette première copie permet de tester chaque site sur sa nouvelle infra (avec un nom de domaine temporaire en .reagency.dev) avant de toucher à quoi que ce soit en prod. On a corrigé 4 problèmes mineurs à ce stade — un plugin de cache qui ne tournait pas, deux configs de redirection cassées, un PHP 7.4 qui devait monter en 8.2.

Phase 2 — la bascule (J0 à J+2)

Jour 0  ↳ 32 sites "simples" (groupe A)
          ↳ Bascule par lots de 8
          ↳ TTL DNS abaissé à 60s la veille
          ↳ Cutoff à 14h pour minimiser l'impact

Jour 1  ↳ 5 sites WooCommerce (groupe B)
          ↳ Bascule en mode read-only puis switch
          ↳ Synchronisation finale des sessions

Jour 2  ↳ 2 Symfony + 1 facturation (groupe C)
          ↳ Bascule en heures non-critiques
          ↳ Vérification cron à 03h le lendemain

Les points de friction réels

On va pas vous dire que tout s’est passé sans accroc. Voici les vrais incidents :

  • Un client final a oublié de répondre au mail de validation — le site est resté sur l’ancienne infra 3 jours de plus.
  • Un cron job utilisait un binaire système non standard (pdftk) qu’on a dû installer manuellement.
  • Un .htaccess contenait une règle obscure qui a cassé une redirection après bascule. 15 minutes pour identifier, 2 minutes pour corriger.

Le résultat

39 sites migrés sans downtime visible pour les utilisateurs finaux. Le 40e (le récalcitrant) a été migré la semaine suivante. Aucune perte de données. Une seule interruption de 4 minutes sur un site WooCommerce pendant la synchronisation finale du panier — annoncée à l’avance, faite à 4h du matin.

Studio Pixel n’a eu aucun mail de panique de ses clients. C’est ça, le vrai indicateur de réussite d’une migration.

Note — La migration initiale est incluse dans tous nos forfaits, sans frais additionnels. On dimensionne la fenêtre selon vos contraintes — pas les nôtres.