Tu arrives sur Server Manager depuis un autre hébergeur ? L’assistant Importer depuis un autre hôte se connecte à ton ancien serveur, y recherche des sites WordPress, des sites statiques et des bases de données, puis copie l’un d’eux sous forme de bundle .tar.gz. Le bundle est ensuite transmis à l’assistant de restauration, qui installe réellement le service sur ce serveur, avec ton accord à chaque étape.
La source est en lecture seule. Rien n’est modifié chez ton ancien hébergeur. L’assistant analyse, copie ce dont il a besoin, puis se déconnecte. Tu peux le relancer plus tard pour migrer un autre site.
Que puis-je migrer ?
L’assistant reconnaît trois types d’éléments à déplacer :
| Type | Ce qu’il trouve | Ce qui arrive ici |
|---|---|---|
| Site WordPress | Un wp-config.php + une base de données accessible (identifiants préremplis quand ils sont lisibles) | Une installation WordPress complète en conteneurs, avec une nouvelle base de données et tes médias + extensions + thèmes restaurés |
| Site statique | Une racine de site avec index.html (sous /var/www/, /home/<user>/public_html/, dispositions cPanel courantes…) | L’arborescence de fichiers sous /var/www/<your-new-domain>/, servie par Caddy |
| Base de données | Une instance MySQL / MariaDB accessible depuis la connexion SSH de la source | Un nouveau conteneur de base de données avec une copie restaurée via mysqldump |
Il ne migre pas : les applications web arbitraires (frameworks Node/Python/PHP hors WordPress — utilise plutôt Déployer depuis un dépôt git pour cela), les e-mails/boîtes mail, les enregistrements DNS, ni ce qui sort des conventions standard de racine web/base de données.
Comment accéder à ton ancien hébergeur — SSH ou cPanel
L’assistant prend en charge deux modes de connexion :
| Type de source | Quand le choisir |
|---|---|
| Connexion SSH | Tu as un accès shell (les mêmes identifiants que tu utiliserais avec la commande ssh). La plupart des fournisseurs de serveurs te le donnent par défaut. |
| API cPanel | Tu n’as que cPanel, sans SSH (courant sur l’hébergement mutualisé). Utilise le token d’API propre à cPanel au lieu d’une connexion Linux. |
Si tu n’es pas sûr, essaie d’abord SSH : c’est le chemin le plus simple. Change d’onglet si la connexion échoue ou si ton hébergeur ne propose que cPanel.
Guide pas à pas
Barre du haut → menu → Importer depuis un autre hôte.
Choisis le type de source, renseigne les identifiants, puis clique sur Analyser la source.
Le mode Connexion SSH demande : hôte (IP ou domaine de l’ancien serveur), port (généralement 22), nom d’utilisateur (root, ubuntu, ton utilisateur cPanel, etc.) et soit un mot de passe, soit une clé privée OpenSSH. Tu as déjà enregistré ces mêmes identifiants dans Server Manager pour un serveur ? Clique sur Utiliser les identifiants d’un serveur enregistré pour les préremplir.
Le mode API cPanel demande : l’URL cPanel complète (port inclus — généralement https://your-domain:2083), ton nom d’utilisateur cPanel et un token d’API. Récupère le token dans cPanel → recherche « Manage API Tokens » → Create — cPanel ne l’affiche qu’une seule fois, donc copie-colle-le tout de suite.
Ce que l’assistant fait des identifiants. Ils restent uniquement dans cette session de navigateur et sont envoyés en HTTPS directement à la source. Nous ne les écrivons pas sur le disque de ce serveur et nous ne les conservons pas entre deux exécutions de l’assistant.
L’assistant se connecte à la source et parcourt pendant ~10 à 30 secondes ses emplacements web/base de données courants, en regroupant ce qu’il reconnaît par type.
Choisis un élément à migrer pour cette exécution (la sélection multiple n’existe pas encore — rouvre l’assistant pour le suivant). La carte sélectionnée reçoit un contour pêche.
Si l’analyse ne trouve rien, l’assistant t’indique les racines qu’il a vérifiées + les éventuels avertissements (erreurs de permissions, wp-config illisible, etc.). Ajuste les identifiants de la source ou la structure des chemins si l’élément manquant se trouve dans une racine non standard.
Cette étape varie selon le type :
- WordPress → choisis le domaine qui hébergera le site migré (il peut être identique à l’ancien — tu basculeras le DNS ensuite — ou tout nouveau), puis confirme les identifiants de base de données (préremplis depuis
wp-config.phps’il est lisible). - Site statique → choisis éventuellement un domaine. Laisse vide pour le servir pour l’instant sur l’IP de ton serveur ; tu pourras ajouter un domaine plus tard depuis le panneau du service.
- Base de données → choisis un titre pour la nouvelle base de données sur ce serveur et, dans de rares cas, remplace les identifiants
mysqldump.
Clique sur Démarrer l’import.
Server Manager récupère les données depuis la source et assemble sur ce serveur un bundle au format Server Manager. Les lignes de progression se mettent à jour en temps réel (création de l’archive, transfert, hachage, etc.). Côté source, il ne s’agit que de lectures : aucune écriture, aucun fichier temporaire laissé derrière.
Ne ferme pas la fenêtre en plein import. Si tu le fais, le transfert en cours est annulé et tu devras recommencer. Le nettoyage se fait automatiquement : les fichiers partiels dans /tmp/helm-restore/ sur ce serveur sont supprimés sous 24 heures, ou tu peux les nettoyer immédiatement depuis l’écran d’erreur si quelque chose échoue.Une fois le bundle assemblé, la fenêtre de migration se ferme et l’assistant de restauration s’ouvre avec le bundle tout juste arrivé déjà sélectionné. C’est la même fenêtre que celle utilisée à l’arrivée par le flux Déplacer vers un autre serveur, avec le même bouton Restaurer ce bundle en un clic.
Clique sur Restaurer ce bundle et le chat prend le relais : Faro lit le manifeste, lance l’installation sur ce serveur et s’arrête pour te demander ton accord à chaque commande — docker compose up, la modification du Caddyfile, le wp search-replace si le domaine a changé, etc.
Quand c’est terminé, le site migré apparaît sous forme de carte de service sur ton écran d’accueil — comme tout ce que tu aurais déployé directement ici.
Si tu as utilisé un nouveau domaine pour la destination, c’est terminé : Caddy émet un certificat TLS pour lui en ~30 s et le site est en ligne.
Si tu as utilisé le même domaine que chez l’ancien hébergeur, la migration a été effectuée contre l’IP de ton ancien serveur. Pour déplacer le trafic, mets à jour l’enregistrement A chez ton fournisseur DNS pour qu’il pointe vers ce serveur. Pendant le temps de propagation DNS (généralement 1 à 10 min), le trafic bascule vers la copie migrée et Caddy renouvelle automatiquement le certificat sous la nouvelle IP. L’ancienne installation sur la source continue de servir le même domaine jusqu’à la propagation du DNS ; tu peux l’arrêter côté source une fois que la migration te convient.
Avertissement DNS sur l’écran final. L’assistant affiche un encart si le domaine de destination ne pointe pas encore ici — Caddy ne peut pas obtenir de certificat HTTPS tant que le DNS n’est pas propagé. L’étape de restauration s’arrête aussi et te prévient si le DNS n’est pas encore en place.
Questions fréquentes
Mon site sera-t-il indisponible pendant la migration ? Non — la source continue de servir le trafic pendant tout le processus. La migration ne fait que copier. Tu n’as une interruption qu’au moment où tu bascules le DNS (ou jamais, si tu utilises un nouveau domaine sur le nouveau serveur).
Et les extensions / thèmes / code personnalisé sur WordPress ? Ils sont inclus dans le bundle. La migration capture les fichiers WordPress (thèmes, extensions, uploads) ET la base de données dans un instantané cohérent. Après restauration, le site se comporte à l’identique : même contenu, mêmes URL (ou URL réécrites si tu as choisi un autre domaine).
Ma base de données est plus grosse que l’espace libre sur le disque de la source. Ça ne fonctionnera pas tel quel : mysqldump a brièvement besoin, sur la source, d’un espace temporaire équivalent à la taille du dump. Libère d’abord de l’espace sur la source, ou migre manuellement via des dumps SQL (télécharge le dump → envoie-le ici via Restaurer depuis une sauvegarde).
Puis-je migrer depuis autre chose que SSH/cPanel ? Aujourd’hui, non : la logique d’analyse/sonde ne connaît que ces deux modes d’accès. Pour les autres panneaux (Plesk, DirectAdmin, etc.), la marche à suivre est : connecte-toi manuellement à la source en SSH, utilise tar pour ton webroot, mysqldump pour ta base de données, empaquette le tout dans un .tar.gz correspondant à la structure du bundle de sauvegarde, puis importe-le via Restaurer depuis une sauvegarde. Si tu as besoin de la spécification exacte du format de bundle pour en créer un à la main, demande-la via Contact et nous te la partagerons.
Que se passe-t-il si la migration échoue à mi-chemin ? L’écran d’erreur propose un bouton Nettoyer maintenant en un clic, qui supprime tous les répertoires de préparation partiellement écrits sous /tmp/helm-restore/. Côté source, rien n’a été modifié. Tu peux relancer l’assistant depuis le début sans risque.
Est-ce que cela écrasera un site existant à cette destination ? Seulement si tu l’acceptes explicitement à l’étape de restauration. Par défaut, lors du passage au chat, l’installation se fait côte à côte : tu choisirais « cloner vers un nouveau domaine » (ou, pour les bases de données, « cloner à côté » avec un suffixe) s’il existe déjà un service sur le domaine cible.
Reste-t-il quelque chose sur la source après la migration ? Aucun artefact ajouté par nous. L’assistant ne fait que des appels en lecture ; la seule chose qui écrit sur la source est mysqldump (pour les migrations WordPress + bases de données), qui produit un fichier que l’assistant télécharge puis supprime immédiatement. Une fois l’assistant déconnecté, la source est dans le même état qu’avant.
Secrets — sont-ils réutilisés ou renouvelés ? Le mot de passe de base de données issu de wp-config.php sert à exécuter mysqldump sur la source, puis il est supprimé. Le site restauré démarre avec de nouveaux identifiants de base de données générés par le passage au chat : aucun identifiant côté source ne se retrouve dans la nouvelle installation.
Ce qui n’est PAS couvert ici
- Restauration bundle vers bundle (tu as déjà un
.tar.gzexporté depuis ailleurs) → consulte directement Restaurer depuis une sauvegarde. - Déplacement de serveur à serveur dans Server Manager (la source et la destination sont toutes deux gérées par Helm) → consulte Sauvegardes → Déplacer vers un autre serveur. Ce chemin est plus efficace : pas d’étape de sonde, pas de reconstruction du manifeste.
- Changement de moteur (tu utilises nginx/Apache et tu veux Caddy ici) → consulte Migrer vers Caddy. C’est un autre problème ; ce flux réécrit les configs sur place, il ne récupère pas de bundle.
- E-mail + DNS → non couvert ici. Configure-les séparément via Connecter un domaine et Configurer l’e-mail pour ton domaine.
Référence
Chemins source vérifiés par l’analyse SSH :
/var/www/*/— racine vhost Nginx / Apache courante/srv/www/*/— alternative à la Debian/home/*/public_html/— racine de site à la cPanel/home/*/domains/*/public_html/— racine de site à la DirectAdmin- WordPress : tout chemin ci-dessus contenant un
wp-config.php - Bases de données : recensées via
mysql -e "SHOW DATABASES"en utilisant le~/.my.cnfde l’utilisateur SSH s’il existe
Endpoints d’analyse cPanel utilisés :
WebVhosts(liste les racines de site des vhosts)MysqlFE/listdbs(liste les bases de données)- Sonde de l’arborescence par vhost pour
wp-config.php
Zone de préparation sur disque pendant la migration :
- Côté source : mysqldump temporaire sous
/tmp/, puis suppression immédiate - Ce serveur :
/tmp/helm-restore/<id>/<bundle>.tar.gz— le même chemin que celui utilisé par l’assistant de restauration
Format de bundle : le format propre à Server Manager, interchangeable avec celui produit par l’onglet Sauvegarde — une migration puis restauration est donc identique octet pour octet à une sauvegarde puis restauration (la seule différence est l’origine du bundle).