Migration d'une instance Oracle Content Management à partir d'une infrastructure cloud héritée

Si vous disposez d'instances Oracle Content Management exécutées sur une infrastructure cloud héritée avec un abonnement non mesuré, Oracle vous recommande de les migrer vers le nouvel environnement Oracle Cloud Infrastructure (OCI) natif, OCI Gen 2 (utilisation de la console Infrastructure pour gérer les instances de service). De cette façon, vous profiterez des avantages et des avancées à venir de la plate-forme cloud d'Oracle.

Pour lancer la migration, vous devez d'abord effectuer certaines étapes et la programmer avec le support technique Oracle.

Migrez votre abonnement vers un abonnement avec crédits universels. Contactez votre représentant Oracle Sales pour qu'il vous aide.
Créer une instance Oracle Content Management sur OCI à l'aide de la console Infrastructure. Il s'agit de l'instance cible vers laquelle vos données seront migrées. N'utilisez PAS cette instance tant que la migration n'est pas terminée.
Migrez les utilisateurs des comptes cloud traditionnels vers des comptes Oracle Identity Cloud Service (IDCS). Veillez à conserver les noms utilisateur afin d'affecter correctement les rôles et droits d'accès dans le cadre du processus de migration. Dans le fichier CSV exporté, l'entrée de nom utilisateur est appelée "User Login". Les rôles utilisateur sont affectés en fonction de la correspondance d'utilisateurs.
Préparez la migration en collectant les informations dont vous aurez besoin pour la demande de service et en créant la liste des intégrations en place pour obtenir les procédures à appliquer après la migration.
Soumettez une demande de service de migration, et confirmez la date et l'heure de migration.
Surveillez la progression de la migration. Votre demande de service est mise à jour au fil de la progression de la migration, et une fois celle-ci terminée, vous devez vérifier que la nouvelle instance fonctionne comme prévu.
Finalisez la migration en appliquant toutes les étapes nécessaires à la migration des intégrations en place entre votre instance et d'autres services ou applications.
Migrez vos sites contenant des ressources et rendez-les compatibles avec un site multilingue.
Migrez les ressources qui ont été exclues de la migration.
Communiquez la modification aux utilisateurs.

Correspondance d'utilisateurs

Ce tableau décrit la correspondance des groupes de droits d'accès Oracle Content Management et des rôles d'application OCI.

Groupe de droits d'accès Oracle Content Management	Rôle d'application OCI
DocumentsServiceUser	CECStandardUser
DocumentsServiceAdmin	CECServiceAdministrator
SitesServiceVisitor	CECSitesVisitor
SitesServiceAdmin	CECSitesAdministrator
ContentAdministratorRole	CECContentAdministrator
CECSStandardUser	CECStandardUser
CECSEnterpriseUser	CECEnterpriseUser

Remarque :

Si le domaine IDCS cible contient déjà un utilisateur portant le même nom, les rôles d'application OCI correspondant aux groupes de droits d'accès Oracle Content Management de l'utilisateur existant seront affectés à l'utilisateur.

Préparation à la migration

Notez l'URL de la nouvelle instance (la cible) que vous avez créée afin de l'inclure dans votre demande de migration.
Notez l'URL de l'ancienne instance (la source) afin de l'inclure dans votre demande de migration.
Dressez l'inventaire de toutes les intégrations en place entre votre ancienne instance et d'autres services ou applications, que ce soit directement ou via des appels d'API REST. Si de telles intégrations existent, vous devez effectuer certaines opérations après la migration.

Soumission d'une demande de service de migration

Lorsque vous êtes prêt à effectuer la migration, vous devez soumettre une demande de migration pour lancer le processus :

Connectez-vous au support technique Oracle Cloud.
Créez une demande de service.
Pour Type de problème, sélectionnez Migration d'instance de service, puis De l'abonnement non mesuré à OCI-Gen2.
Fournissez les informations suivantes dans la demande de service :
- URL de l'instance source (instance d'origine de la migration)
- URL de l'instance cible (instance de destination de la migration)
- Si vous utilisez Akamai distribué par Oracle, indiquez-le afin que nous puissions convenir d'une heure pour mettre à jour les URL dans votre configuration Akamai après la migration
Indiquez la date de début de migration que vous aimeriez.
Soumettez votre demande de service.
Une fois que le support technique Oracle reçoit votre demande de service de migration, nous programmons la migration en fonction de la date que vous avez demandée, et la demande de service est mise à jour avec la date et l'heure de début de la migration.
Dans la demande de service, confirmez que vous approuvez la date et l'heure de début de la migration.

