Scénario illustratif : Imaginons Cedar Studio, une agence de design fictive de 32 personnes utilisant ownCloud Classic 10 avec un annuaire LDAP, des espaces de stockage personnels, des partages de groupe, des liens publics et un montage de stockage externe pour les projets. L’agence souhaite migrer vers ownCloud Infinite Scale (oCIS) sans présumer que l’installation d’un nouveau serveur transférera ses données et ses autorisations. Cet exemple est hypothétique ; il ne s’agit pas d’un compte rendu de migration réalisée.
La méthode recommandée par ownCloud consiste en une migration guidée via l' migrate-to-ocisapplication installée sur le serveur Classic et occdes commandes dédiées. Il s'agit d'un transfert progressif vers une cible oCIS distincte et propre, et non d'une mise à niveau directe de la base de données ou du répertoire de données Classic. Le manuel de migration indique que la source reste opérationnelle pendant la majeure partie du processus, mais ne décrit ni la synchronisation continue ni la migration finale sans interruption de service. Avant la mise en production, planifiez une bascule contrôlée et assurez-vous de la compatibilité des versions de la source et de la procédure de gel final des écritures auprès du support ownCloud.
Les étapes ci-dessous suivent le guide de migration officiel d'ownCloud Server 11.0 et la documentation d'authentification et de sauvegarde d'Infinite Scale 8.2 disponibles le 6 octobre 2026. La syntaxe des commandes, les variables d'environnement et les modalités de support peuvent changer ; veuillez les confirmer à l'aide de la documentation correspondant à vos versions installées.
Pour Cedar Studio, la première étape consiste à lister les utilisateurs, les groupes, les comptes activés et désactivés, les dossiers partagés, les partages de liens, les montages externes et tous les utilisateurs locaux absents de LDAP. Il est important d'identifier les équipes qui dépendent de chaque élément. Cela permet d'éviter de considérer un transfert réussi de fichiers personnels comme la preuve que tous les flux de travail antérieurs ont été migrés.
Conformément au guide de migration, la migration permet de transférer les utilisateurs et groupes activés, ainsi que leurs appartenances, les fichiers du répertoire personnel de chaque utilisateur activé et les partages d'utilisateurs, de groupes et de liens. Les fichiers sont placés dans l'espace personnel de chaque utilisateur sur oCIS. Les utilisateurs désactivés et leurs fichiers sont ignorés. Le processus ne migre pas les mots de passe ni les points de montage externes. Les données présentes sur les points de montage externes et les partages reçus sont exclues du transfert des fichiers personnels et doivent être traitées séparément. Il convient d'inventorier ces emplacements et de désigner manuellement un responsable de la migration.
| Article classique | Comportement migratoire documenté | Plan pour Cedar Studio |
|---|---|---|
| Utilisateurs et groupes autorisés | Transféré ou mappé, selon le système d'identité dorsal. | Vérifiez que tous les comptes et abonnements attendus sont visibles dans oCIS. |
| Fichiers dans les répertoires personnels des utilisateurs | Transféré dans l'espace personnel de chaque utilisateur. | Comparez les dossiers et fichiers représentatifs après le transfert. |
| Partages d'utilisateurs, de groupes et de liens | Les enregistrements de partage sont migrés, sous réserve de l'absence d'utilisateurs, de groupes ou de la politique de mot de passe des liens. | Retestez l'accès avec les comptes du propriétaire et du destinataire. |
| Mots de passe et comptes désactivés | Les mots de passe ne sont pas transférés ; les utilisateurs désactivés sont ignorés. | Préparer l'intégration des comptes et vérifier quels comptes désactivés doivent être réactivés avant la migration. |
| Supports externes et données partagées reçues | Les données de montage externe sont exclues du transfert de fichiers. | Recréez les points de montage ou copiez les données sources séparément, puis testez l'accès. |
Notez également si des liens publics sans mot de passe sont utilisés. Par défaut, oCIS exige un mot de passe pour les liens publics ; ces liens classiques peuvent ne pas être migrés si la politique cible n'est pas modifiée. N'assouplissez pas cette politique uniquement pour préserver les anciennes URL. Déterminez si les propriétaires des liens doivent plutôt créer de nouveaux liens protégés par mot de passe. Les mots de passe des liens protégés migrés ne correspondront pas aux anciens mots de passe ; les utilisateurs devront donc les réinitialiser après la migration.
Créez et testez une instance oCIS distincte avant de transférer les données de production. Le guide de migration exige que les deux systèmes soient opérationnels et accessibles l'un à l'autre. Il précise également que le système cible doit être vierge : les utilisateurs ou données préexistants peuvent entrer en conflit avec le contenu importé. Sauvegardez l'instance Classic actuelle et préparez un plan de restauration pour la maintenir disponible jusqu'à ce que les utilisateurs acceptent le nouveau service.
La migration nécessite l'installation d'une application ownCloud sur le serveur Classic. Cette application est fournie dans le cadre d'une migration guidée ; la documentation invite les administrateurs à contacter le support ownCloud pour l'obtenir. L'application inclut son propre fichier binaire rclone. N'utilisez pas un package Marketplace quelconque ni une autre opération de copie de fichiers pour remplacer la procédure documentée de cette application.
Du côté d'oCIS, activez le auth-appservice et l'authentification de l'application. Le guide de migration exige également que l'emprunt d'identité soit activé et qu'un jeton d'application soit créé pour l'administrateur oCIS. La documentation d'Infinite Scale 8.2 auth-app précise que l'emprunt d'identité est destiné à la migration et ne doit pas rester activé en production. Considérez-le comme un paramètre de migration temporaire : protégez le jeton, limitez son accès et désactivez l'emprunt d'identité (uniquement pour la migration) une fois celle-ci terminée. Dans un déploiement distribué, appliquez les paramètres au service approprié, conformément à la documentation.
Pour l'environnement hypothétique Cedar Studio, la cible oCIS doit être testée avec le même service LDAP que celui utilisé par le serveur Classic. Il est recommandé de conserver les identifiants dans le système de sécurité du déploiement plutôt que de les enregistrer dans l'historique du shell ou dans un runbook partagé. Le guide de migration officiel d'ownCloud détaille les exigences de la cible et indique la documentation d'ownCloud concernant l'application de migration. Le guide d'authentification oCIS 8.2 explique les jetons d'application et l'emprunt d'identité.
oCIS doit pouvoir identifier les utilisateurs et les groupes avant la migration de leurs fichiers et partages. Cedar Studio utilisant déjà LDAP, son administrateur connectera oCIS au même annuaire, vérifiera que les utilisateurs peuvent se connecter et s'assurera que les identifiants correspondent aux comptes prévus. Le guide ownCloud indique des adresses e-mail uniques et valides pour chaque utilisateur Classic activé. Pour les utilisateurs Classic utilisant LDAP, il précise également l'attribut « username », généralement « nom_utilisateur » uidou samAccountName« nom_groupe », ainsi que les paramètres de schéma LDAP oCIS correspondants. Veillez à faire correspondre les attributs à l'annuaire réel ; ne copiez pas les exemples de valeurs sans les vérifier.
Si Classic utilise des comptes locaux tandis qu'oCIS utilise un annuaire LDAP externe, créez ou migrez les utilisateurs et groupes correspondants vers cet annuaire avant le transfert de fichiers. Les noms d'utilisateurs et de groupes doivent correspondre. Le système de gestion des identités interne d'oCIS est un annuaire intégré limité, conçu pour les petites configurations ou les tests ; ownCloud recommande un véritable annuaire LDAP ou un système de gestion des identités externe pour la production. La procédure de migration officielle ne prend pas en charge la présence d'utilisateurs Classic locaux et d'utilisateurs utilisant un annuaire LDAP dans une même branche de migration. Il est préférable de résoudre ce problème d'architecture avec l'aide du support technique plutôt que d'improviser en cours de route.
Une fois l'application de migration installée et activée sur Classic, adaptez le chemin d'accès et le compte de service indiqués à votre installation. Le guide utilise /var/www/owncloudles www-dataexemples suivants :
sudo -u www-data php /var/www/owncloud/occ app:enable migrate_to_ocis
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:init ocis.example.com
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:verifyLa commande de vérification contrôle que les utilisateurs activés possèdent des adresses e-mail valides et uniques. Corrigez les problèmes signalés avant de poursuivre, plutôt que d'ignorer la vérification. Si un utilisateur désactivé doit être déplacé, examinez son compte, activez-le sur Classic avant la vérification et intégrez-le au plan de migration. Cedar Studio doit également vérifier la connexion LDAP à oCIS avec plusieurs utilisateurs représentatifs avant le début du transfert de données.
Suivez la branche du guide officiel correspondant à votre configuration d'identité. Si les utilisateurs Classic sont locaux et utilisent le système de gestion des identités intégré à oCIS, la procédure décrite dans le guide comprend la migration des utilisateurs, l'attribution d'un rôle oCIS et la migration des groupes. Un seul rôle est attribué aux utilisateurs migrés ; les rôles Classic ne sont pas conservés à l'identique et les privilèges de sous-administrateur Classic n'ont pas d'équivalent dans oCIS. Vérifiez manuellement les accès administrateur. Si les deux systèmes utilisent le même annuaire LDAP, assurez-vous que les utilisateurs et les groupes sont déjà disponibles dans oCIS et suivez la branche LDAP au lieu de créer des doublons.
Une fois les utilisateurs, les groupes et les rôles définis, les commandes de fichiers et de partage documentées utilisent le nom d'utilisateur administrateur oCIS comme dernier argument. Le mot de passe administrateur classique est demandé de manière interactive.
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:migrate:files admin
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:migrate:shares adminLancez le transfert de fichiers avant le transfert de partage, comme indiqué dans la procédure de migration. Les utilisateurs qui ne se sont jamais connectés et qui n'ont aucun fichier, ainsi que les utilisateurs absents d'oCIS, sont ignorés lors de l'étape de transfert de fichiers. Les partages impliquant des utilisateurs ou des groupes manquants peuvent être signalés comme des erreurs pendant la migration. Pour Cedar Studio, cela signifie que l'équipe doit examiner la sortie de la commande et l'inventaire des partages ; une migration terminée sans erreur fatale ne garantit pas le bon fonctionnement de tous les partages.
Le guide de migration précise qu'il est impossible de répéter les étapes réussies sans supprimer au préalable les données cibles créées. Une --forceréinitialisation de l'initialisation ne supprime pas les fichiers déjà migrés d'oCIS. N'utilisez pas les options de réinitialisation comme stratégie de nouvelle tentative systématique. En cas d'échec d'une étape, conservez les journaux, identifiez les éléments créés et consultez le guide de migration ou le support avant de décider de réparer la cible ou de redémarrer sur une cible propre.
Pour une migration sécurisée, Cedar Studio planifie une période durant laquelle les employés cessent de modifier les fichiers dans Classic, exécute la migration approuvée, puis redirige les clients et les utilisateurs vers oCIS une fois les vérifications effectuées. Ce gel des écritures est une mesure de sécurité opérationnelle et ne prétend pas que l'application de migration effectue une synchronisation en temps réel. Le guide de migration publié ne décrit ni la synchronisation continue ni la commande de copie delta finale. Si l'entreprise ne peut tolérer un gel des écritures, veuillez contacter le support ownCloud pour obtenir un plan de transition adapté à votre version avant de garantir une migration sans interruption de service.
Validez à l'aide d'une liste de contrôle plutôt qu'avec une seule connexion d'administrateur :
Conservez Classic disponible en lecture seule ou gelé jusqu'à ce que le responsable métier valide et que les enregistrements requis aient été vérifiés. Supprimez la fonctionnalité d'emprunt d'identité temporaire et révoquez le jeton de l'application de migration lorsqu'il n'est plus nécessaire. Effectuez ensuite une sauvegarde oCIS et testez-la en suivant la procédure correspondant à son architecture de stockage. La documentation officielle d'oCIS 8.2 relative aux sauvegardes précise que l'instance doit être complètement arrêtée pour la procédure de sauvegarde et explique que les métadonnées et les objets binaires binaires peuvent avoir des chemins de stockage distincts.
Dans l'exemple de Cedar Studio, la réussite ne se limite pas au chargement de l'interface web oCIS. Elle implique que les employés puissent s'authentifier auprès de la source d'identité prévue, accéder au contenu de leur répertoire personnel, ouvrir les fichiers d'équipe et utiliser les partages recréés ou migrés avec les autorisations attendues. La réinitialisation des mots de passe, les montages externes et les modifications des liens publics sont pris en compte, tandis que Classic reste disponible jusqu'à validation. Si l'un de ces contrôles échoue, suspendez la migration, consignez les utilisateurs et les objets concernés et résolvez le problème avant de considérer oCIS comme système de référence.
Comparez 10 outils de balayage ping pour une découverte rapide du réseau local, une analyse multiplateforme et la gestion des adresses IP. Découvrez ce qu'un balayage peut – et ne peut pas – vous révéler.
Comparez six outils de gestion de réseau pour la surveillance des performances, notamment la couverture SNMP, la cartographie, les alertes, les modèles de déploiement et les compromis en matière de coûts.
Comparez sept moniteurs de ping gratuits et open source, allant des suites réseau complètes aux sondes de latence ciblées, et choisissez celui qui convient le mieux à vos besoins en matière de disponibilité, de perte de paquets et d'historique.
Comparez les meilleurs analyseurs Wi-Fi pour Windows, iPhone et Android, incluant des outils pour la congestion des canaux, la couverture du signal, les cartes thermiques et le dépannage réseau.
Découvrez ce que signifie la QoS dans le domaine des réseaux, comment les marquages DSCP et les files d'attente de trafic priorisent la voix, la vidéo et les applications professionnelles, et ce que la QoS ne peut pas corriger.
Comparez les logiciels serveurs SFTP fiables pour Windows et Linux, notamment OpenSSH, Bitvise, SolarWinds et SFTPGo. Trouvez la solution idéale pour vos besoins en matière de sécurité et de transfert de fichiers.
Comparez sept outils de gestion d'adresses IP pour la découverte de sous-réseaux, la coordination DNS et DHCP, l'inventaire réseau et l'IPAM open source.
Mettez en place une surveillance réseau pratique avec une couverture claire des périphériques, des indicateurs de performance utiles, des alertes exploitables et une comparaison de SolarWinds NPM, PRTG et OpManager.
Comparez les outils d'analyse réseau pour la découverte rapide des périphériques, les analyses IP multiplateformes et la gestion des identités et des accès IP (IPAM) d'entreprise, avec des conseils pour adapter chaque option à votre réseau.
Utilisez l'option --traceroute de Nmap pour associer les sauts à un hôte autorisé, comprendre les résultats des sauts et du RTT, et résoudre les problèmes de réponses manquantes sans sur-analyse.
