Aller au contenu
Agencei

Cloud & DevOps

Migration de serveur : déplacer vos services vers une nouvelle machine sans rien perdre

La migration de serveur consiste à transférer l'ensemble des services hébergés sur une machine (sites web, bases de données, messagerie, tâches planifiées, certificats, configurations) vers un nouveau serveur dédié ou VPS. Elle est souvent déclenchée par une fin de support de l'OS, une machine sous-dimensionnée, un changement de fournisseur ou un besoin de sécurité.

Ce service s'adresse aux PME, agences et éditeurs qui exploitent un ou plusieurs serveurs avec ou sans panneau d'administration (Plesk, cPanel, ISPConfig) et qui n'ont pas les ressources internes pour mener l'opération sans risque. Un serveur accumule des années de réglages implicites : c'est ce qui rend l'exercice délicat.

Nous inventorions chaque service, reconstruisons l'environnement cible sur une version d'OS supportée, transférons les données avec rsync et des dumps cohérents, puis basculons le trafic après une recette complète. L'ancien serveur reste disponible le temps de confirmer que tout fonctionne.

Dans quelles situations intervenons-nous ?

Fin de support de l'OS

Votre serveur tourne sous Debian, Ubuntu ou CentOS en fin de vie et ne reçoit plus de correctifs de sécurité. La mise à niveau sur place étant risquée, la migration vers une machine neuve sur un OS supporté est souvent la voie la plus sûre.

Serveur saturé ou vieillissant

Charge CPU constante, disque plein, mémoire insuffisante ou matériel ancien : le serveur ne suit plus la croissance des sites et applications qu'il héberge.

Changement de fournisseur

Vous quittez un hébergeur pour OVH, Hetzner, Scaleway, AWS ou un autre, pour des raisons de coût, de localisation des données ou de qualité de service.

Migration Plesk ou cPanel

Vos sites sont gérés via un panneau d'administration. Il faut transférer abonnements, domaines, boîtes mail, bases et certificats, en utilisant les outils de migration natifs ou une reconstruction manuelle lorsque les versions sont incompatibles.

Consolidation ou découpage

Regrouper plusieurs petits serveurs sur une machine plus puissante, ou au contraire isoler une base de données ou une application critique sur un serveur dédié.

Notre intervention

  1. 1

    Inventaire du serveur source

    Recensement des sites, bases, versions de PHP, Node.js ou Java, tâches cron, services système, ports ouverts, certificats, règles de pare-feu et dépendances externes. Nous documentons aussi les réglages implicites qui ne figurent dans aucune documentation.

  2. 2

    Conception du serveur cible

    Choix de l'OS et du dimensionnement, installation des mêmes versions logicielles ou de versions plus récentes compatibles, durcissement de base (SSH par clé, fail2ban, pare-feu), et mise en place des sauvegardes dès le premier jour.

  3. 3

    Transfert initial des données

    Copie des fichiers avec rsync, export des bases avec des dumps cohérents ou une réplication temporaire, transfert des boîtes mail avec imapsync si nécessaire. Cette première passe se fait sans impact sur la production.

  4. 4

    Recette complète

    Chaque site et service est testé sur le serveur cible via le fichier hosts : pages, formulaires, paiement, envoi d'e-mails, tâches planifiées, performance. Les écarts détectés sont corrigés avant la bascule.

  5. 5

    Bascule contrôlée

    Baisse préalable des TTL DNS, gel des écritures, synchronisation delta finale avec rsync et dernier dump, changement des enregistrements DNS ou de l'IP failover, puis surveillance des journaux pendant les premières heures.

  6. 6

    Décommissionnement

    L'ancien serveur est conservé en lecture seule pendant une période de sécurité, puis ses données sont archivées et la machine résiliée. Nous remettons une documentation à jour de la nouvelle installation.

Technologies utilisées

  • Debian et Ubuntu
  • rsync et SSH
  • Plesk et cPanel
  • Nginx et Apache
  • MySQL, MariaDB et PostgreSQL
  • imapsync
  • Let's Encrypt
  • OVH, Hetzner, Scaleway et AWS
  • fail2ban et nftables
  • Docker