La demande de service est mise à jour afin de refléter la progression de la migration. La migration des données est effectuée en back-end : aucune action n'est requise de votre part en dehors de la consultation des mises à jour de la demande de service et de la validation de la migration une fois qu'elle est terminée.

Processus de migration

Voici ce qui se produit pendant la migration :

Le support technique Oracle met à jour la demande de service au début de la migration.

Important :
A ce stade, vous ne devez apporter aucune modification à votre ancienne instance (source). Toute modification réalisée après le début de la migration n'est pas migrée vers la nouvelle instance.
Le contenu et les données de configuration sont exportés à partir de votre ancienne instance (la source) et importés dans la nouvelle instance (la cible).
Dès que la migration est terminée, le support technique Oracle met à jour la demande de service et vous demande de valider la nouvelle instance afin de vous assurer que tout fonctionne comme prévu.
Si vous rencontrez des problèmes, indiquez-les dans la demande de service. Le support technique Oracle se charge de résoudre les problèmes et vous informe via la demande de service une fois que l'instance est prête pour validation.
Une fois que tout fonctionne correctement, indiquez dans la demande de service que vous acceptez l'instance migrée.

Remarque :

L'ancienne instance reste en fonctionnement pour que vous puissiez vous y référer à des fins de validation. Vous devez également migrer tous les sites qui utilisent des ressources et migrer toutes les autres ressources exclues lors de la migration.

Finalisation de la migration

Si des intégrations ou communications étaient en place entre votre ancienne instance et d'autres services ou applications, que ce soit directement ou via des appels d'API REST, vous devrez peut-être effectuer des tâches post-migration.

Les éléments suivants s'appliquent à l'échelle du service :

Vérifiez les rôles d'application OCI et affectez les rôles qui n'existaient pas dans votre instance source, tel que le rôle d'application CECRepositoryAdministrator.
Reconfigurez les informations d'identification utilisateur pour toutes les intégrations qui les utilisent. Les informations d'identification utilisateur ne sont pas migrées.
Le modèle d'URL Oracle Content Management est différent : vous devez mettre à jour les URL dans les intégrations qui les utilisent.
Les anciennes URL utilisaient le modèle suivant :

https://<nom-service>-<nom-compte>.<région>.oraclecloud.com/documents

Les nouvelles URL utilisent le modèle suivant :

https://<nom-service>-<nom-compte>.<type-service>.ocp.oraclecloud.com/documents
Reconfigurez les paramètres CORS et de contenu imbriqué. Les paramètres du service cible ne sont pas migrés.
Les sites standard sont migrés, mais pas les sites d'entreprise. Migrez manuellement les sites d'entreprise et l'ensemble des ressources numériques et des éléments de contenu associés au site. Pour ce faire, créez un modèle pour chaque site d'entreprise, exportez le modèle à partir de l'instance source et importez-le dans l'instance cible.
Enlevez ou mettez à jour tous les contrôleurs personnalisés utilisés dans les sites migrés.

Intégration	Opérations à effectuer après la migration
Oracle Integration	Reconfigurez les informations d'identification. Mettez à jour les URL Oracle Content Management dans Oracle Integration Cloud.
Oracle Commerce Cloud	Reconfigurez les informations d'identification. Mettez à jour les URL Oracle Content Management dans Oracle Commerce Cloud.
Oracle Process Cloud Service	Reconfigurez les informations d'identification.
Oracle Eloqua Cloud Service	Reconfigurez les informations d'identification.
Oracle Intelligent Advisor	Reconfigurez les informations d'identification.
Oracle Cobrowse Cloud Service	Reconfigurez les informations d'identification.
Responsys	Reconfigurez les informations d'identification.
Visual Builder Cloud Service (VBCS)	Reconfigurez les informations d'identification. Mettez à jour les URL Oracle Content Management dans les composants VBCS.
CDN/Akamai	Si vous utilisez Akamai distribué par Oracle, convenez d'une heure avec le support technique Oracle pour mettre à jour les URL Oracle Content Management dans votre configuration Akamai. Sinon, vous devez mettre à jour vous-même les URL dans votre configuration de CDN.
Appels d'API REST	Mettez à jour les URL Oracle Content Management dans tous les appels d'API REST.
Utilisation de CLI/SDK client	Si l'URL est rendue persistante/mise en cache localement côté client, mettez à jour les URL Oracle Content Management dans la configuration.
Connecteurs	Reconfigurez les informations d'identification.

