Changer de machine sans perdre les comptes, partages et calendriers demande plus qu'une copie du dossier de fichiers. En 2026, une migration Nextcloud vers un nouveau serveur doit déplacer un état cohérent : code, configuration, base de données, données et composants associés. La procédure officielle impose une instance hors ligne pendant le transfert, sauf architecture de haute disponibilité conçue avant l'installation. Ce guide couvre le cas courant d'un serveur unique remplacé par une nouvelle machine. Il sépare la préparation, la copie, les contrôles et la bascule DNS afin de conserver l'ancien serveur comme solution de retour jusqu'à la recette finale.
Que faut-il conserver pendant une migration Nextcloud ?
Une instance Nextcloud ne se limite pas aux documents visibles dans Files. La base de données conserve notamment les comptes, groupes, partages et références des fichiers. config.php contient les réglages essentiels du déploiement. Le répertoire de données contient les fichiers lorsque le stockage primaire est local. Les applications personnalisées et le thème peuvent aussi être nécessaires au fonctionnement attendu.
La documentation officielle de sauvegarde recense cinq ensembles : configuration, applications personnalisées, données, thème et base. Pour un déplacement complet, la procédure de migration demande en plus de copier les fichiers du programme et les journaux utiles. Copier uniquement /data vers une installation neuve ne recrée donc ni les partages, ni les comptes, ni les métadonnées.
Dressez un inventaire avant toute commande :
- version exacte de Nextcloud et méthode d'installation ;
- version de PHP, serveur web et moteur de base ;
- chemins du code, de
config/, decustom_apps/, dethemes/et des données ; - taille des données et de la base ;
- services externes, dont Redis, LDAP, SMTP, stockage objet, proxy inverse et suite bureautique ;
- tâches cron, certificats, DNS, pare-feu et supervision ;
- applications actives et compatibilité avec la cible.
Pour replacer ces briques dans l'architecture générale, consultez le guide Nextcloud. Si vous ne disposez pas déjà d'une copie restaurable, commencez par le guide de sauvegarde Nextcloud avant de planifier l'arrêt.
Migration et mise à niveau sont deux opérations différentes
Évitez de changer en même temps de serveur, de version majeure Nextcloud, de moteur de base et de méthode d'installation. La documentation interdit de sauter une version majeure lors d'une mise à niveau. Pour réduire les variables, migrez d'abord une version identique ou explicitement compatible, validez-la, puis organisez la mise à niveau séparément.
Comment préparer le nouveau serveur avant l'arrêt ?
Installez le système, le serveur web, PHP et la base sans encore ouvrir l'instance aux utilisateurs. Vérifiez les prérequis correspondant à la version de Nextcloud, pas ceux d'une autre branche. Les versions prises en charge évoluent. Il faut aussi retrouver les modules PHP, limites d'envoi, extensions et permissions nécessaires à votre installation.
Reproduisez les dépendances relevées dans config.php. Un cache Redis déclaré mais absent peut empêcher le démarrage. Il en va de même pour une base distante, un annuaire LDAP, un bucket objet ou un proxy dont le nom n'est pas joignable depuis la cible. Testez la résolution DNS, les ports sortants et les certificats depuis le nouveau serveur avant la fenêtre de maintenance.
Préparez les chemins avec les propriétaires attendus par le serveur web. Garder le même chemin absolu pour le répertoire de données simplifie le transfert. Nextcloud identifie un stockage local par son chemin absolu. La documentation de dépannage du répertoire de données avertit qu'un changement mal traité peut créer des fichiers orphelins, des doublons ou une perte de liens partagés.
Mesurez ensuite le temps de copie sur un échantillon représentatif. Une fenêtre réaliste inclut le dump SQL, la copie finale, l'import, les corrections de permissions et la recette. Informez les utilisateurs que la synchronisation sera indisponible. Le mode maintenance bloque les sessions et les nouvelles connexions, mais les clients doivent aussi avoir le temps d'enregistrer cet état.
Comment transférer la base, les fichiers et la configuration ?
La procédure officielle indique que la migration doit se dérouler sans accès à l'instance. Depuis la racine Nextcloud de l'ancien serveur, activez le mode maintenance avec le compte HTTP. L'exemple ci-dessous utilise www-data, courant sur Debian et Ubuntu. Adaptez le compte et le chemin à votre installation.
cd /var/www/nextcloud
sudo -E -u www-data php occ maintenance:mode --on
Nextcloud recommande d'attendre six à sept minutes afin que les clients de synchronisation constatent le mode maintenance, puis d'arrêter le serveur web ou le service applicatif. Désactivez aussi la tâche cron pendant l'opération. Créez ensuite un dump de la base. Pour MariaDB avec prise en charge des caractères sur quatre octets :
mariadb-dump \
--single-transaction \
--default-character-set=utf8mb4 \
-h DB_SOURCE -u nextcloud -p nextcloud \
> /srv/transfert/nextcloud.sql
Copiez le code, la configuration, les applications personnalisées, le thème, les données et les journaux nécessaires. rsync -a conserve notamment les horodatages. C'est important, car la documentation prévient qu'une modification des dates peut pousser les clients à retélécharger les fichiers. Les options -A, -X et --numeric-ids préservent respectivement ACL, attributs étendus et identifiants numériques lorsque les deux systèmes les prennent en charge.
sudo rsync -aAX --numeric-ids --info=progress2 \
/var/www/nextcloud/ NOUVEAU_SERVEUR:/var/www/nextcloud/
sudo rsync -aAX --numeric-ids --info=progress2 \
/srv/nextcloud-data/ NOUVEAU_SERVEUR:/srv/nextcloud-data/
Ces chemins sont des exemples. Ne lancez pas la commande avant d'avoir confirmé les sources, destinations, montages et espaces libres. Si les données sont stockées dans un bucket S3 primaire, le plan doit inclure la base, la configuration, les clés et l'accessibilité du bucket. Le guide Nextcloud avec stockage S3 explique pourquoi les objets seuls ne reconstituent pas l'arborescence.
Quels paramètres modifier sur le serveur cible ?
Importez la base dans une base vide créée avec le jeu de caractères adapté, puis contrôlez les permissions des fichiers. Pour MariaDB, le principe est le suivant :
mariadb -h DB_CIBLE -u nextcloud -p nextcloud \
< /srv/transfert/nextcloud.sql
Relisez ensuite chaque valeur liée au serveur dans config.php. La procédure de migration cite au minimum datadirectory, les paramètres dbhost, dbname, dbuser et dbpassword, puis trusted_domains. Vérifiez aussi les paramètres overwrite* derrière un proxy, les caches Redis ou Memcached, objectstore, SMTP, logfile et tempdirectory lorsque ces options existent.
Copiez la configuration d'origine au lieu de laisser une installation neuve générer une autre identité. Les valeurs instanceid et secret appartiennent à l'instance et ne doivent pas être régénérées pendant le déplacement. Conservez également serverid s'il est défini. Ne publiez jamais la sortie privée de config.php dans un ticket ou un journal partagé.
Si le nom public ne change pas, gardez-le dans trusted_domains et dans les réglages du proxy. Si le domaine change, ajoutez la nouvelle valeur et contrôlez le certificat, les redirections, les URL générées et les clients. Une migration physique n'oblige pas à changer l'adresse visible par les utilisateurs. Conserver le même nom réduit les reconfigurations sur les postes et mobiles.
N'exécutez pas files:scan --all par réflexe. Lorsque la base et les données ont été transférées ensemble, le cache des fichiers fait partie de l'état conservé. La commande devient pertinente dans des cas précis documentés, par exemple après certaines récupérations incohérentes. Un scan massif inutile peut être long et masquer la cause réelle d'un écart.
Comment tester avant la bascule DNS ?
Démarrez la base et le serveur web de la cible tout en gardant Nextcloud en maintenance. Avant de modifier le CNAME ou l'enregistrement public, dirigez uniquement votre poste de recette vers la nouvelle adresse, par exemple avec une résolution locale temporaire. Vous devez voir l'avis de maintenance. Vérifiez aussi qu'Apache ou Nginx et Nextcloud écrivent bien leurs journaux sans erreur nouvelle.
Contrôlez d'abord l'état en ligne de commande :
cd /var/www/nextcloud
sudo -E -u www-data php occ status
sudo -E -u www-data php occ config:list system
La seconde commande permet de relire la configuration fusionnée sans afficher les secrets privés. Désactivez ensuite le mode maintenance sur la cible pour une recette limitée, toujours avant l'ouverture générale. Testez au minimum : connexion administrateur et utilisateur, lecture et envoi d'un fichier, partage interne et public, calendrier ou contacts utilisés, application métier, envoi d'email, tâche cron, verrouillage Redis, suite bureautique et client de synchronisation de test.
Consultez la page Administration > Vue d'ensemble, les journaux et l'espace disponible. Le guide de sécurité Nextcloud fournit les contrôles de serveur, proxy, HTTPS, comptes et mises à jour à reprendre sur la cible. Corrigez les erreurs avant le DNS, pas après l'arrivée des utilisateurs.
Conservez une preuve de recette
Notez la version, l'heure du dump, le nombre ou volume d'éléments contrôlés, les comptes testés et le résultat de chaque application importante. Cette trace permet de distinguer une anomalie antérieure d'une régression liée au déplacement.
Comment basculer le DNS et prévoir le retour arrière ?
Quand la recette est validée, remettez brièvement la cible en maintenance si vos tests y ont créé des écritures, finalisez les contrôles, puis pointez le DNS vers le nouveau serveur. Conservez l'ancien système allumé mais inaccessible aux utilisateurs et toujours en maintenance. Deux instances actives sur la même base logique créeraient des états divergents.
La propagation dépend de la configuration DNS et des caches. Surveillez les accès sur l'ancienne et la nouvelle adresse afin de confirmer le déplacement du trafic. Une fois les utilisateurs reçus par la cible, retirez son mode maintenance, réactivez cron et suivez les erreurs, files d'attente, envois d'emails et synchronisations.
Le retour arrière est simple seulement tant qu'aucune nouvelle écriture utile n'a été créée sur la cible. Dans ce cas, repointez le DNS vers la source, vérifiez ses dépendances puis retirez son mode maintenance. Après reprise d'activité sur la cible, un retour exige de traiter les données produites depuis la bascule. Ne remettez pas l'ancien serveur en ligne comme si elles n'existaient pas.
Gardez la source intacte pendant la période de validation définie par votre organisation. Après acceptation, révoquez les accès temporaires, supprimez les copies de transfert non nécessaires et archivez la procédure. Vérifiez enfin la sauvegarde indépendante du nouveau serveur par une restauration isolée.
Conclusion
Migrer Nextcloud vers un nouveau serveur consiste à transférer un système cohérent, pas un simple dossier. Préparez une cible compatible, gelez les écritures, déplacez base, configuration, code et données en conservant les horodatages, puis testez la cible avant le DNS. L'ancien serveur reste en maintenance jusqu'à la validation, ce qui préserve un retour contrôlé. Si vous préférez éviter l'administration de PHP, de la base et du stockage, une offre Nextcloud gérée permet de confier cette exploitation à un hébergeur.
Découvrir l'hébergement Nextcloud GaprodEspace géré en France, sans administration du serveur