Pourquoi choisir Agencei ?

  • Inventaire exhaustif avant toute action

    La majorité des migrations ratées le sont à cause d'un service oublié : une tâche cron, un certificat, un webhook. Nous partons des processus réellement en cours sur la machine, pas seulement de la documentation.

  • Bascule réversible

    L'ancien serveur reste intact et accessible tant que la migration n'est pas validée. En cas de problème, le retour arrière consiste à remettre les DNS ou l'IP failover sur la machine d'origine.

  • Mise à niveau plutôt que copie à l'identique

    Nous profitons de la migration pour passer sur des versions supportées de PHP, Node.js ou de la base de données, en testant la compatibilité des applications au préalable.

  • Sécurisation dès l'installation

    Le serveur cible est livré durci : authentification par clé, pare-feu restrictif, mises à jour automatiques de sécurité et sauvegardes externalisées configurées.

En bref

Qu'est-ce que ce service ?
La migration de serveur est le transfert complet des sites, bases de données, messagerie, tâches planifiées et configurations d'un serveur dédié ou VPS vers une nouvelle machine, avec ou sans panneau Plesk ou cPanel.
À qui s'adresse-t-il ?
PME, agences et éditeurs qui exploitent un serveur en fin de support, saturé ou chez un fournisseur qu'ils souhaitent quitter, sans équipe système en interne.
Quel problème résout-il ?
Éviter les pertes de données, services oubliés, coupures prolongées et régressions applicatives lors du changement de serveur ou de la mise à niveau de l'OS.
Combien de temps faut-il prévoir ?
Généralement quelques jours pour un VPS simple, plusieurs semaines pour un serveur mutualisant de nombreux sites, des boîtes mail et des applications hétérogènes. La bascule finale prend souvent quelques minutes.
Quels facteurs influencent le prix ?
Le nombre de sites et services, le volume de données et de messagerie, la présence d'un panneau d'administration, l'écart de versions entre source et cible, et les exigences de disponibilité.
Comment se déroule l'intervention ?
Inventaire exhaustif, construction et durcissement du serveur cible, transfert initial avec rsync et dumps, recette complète via le fichier hosts, bascule DNS après synchronisation delta, puis décommissionnement.
Quels sont les risques ?
Service ou tâche cron oubliée, incompatibilité de version PHP ou base de données, enregistrements DNS ou SPF non mis à jour, et données écrites sur l'ancien serveur après la bascule si les écritures ne sont pas gelées.
Quelles alternatives existent ?
Mise à niveau de l'OS sur place, conteneurisation progressive des applications sur le serveur existant, ou migration vers une plateforme managée qui supprime la gestion du serveur.

Questions fréquentes

Faut-il migrer ou mettre à niveau l'OS sur place ?

La mise à niveau sur place est possible sur certaines distributions, mais elle peut laisser des paquets obsolètes et rend le retour arrière difficile. Migrer vers une machine neuve sur un OS supporté offre un environnement propre et un plan de repli simple : l'ancien serveur reste disponible.

Combien de temps dure une migration de serveur ?

Cela dépend du nombre de services et du volume de données. Un VPS hébergeant quelques sites se migre en général en quelques jours, un serveur Plesk avec des dizaines d'abonnements et de la messagerie peut demander plusieurs semaines de préparation. La bascule elle-même se limite souvent à quelques minutes.

Les boîtes mail sont-elles transférées ?

Oui. Nous transférons les comptes et leur contenu avec les outils natifs de Plesk ou cPanel, ou avec imapsync pour une migration entre systèmes différents. Les enregistrements MX, SPF, DKIM et DMARC sont reconduits ou mis à jour.

Peut-on changer d'adresse IP sans impact ?

Oui, à condition d'abaisser les TTL DNS quelques jours avant et de mettre à jour toutes les références à l'ancienne IP (enregistrements A, SPF, listes blanches chez des partenaires). Chez certains hébergeurs, une IP failover permet même de conserver l'adresse.

Que se passe-t-il si une application n'est pas compatible avec les nouvelles versions ?

Nous le détectons pendant la recette, avant la bascule. Selon le cas, nous corrigeons l'application, installons la version logicielle requise en parallèle, ou isolons l'application dans un conteneur Docker avec sa propre version.

Parlez-nous de votre projet

Décrivez votre besoin en quelques lignes : nous revenons vers vous avec une première analyse et les prochaines étapes.