Remarque :

Tous les signets sur le contenu de votre ancienne instance ne fonctionnent plus car l'URL de la nouvelle instance a changé.

Migration de vos sites contenant des ressources

Les sites qui ne contiennent pas de ressources sont migrés automatiquement, mais pour ceux qui en contiennent, vous devez effectuer quelques étapes supplémentaires pour pouvoir les faire fonctionner dans votre nouvelle instance Oracle Content Management.

Installation d'OCE Toolkit

La commande "cec migrate-site" est nouvelle, vous devez donc installer OCE Toolkit à partir du référentiel Git WebClient même si vous l'avez téléchargé et installé précédemment.

Suivez les instructions indiquées sur la page Sites Toolkit pour télécharger et installer OCE Toolkit.

Inscription du serveur cible

Inscrivez les détails de connexion du serveur cible (le serveur vers lequel vous migrez vos sites):

> cec register-server <target_server_name>
          -e http://<target_server>:<target_port>
          -u <target_username> -p <target_password>
          -t pod_ec

<target_server_name> permet d'identifier l'adresse cible. Vous pouvez choisir n'importe quel nom.
<target_server> et <target_port> constituent l'URL utilisée pour accéder au serveur cible.
<target_username> et <target_password> sont le nom utilisateur et le mot de passe de la personne qui exportera les modèles de site à partir du serveur source afin qu'il n'y ait aucun problème de droit d'accès lors de l'import des modèles pendant la migration.
La valeur "pod_ec" correspond au type du serveur cible. Elle identifie le type de serveur sur lequel l'instance est créée.

Migration de vos sites

Pour migrer vos sites, procédez comme suit :

Sur le serveur source, créez des modèles à partir de chaque site comprenant des ressources.
Sur le serveur source, exportez chaque modèle. Veillez à effectuer cette étape sous le nom de l'utilisateur indiqué lors de l'inscription du serveur cible.
Sur le serveur cible, connectez-vous en tant qu'administrateur de référentiel (utilisateur doté du rôle CECRepositoryAdministrator). Ensuite, création de référentiel pour les ressources qui seront importées avec le modèle.
Pour chaque modèle téléchargé, exécutez la commande suivante en remplaçant <site_name> par le nom que vous souhaitez donner au site sur le serveur cible :
```
> cec migrate-site <site_name> --template <template_path_and_name> 
--destination <registered_target_server_name> --repository <repository_name>
```
Sur le serveur cible, partagez les sites et ressources migrés de façon appropriée.

Etapes après la migration

Une fois que vous avez migré le site, il sera exécuté avec des appels REST de contenu version 1.1. Certains problèmes peuvent en découler. Vous devez les résoudre pour que le site soit exécuté correctement. Voici quelques informations pour vous aider à déterminer les actions à effectuer :

Si vous utilisez ContentSDK, les appels sont automatiquement mis à jour vers des appels REST de contenu version 1.1.
Si les présentations de contenu n'indiquent pas qu'elles prennent en charge la version 1.1, ContentSDK ajoute également l'entrée "data" (version 1.0) dans la réponse qui pointera tout simplement vers l'entrée "fields" (version 1.1). Par conséquent, il se peut que vos modèles continuent de fonctionner sans que vous n'effectuiez aucune modification.
Si vous utilisez la syntaxe REST de contenu version 1.0 "fields.type.equals=" dans la chaîne de requête supplémentaire, nous tentons de l'analyser et de la modifier en une syntaxe version 1.1, mais vous devriez la valider.
Si vous effectuez des appels REST de contenu version 1.0 directs (et non via ContentSDK), ces appels échoueront. Vous devez corriger votre code personnalisé et mettre à niveau ces appels.
De même, toutes les requêtes de contenu personnalisées avec une syntaxe version 1.0 "fields.type.equals=" doivent avoir la syntaxe 'q=(type eq "..")'.
"updateddate" et "updatedDate" : ce problème est censé être corrigé par CaaS, mais tant qu'il n'existe pas de build EC permettant à l'API REST de contenu version 1.1 de prendre en charge les deux valeurs, vous devez modifier les valeurs "updateddate" pour qu'elles correspondent à la valeur camelCase : "updatedDate".

Compatibilité du site migré avec un site multilingue

Une fois que votre site fonctionne correctement, vous devez le rendre compatible avec un site multilingue. Si vous deviez créer un site d'entreprise sur un serveur de calcul externe, il vous faudrait définir une langue par défaut et une stratégie de localisation. Votre site ayant été copié, il n'est pas multilingue. Vous devez donc le mettre à niveau vers un site multilingue pour vous assurer qu'il prend en charge cette future fonctionnalité.

Le tableau ci-après présente les différences entre les sites multilingues et les sites non multilingues.

Objet de site	Site multilingue	Site non multilingue
Eléments de contenu	La variante de langue de l'élément de contenu est affichée, pas l'élément déplacé vers la page. La langue peut être modifiée selon la langue demandée lors de l'affichage du site.	L'élément de contenu déplacé vers la page est toujours affiché.
Présentations de contenu	Les présentations de contenu doivent prendre en charge les API version 1.1. Sinon, un message d'avertissement s'affichera à la place de l'élément de contenu. Cela est dû au fait que tous les appels d'API version 1.1 possèdent un élément "locale" qui a été ajouté et qui n'est pas pris en charge dans l'API version 1.0.	Les présentations de contenu peuvent prendre en charge la version 1.0 ou 1.1. Si la présentation de contenu prend uniquement en charge la version 1.0, ContentSDK ajoute une entrée "data" dans la réponse correspondant à l'entrée "fields". D'autres problèmes peuvent surgir, cette fonctionnalité ne doit donc pas être considérée comme prise en charge et la présentation de contenu doit être mise à niveau.
Listes de contenu	Seuls les éléments de contenu disponibles dans la variante de langue demandée sont affichés.	Tous les éléments, peu importe la langue, sont affichés. L'utilisateur peut attacher les résultats à une langue donnée dans la liste de contenu, de sorte que deux listes de contenu sont affichées sur la page avec les résultats dans différentes langues. Cette option du panneau des paramètres permettant de choisir une langue n'est pas disponible pour les sites multilingues.
defaultLocale	Les sites multilingues possèdent un environnement local de site par défaut. Par conséquent, toutes les requêtes de contenu renvoient uniquement les éléments de contenu de cet environnement local (ou non traduisibles).	Il n'existe aucun environnement local par défaut pour les sites non multilingues, la requête de contenu utilisée renvoie donc tous les éléments de contenu, peu importe la langue.
Stratégie de localisation	Définit la liste des langues disponibles sur le site. Le générateur de site contient une liste déroulante répertoriant ces langues. En outre, l'interface utilisateur de gestion contient une liste déroulante de langues vous permettant d'ouvrir/de prévisualiser le site dans la langue demandée.	Comme il n'existe aucune stratégie de localisation, la liste déroulante permettant de modifier la langue est enlevée du générateur. L'interface utilisateur de gestion ne répertorie aucune langue, ni de langue "par défaut". Cette différence vous permet de reconnaître un site multilingue et un site non multilingue dans l'interface utilisateur de gestion.
Traduction/Traduisible	Le menu contextuel de l'interface utilisateur de gestion dispose d'une option Traduire. Cette option vous permet de créer un travail de traduction pour traduire le site.	Le menu contextuel de l'interface utilisateur de gestion dispose d'une option Traduisible. Un site non multilingue n'est effectivement pas traduisible. Vous devez donc le rendre traduisible (multilingue) pour pouvoir le traduire. C'est également ainsi que vous "mettez à niveau" un site non multilingue vers un site multilingue. Remarque : la mise à niveau est unidirectionnelle. Vous ne pouvez pas revenir à une version non traduisible.

Pour transformer votre site en un site multilingue, vous devez effectuer les actions suivantes :

Mettez à niveau tous les composants de présentation de contenu pour qu'ils puissent prendre en charge les API REST de contenu de version 1.1
Mettez à niveau toutes les "chaînes de requête supplémentaires" dans les listes de contenu du site pour qu'elles soient compatibles avec l'API REST de contenu de version 1.1.

Ensuite, si vous avez du code de composant personnalisé qui effectue des appels REST de contenu, vous devez également le mettre à niveau pour qu'il puisse réaliser des appels version 1.1. Cette situation est peu probable car la plupart des appels de contenu sont effectués à partir des présentations de contenu.

Mise à niveau des présentations de contenu

Spécification des versions d'API REST de contenu prises en charge

Les présentations de contenu doivent indiquer la version d'API REST de contenu qu'elles prennent en charge. Il est ainsi garanti que l'appel REST de contenu approprié est effectué pour renvoyer les données de réponse attendues à la présentation.

Si vous n'indiquez aucune prise en charge de version, le système part du principe que la présentation de contenu prend uniquement en charge la version 1.0.

La console répertorie les présentations de contenu qui sont encore sous la version .0.

Pour permettre à votre présentation de contenu de prendre en charge d'autres versions, ajoutez la propriété "contentVersion" à votre objet de présentation de contenu.

Dans cet exemple, la présentation de contenu prend en charge toutes les versions de 1.0 incluse à 2.0 non incluse (remarque : la version 2.0 n'existe pas, mais des modifications majeures de version peuvent entraîner de nouveaux changements).

// Content Layout
          definition.ContentLayout.prototype = {    // Specify the versions of
          the Content REST API that are supported by the this Content Layout.    // The value for contentVersion follows Semantic Versioning
          syntax.    // This allows applications that use the
          content layout to pass the data through in the expected format.    contentVersion: ">=1.0.0
          <2.0.0",     // Main rendering function:    // - Updates the data to handle any required additional requests and
          support both v1.0 and v1.1 Content REST APIs    // - Expand the Mustache template with the updated data
            // - Appends the expanded template HTML to the
          parentObj DOM element    render: function (parentObj)
          {

Gestion des modifications de réponse version 1.1

Vous devez au minimum gérer la modification de "data" en "fields" dans la réponse d'API REST de contenu. Pour ce faire, le plus simple est d'ajouter de nouveau la propriété "data" et de pointer vers la nouvelle propriété "fields".

render: function (parentObj)
          {    ...    if(!content.data) {        content.data =
          content.fields;    }

Le mieux est de modifier vos présentations de contenu pour qu'elles utilisent la valeur "fields" de la version 1.1. Cette opération implique de mettre à jour le code JavaScript et le code de modèle.

Pour prendre entièrement en charge la version 1.1, vous devez gérer les modifications d'API REST de contenu suivantes entre la version 1.0 et la version 1.1 :

Modification d'API REST de contenu	Version 1.1	Version 1.0
"fields" et "data"	"items": [{ "type": "Starter-Blog-Author", "name": "Alex Read", "id": "COREB62DBAB5CEDA4915A9C9F6050E554F63", "fields": { "starter-blog-author_bio": "Alex's bio", "starter-blog-author_name": "Alex Read" } },	"items": [{ "type": "Starter-Blog-Author", "name": "Alex Read", "id": "COREB62DBAB5CEDA4915A9C9F6050E554F63", "data": { "starter-blog-author_bio": "Alex's bio", "starter-blog-author_name": "Alex Read" } },
Noms de propriété camelCase	"updatedDate"	"updateddate"
Format de requête	/items?q=(type eq "Starter-Blog-Author")	/items?fields.type.equals="Starter-Blog-Author"
Version d'API	/content/management/api/v1.1/items	/content/management/api/v1/items
Requêtes propres à la langue	/content/management/api/v1.1/items?q=((type eq "Promo") and (language eq "en-US" or translatable eq "false"))	Non prises en charge. Vous devez migrer tous les appels version 1 personnalisés pour inclure l'option de langue. Vous vous assurez ainsi que les résultats sont cohérents avec ceux renvoyés pour le site multilingue lorsqu'il est affiché dans une langue donnée.

Mise à niveau de la chaîne de requête de contenu

Si du code personnalisé contient des appels d'API de contenu, vous devez valider tout le code personnalisé de votre site qui effectue des appels d'API REST de contenu.

Composants personnalisés : vérifiez les composants suivants :
- Présentations de contenu
- Composants locaux
- Présentations de section
- Composants distants
Thèmes : JavaScript : bien que cela soit peu probable, il se peut que votre thème contienne du code JavaScript qui effectue des appels d'API REST de contenu. Ce code doit également être validé.
Propriétés de site : chaîne de requête supplémentaire : une fois que vous avez validé la mise à niveau de tout votre code personnalisé effectuant des appels d'API REST de contenu, vous devez également mettre à niveau les composants de chaîne de requête supplémentaire et de liste de contenu sur toutes les pages du site. Nous tentons de les analyser et de les convertir lors de l'exécution, mais vous devez les mettre à niveau pour qu'ils soient compatibles avec les appels REST de contenu version 1.1 afin de garantir une prise en charge continue.

Conversion d'un site non multilingue en un site multilingue

Une fois que vous avez converti votre site pour qu'il prenne entièrement en charge les API REST de contenu version 1.1, vous pouvez ajouter la prise en charge des langues en transformant le site en un site multilingue.

Si vous sélectionnez votre site dans l'interface utilisateur de gestion de site, l'option de menu de contenu Traduisible apparaît. Si vous sélectionnez cette option, une boîte de dialogue apparaît et vous invite à choisir une stratégie de localisation et une langue par défaut pour le site dans la liste des langues requises de la stratégie de localisation. Si aucune stratégie de localisation n'existe, vous ne pourrez pas accomplir cette étape. Vous devez d'abord accéder aux écrans d'administration de contenu et créer une stratégie de localisation contenant au moins une langue requise.

Une fois cette étape terminée, votre site affiche le contenu dans l'environnement local par défaut. Il est également possible de passer à d'autres environnements locaux indiqués dans la stratégie de localisation.

Vous devez vérifier que votre site affiche le contenu comme prévu dans l'environnement local par défaut.

Migration de vos ressources

Les ressources associées aux sites sont migrées en même temps que les sites, mais les ressources non associées doivent être migrées séparément.

Pour effectuer la migration, tenez compte des points suivants :

Seules les ressources associées à une collection peuvent être migrées. Si vous souhaitez migrer des ressources qui ne sont pas associées à une collection, vous devez d'abord les ajouter à une collection.
Les instances non mesurées ne prennent pas en charge les langues sur les ressources. Par conséquent, lorsque vous migrez vos ressources, la langue par défaut sera héritée de la langue par défaut du référentiel. Vérifiez que la langue par défaut du référentiel est définie sur la langue par défaut souhaitée avant de migrer les ressources.
Seuls les éléments publiés sont migrés. Après la migration, s'il vous manque des éléments, vérifiez que ces éléments ont été publiés dans l'instance source.
Si des éléments publiés comportent des versions brouillon, celles-ci sont publiées sur l'instance cible. Les versions initialement publiées à partir de l'instance source sont perdues.
Dans la version non mesurée d'Oracle Content Management, en cas de visualisation d'un élément de contenu, les utilisateurs pouvaient choisir la vue Présentation de contenu ou Contenu. Dans la version actuelle d'Oracle Content Management, la vue Contenu a été remplacée par Vue de formulaire de contenu et la vue Présentation de contenu a été enlevée.

Pour migrer vos ressources, procédez comme suit :

Si ce n'est pas déjà fait, installez OCE Toolkit.
Inscrivez les serveurs source et cible.
Migrez une collection de ressources.

Inscription des serveurs source et cible

Inscrivez les détails de connexion des serveurs source et cible.

Inscrivez le serveur source (le serveur à partir duquel vous migrez les ressources) :

> cec register-server <source_server_name>
          -e http://<source_server>:<source_port>
          -u <source_username> -p <source_password>
          -t pod_ic

<source_server_name> permet d'identifier l'adresse source. Vous pouvez choisir n'importe quel nom.
<source_server> et <source_port> constituent l'URL utilisée pour accéder au serveur source.
<source_username> et <source_password> sont le nom utilisateur et le mot de passe de la personne qui peut accéder aux ressources du serveur source.
La valeur "pod_ic" correspond au type du serveur source. Elle identifie le type de serveur sur lequel l'instance est créée.

Inscrivez le serveur cible (le serveur vers lequel vous migrez les ressources) :

> cec-install % cec register-server <target_server_name>
          -e http://<source_server>:<source_port>
          -u <target_username> -p <target_password>
          -t pod_ec

<target_server_name> permet d'identifier l'adresse cible. Vous pouvez choisir n'importe quel nom.
<target_server> et <target_port> constituent l'URL utilisée pour accéder au serveur cible.
<target_username> et <target_password> sont le nom utilisateur et le mot de passe de la personne qui sera propriétaire des ressources sur le serveur cible.
La valeur "pod_ec" correspond au type du serveur cible. Elle identifie le type de serveur sur lequel l'instance est créée.

Migration d'une collection de ressources

Pour migrer une collection de ressources, exécutez la commande suivante :

> cec migrate-content <source_collection_name> --server  <source_server_name>
      --destination <target_server_name> --repository <target_repository_name> --collection  <target_collection_name> --channel
    <target_channel_name>

Cette commande crée les ressources sur le serveur cible dans le référentiel indiqué, et les associe à la collection et au canal. Le cas échéant, la collection et le canal sont créés automatiquement. La langue par défaut de toutes les ressources migrées est la langue par défaut définie dans le référentiel indiqué.

Communication de la modification aux utilisateurs

Communiquez la nouvelle URL de service aux utilisateurs. Les utilisateurs de bureau et mobiles doivent configurer leurs appareils avec un nouveau compte et synchroniser de nouveau l'intégralité du contenu.