Migración de una instancia de Oracle Content Management desde una instancia de Cloud Infrastructure heredada

Si tiene instancias de Oracle Content Management que se ejecuten en una infraestructura de Cloud Infrastructure heredada con una suscripción no medida, Oracle le recomienda migrar estas instancias al nuevo entorno de Oracle Cloud Infrastructure (OCI) nativo, OCI Gen 2 (es decir, utilizando la consola de Infrastructure para gestionar las instancias de servicio). Esto le garantizará el poder disfrutar de las ventajas y avances de la plataforma de Oracle en la nube en el futuro.

Para iniciar la migración, deberá realizar algunos pasos previos a la migración y trabajar con los Servicios de soporte Oracle para programarla.

Migre su suscripción a una suscripción de créditos universales. Póngase en contacto con su representante de ventas de Oracle para que le ayude.
Crear una nueva instancia de Oracle Content Management en OCI con la consola de Infrastructure. Se trata de la instancia de destino a la que se migrarán sus datos. NO utilice esta instancia hasta que haya terminado la migración.
Cuentas de Migre los usuarios desde cuentas en la nube tradicionales a Oracle Identity Cloud Service (IDCS). Asegúrese de mantener los nombres de usuario para que los roles y los permisos puedan asignarse correctamente como parte del proceso de migración. En el archivo CSV exportado, la entrada de nombre de usuario se denomina "Conexión de usuario". Los roles de usuario se asignarán de acuerdo con la asignación de usuario.
Prepárese para la migración mediante la recopilación de información que necesitará para su solicitud de servicio, así como mediante la creación de una lista de cualquier integración que tenga para los pasos que realizará tras la migración.
Envíe una solicitud de servicio de migración y confirma la fecha y hora de la migración.
Comprobar el progreso de la migración. La solicitud de servicio se actualizará conforme la migración avance y, cuando esté lista, se le pedirá que verifique que el funcionamiento de la instancia nueva es el previsto.
Finalice la migración mediante la realización de los pasos necesarios para migrar cualquier integración que tenga su instancia con otros servicios o aplicaciones.
Migre los sitios que incluyan activos y hágalos compatibles con varios idiomas.
Migre los activos que se hayan excluido de la migración.
Comunique el cambio a los usuarios.

Asignación de usuarios

En la siguiente tabla se describe la asignación de grupos de permisos de Oracle Content Management a roles de aplicación de OCI.

Grupo de permisos de Oracle Content Management	Rol de aplicación de OCI
DocumentsServiceUser	CECStandardUser
DocumentsServiceAdmin	CECServiceAdministrator
SitesServiceVisitor	CECSitesVisitor
SitesServiceAdmin	CECSitesAdministrator
ContentAdministratorRole	CECContentAdministrator
CECSStandardUser	CECStandardUser
CECSEnterpriseUser	CECEnterpriseUser

Nota:

Si el dominio de IDCS de destino ya contiene un usuario con el mismo nombre de usuario, se asignarán al usuario los roles de aplicación de OCI correspondientes a los grupos de permisos de Oracle Content Management del usuario.

Preparación para la migración

Anote la URL de la instancia nueva (la de destino) creada, para incluirla en la solicitud de migración.
Anote la URL de la instancia antigua (la de origen), para incluirla en la solicitud de migración.
Realice un inventario de todas las integraciones que tenga su instancia antigua con otros servicios o aplicaciones, ya sea directamente o mediante la API de REST. Si existe alguna de estas integraciones, tendrá que realizar algunas acciones tras la migración.

Envíe una solicitud de servicio de migración

Cuando esté lista para la migración, debe enviar una solicitud de servicio para que se inicie el proceso:

Inicie sesión en Soporte de Oracle Cloud.
Cree una nueva solicitud de servicio.
En Tipo de problema, seleccione Migración de instancia de servicio y, a continuación, De suscripción no medida a OCI-Gen2.
Proporcione la información siguiente en su solicitud de servicio:
- La URL de la instancia de origen (la instancia de la que está realizando la migración)
- La URL de la instancia de destino (la instancia a la que está realizando la migración)
- Si utiliza Akamai proporcionado por Oracle, menciónelo para que podamos coordinar una hora para actualizar las URL en la configuración de Akamai después de la migración
Proporcione la fecha en la que preferiría que se iniciara la migración.
Envíe la solicitud de servicio.
Una vez que los Servicios de Soporte Oracle reciban la solicitud de servicio de migración, programaremos su migración en función de la fecha de la solicitud, y la solicitud de servicio se actualizará con la fecha y la hora de inicio de la migración.
Confirme en la solicitud de servicio que aprueba la fecha y hora de inicio de la migración.

Se realizarán actualizaciones en la solicitud de servicio para mostrar el avance de la migración. La migración de datos se realizará en el backend; no es necesario que realice ninguna acción más allá de mantener actualizadas las solicitudes de servicio, así como validar la migración una vez finalizada.

Proceso de migración

Aquí se detalla lo que sucede durante la migración:

Los Servicios de Soporte Oracle actualizan la solicitud de servicio cuando empieza la migración.

Importante:
En este momento, no debe realizar ningún cambio en la instancia antigua (de origen). Cualquier cambio realizado tras el inicio de la migración no se migrará a la instancia nueva.
El contenido y los datos de configuración se exportan de la instancia antigua (la de origen), y se importan en la instancia nueva (la de destino).
Cuando la migración ha terminado, los Servicios de Soporte Oracle actualizan la solicitud de servicio, y se le pedirá que valide la nueva instancia para asegurarse de que todo funciona como se esperaba.
Si surge algún problema, anótelos en la solicitud de servicio. Los Servicios de Soporte Oracle trabajarán para solucionar los problemas, y le indicará en la solicitud de servicio el momento en el que la instancia esté lista para validarse.
Cuando todo funcione como se espera, anote en la solicitud de servicio que acepta la instancia migrada.

Nota:

La instancia antigua seguirá estando activa para que pueda volver a hacer referencia a ella para la validación. También la necesitará para migrar todos los sitios que utilizan activos y para migrar cualquier otro activo que se hubiera excluido durante la migración.

Finalización de la migración

Si la instancia antigua se ha integrado o comunicado con otros servicios o aplicaciones, directamente o través de las llamadas de API de REST, puede que tenga que realizar tareas posteriores a la migración.

Los siguientes elementos se aplican en todo el servicio:

Revise los roles de aplicación de OCI y asigne roles que no existían en la instancia de origen, como el rol de aplicación CECRepositoryAdministrator.
Vuelva a configurar las credenciales de usuario para todas las integraciones que las utilicen. No se migran las credenciales.
El patrón de URL de Oracle Content Management es distinto, por lo que tendrá que actualizar las URL de las integraciones que las usan.
Las URL antiguas usaban el siguiente patrón:

https://<nombre-servicio>-<nombre-cuenta>.<región>.oraclecloud.com/documents

Las URL nuevas usan el siguiente patrón:

https://<nombre-servicio>-<nombre-cuenta>.<tipo-servicio>.ocp.oraclecloud.com/documents
Vuelva a configurar los valores de CORS y contenido embebido. No se migra la configuración del servicio de destino.
Se migrarán los sitios estándar, pero no los de empresa. Migre manualmente los sitios de empresa y todos los activos digitales y elementos de contenido que están asociados a los sitios mediante la creación de una plantilla para cada sitio de empresa, la exportación de la plantilla desde la instancia de origen y su importación en la instancia de destino.
Elimine o actualice todos los controladores personalizados que se utilizan en los sitios migrados.

Integración	Acciones que realizar tras la migración
Oracle Integration	Vuelva a configurar las credenciales. Actualice las URL de Oracle Content Management de Oracle Integration Cloud.
Oracle Commerce Cloud	Vuelva a configurar las credenciales. Actualice las URL de Oracle Content Management de Oracle Commerce Cloud.
Oracle Process Cloud Service	Vuelva a configurar las credenciales.
Oracle Eloqua Cloud Service	Vuelva a configurar las credenciales.
Oracle Intelligent Advisor	Vuelva a configurar las credenciales.
Oracle Cobrowse Cloud Service	Vuelva a configurar las credenciales.
Responsys	Vuelva a configurar las credenciales.
Visual Builder Cloud Service (VBCS)	Vuelva a configurar las credenciales. Actualice las URL de Oracle Content Management de los componentes de VBCS.
CDN/Akamai	Si utiliza Akamai suministrado por Oracle, coordine una hora con los Servicios de Soporte Oracle para actualizar las URL de Oracle Content Management de la configuración de Akamai. En caso contrario, debe actualizar las URL en su configuración de CDN.
Llamadas de la API de REST	Actualice las URL de Oracle Content Management de cualquier llamada de API de REST.
Uso de SDK/CLI de cliente	Si la URL se mantiene/almacena en caché de forma local en el cliente, actualice las URL de Oracle Content Management de la configuración.
Conectores	Vuelva a configurar las credenciales.

Nota:

No funcionará ningún marcador de contenido de la instancia antigua porque la URL de la instancia nueva ha cambiado.

Migración de sitios que incluyen activos

Los sitios que no incluyen activos se migrarán automáticamente, pero los sitios que sí incluyen activos requieren algunos pasos adicionales para hacer que funcionen en su nueva instancia de Oracle Content Management.

Instalación de OCE Toolkit

El comando "cec migrate-site" es nuevo, por lo que deberá instalar OCE Toolkit desde el repositorio de Git del cliente web incluso si ya lo ha descargado e instalado anteriormente.

Siga las instrucciones de la página de Sites Toolkit para descargar e instalar OCE Toolkit.

Registro del servidor de destino

Registre los detalles de conexión para el servidor de destino (el servidor al que va a migrar los sitios):

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

El <nombre_servidor_destino> se usa para identificar el punto final de destino y puede ser cualquier nombre que elija.
El <servidor_destino> y el <puerto_destino> forman la URL que se usa para acceder al servidor de destino.
El <nombre_usuario_destino> y la <contraseña_destino> deben ser el nombre de usuario y la contraseña de la persona que exportará las plantillas del sitio desde los servidores de origen para que no haya problemas de permiso cuando se importen las plantillas durante la migración.
El valor "pod_ec" es el tipo de servidor de destino, que se usa para identificar el tipo de servidor en que se basa la instancia.

Migración de sitios

Para migrar sus sitios, realice los siguientes pasos:

En el servidor de origen, cree plantillas de cada sitio que incluya los activos.
En el servidor de origen, exporte cada plantilla. Asegúrese de realizar este paso como el usuario al que ha hecho referencia al registrar el servidor de destino.
En el servidor de destino, inicie sesión como administrador de repositorios (usuario con rol CECRepositoryAdministrator). A continuación, debe crear un repositorio para los activos que se importarán con la plantilla.
Para cada plantilla de descarga, ejecute el siguiente comando, sustituyendo <site_name> por el nombre que desee que tenga el sitio en el servidor de destino:
```
> cec migrate-site <site_name> --template <template_path_and_name> 
--destination <registered_target_server_name> --repository <repository_name>
```
En el servidor de destino, comparta los sitios y los activos migrados de forma adecuada.

Pasos posteriores a la migración

Una vez que haya migrado el sitio, este se ejecutará utilizando llamadas de REST de contenido v1.1. Esto puede causar algunos problemas que deben resolverse para que el sitio se ejecute correctamente. Revise los siguientes puntos para determinar qué debe hacer:

Si está utilizando ContentSDK, sus llamadas se actualizarán automáticamente para usar las llamadas de REST de contenido v1.1.
Si los diseños de contenido no indican que soportan v1.1, ContentSDK también se agregará en la entrada "data" (v1.0) de la respuesta, que simplemente apuntará a la entrada "fields" (v1.1) para que las plantillas puedan seguir trabajando sin cambios.
Si está utilizando la sintaxis de REST de contenido v1.0 "fields.type.equals=" en la cadena de consulta adicional, intentamos analizarla y modificarla para que sea una sintaxis v1.1, pero deberá validarla.
Si realiza llamadas directas de REST de contenido v1.0 (en lugar de a través del ContentSDK), estas fallarán. Debe corregir el código personalizado y cambiar la versión de estas llamadas.
De igual modo, debe hacer que todas las consultas de contenido personalizadas que forman la sintaxis v1.0 "fields.type.equals=" pasen a ser la sintaxis 'q=(type eq "..")'.
"updateddate" vs. "updatedDate": supuestamente lo corrige CaaS, pero hasta que obtengamos un compilación de EC en la que la API de REST de contenido v1.1 soporte ambos valores, deberá cambiar cualquier valor "updateddate" para que sea el valor "updatedDate" de camelCase.

Conversión del sitio migrado en un sitio compatible con sitios multilingües (MLS)

Una vez que el sitio se está ejecutando correctamente, debe hacer que sea compatible con MLS. Si se disponía a crear un sitio de empresa en un servidor de cálculo externo, este precisaría un idioma y una política de localización por defecto. Debido a que el sitio se ha copiado, este es un sitio distinto de MLS, por lo que debe cambiar la versión a un sitio MLS para garantizar que podrá soportar una funcionalidad posterior.

En la siguiente tabla se muestran las diferencias entre sitios MLS y distintos de MLS.

Objeto de sitio	Sitio MLS	Sitio distinto de MLS
Elementos de contenido	Se mostrará la variante de idioma del elemento de contenido, en lugar del elemento de contenido soltado en la página. El idioma puede cambiar en función del idioma solicitado cuando se representa el sitio.	El elemento de contenido soltado en la página se mostrará siempre.
Diseños de contenido	Los diseños de contenido deben soportar las API versión 1.1. De lo contrario, no aparecerá el elemento de contenido y se mostrará una advertencia en su lugar. Esto se debe a que todas las llamadas a la API versión 1.1 tendrán una "locale" agregada que no está soportada en la API versión1.0.	Los diseños de contenido pueden ser de la versión 1.0 o 1.1. Si el diseño de contenido solo soporta la versión 1.0, el ContentSDK agregará una entrada "data" en la respuesta para coincidir con la entrada "fields". Pueden presentarse otros problemas, por lo que no debe considerarse una "función soportada" por no cambiar la versión del diseño de contenido.
Listas de contenido	Solo se mostrarán los elementos de contenido disponibles en la variante de idioma solicitada.	Se mostrarán todos los elementos de contenido independientemente del idioma. En la lista de contenido, el usuario tiene la posibilidad de adjuntar los resultados a un idioma específico para que pueda disponer de dos listas de contenido en la página que muestren los resultados en dos idiomas. Esta opción del panel de configuración para elegir un idioma no está disponible para los sitios MLS.
defaultLocale	Los sitios MLS tienen una configuración regional del sitio por defecto. Esto significa que todas las consultas de contenido solo devolverán los elementos de contenido que están en dicha configuración regional (o que no son traducibles).	No hay ninguna configuración regional por defecto en un sitio distinto de MLS, por lo que la consulta de contenido utilizada devuelve todos los elementos de contenido independientemente del idioma.
Política de localización	Define la lista de idiomas disponibles para el sitio. Estos se incluirán en una lista desplegable en el creador. También en la interfaz de usuario de gestión se incluirá una lista desplegable de idiomas para que pueda abrir u obtener una vista previa del idioma solicitado.	Debido a que no hay ninguna política de localización, se eliminará la lista desplegable para cambiar de idioma del creador. En la interfaz de usuario de gestión, no hay ninguna lista de idiomas ni ningún idioma "por defecto". Así es como puede reconocer los sitios distintos de MLS y los sitios MLS en la interfaz de usuario de gestión.
Traducción/traducible	El menú contextual de la interfaz de usuario de gestión contiene "Traducir" como una opción. Esta le permite crear un trabajo de traducción para traducir el sitio.	El menú contextual de la interfaz de usuario de gestión tendrá una opción "Traducible". De forma eficaz, un sitio distinto de MLS no es traducible, por lo tanto debe convertirlo primero en traducible (MLS) para poder traducirlo. Así es como se "cambia la versión" de un sitio de no MLS a MLS. Nota: Esta acción solo se puede realizar en un sentido. No se puede cambiar la versión a no traducible.

Para poder convertir el sitio en un sitio MLS, debe realizar lo siguiente:

Cambie la versión de todos los componentes del diseño de contenido para que soporten las API de REST de contenido versión 1.1
Cambie la versión de "todas las cadenas de consulta adicionales" en las listas de contenido del sitio para que sean compatibles con la API de REST de contenido versión 1.1

A continuación, si tiene algún código de componente personalizado que realiza llamadas de REST de contenido, también debe cambiar su versión para que realice llamadas de la versión 1.1. Esto no es común ya que la mayoría de las llamadas de contenido se realizan desde diseños de contenido.

Cambio de versión de diseños de contenido

Especificación de las versiones de la API de REST de contenido soportadas

Los diseños de contenido deben especificar qué versión de la API de REST de contenido soportan. Esto es para garantizar que se realiza la llamada de REST de contenido adecuada para devolver los datos de respuesta esperados en el diseño.

Si no especifica ningún soporte de versión se asume que el diseño de contenido solo soporta v1.0.

La consola mostrará los diseños de contenido que aún están en v1.0.

Para permitir que el diseño de contenido soporte otras versiones, agregue la propiedad "contentVersion" al objeto de diseño de contenido.

En este ejemplo, se indica que soporta otras versiones entre v1.0 y la anterior a la 2.0 (Nota: la 2.0 no existe, pero un cambio de versión importante puede introducir cambios que pueden causar fallos)

// 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)
          {

Gestión de cambios de respuesta en v1.1

Lo mínimo que tiene que hacer es gestionar el cambio de respuesta de API de REST de contenido de "data" a "fields". La manera más simple de hacerlo es volver a agregar la propiedad "data" y apuntar a la nueva propiedad "fields"

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

Una opción mejor es cambiar el uso del valor "fields" de la v1.1 en todos los diseños de contenido. Esto implicará actualizar el código de plantilla y JavaScript.

Para soportar totalmente la v1.1, debe gestionar los siguientes cambios en la API de REST de contenido entre la v1.0 y la v1.1:

Cambio de la API de REST de contenido	v1.1	v1.0
"fields" vs. "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" } },
nombres de la propiedad camelCase	"updatedDate"	"updateddate"
formato de consulta	/items?q=(type eq "Starter-Blog-Author")	/items?fields.type.equals="Starter-Blog-Author"
Versión de API	/content/management/api/v1.1/items	/content/management/api/v1/items
consultas específicas del idioma	/content/management/api/v1.1/items?q=((type eq "Promo") y (language eq "en-US" or translatable eq "false"))	No soportado. Debe migrar todas las llamadas personalizadas v1 para incluir la opción "language". Esto garantiza que los resultados sean consistentes con los que se devuelven para el sitio MLS cuando se visualizan en un idioma específico.

Cambio de versión de la cadena de consulta de contenido

Es posible que esté realizando llamadas a la API de contenido en un código personalizado, por lo que debe validar todo el código personalizado utilizado por el sitio que esté realizando llamadas a la API de REST de contenido.

Componentes personalizados: compruebe los siguientes componentes:
- Diseños de contenido
- Componentes locales
- Diseños de sección
- Componentes remotos
Temas: JavaScript: aunque es menos probable, puede que tenga JavaScript en el tema que esté realizando llamadas a la API de REST de contenido, por lo que también debe validarse.
Propiedades del sitio: Cadena de consulta adicional: una vez que haya validado que ha cambiado la versión de todo el código personalizado que realiza llamadas a la API de REST de contenido, deberá cambiar también la versión de "Cadena de consulta adicional" en todos los componentes "Lista de contenido" de todas las páginas del sitio. Mientras intentamos analizarlos y convertirlos en tiempo de ejecución, se debe cambiar su versión para que sean compatibles con las llamadas de REST de contenido v1.1 para un soporte continuado.

Conversión de un sitio distinto de MLS a MLS

Una vez que haya convertido el sitio para soportar totalmente las API de REST de contenido v1.1, puede agregar soporte para idiomas cambiándolo a un sitio MLS.

Si selecciona el sitio en la interfaz de usuario de gestión del sitio, se mostrará una opción de menú de contenido "translatable". La selección de esta opción abrirá un cuadro de diálogo que solicita que se seleccione la política de localización y un idioma por defecto para el sitio en la lista de idiomas necesarios de la política de localización. Si no hay ninguna política de localización, no podrá completar este paso y tendrá que ir primero a las pantallas de administración de contenido para crear una política de localización con al menos un idioma necesario.

Después de completar este paso, el sitio se representará en la configuración regional por defecto. También le permitirá cambiar a otras configuraciones regionales especificadas en la política de localización.

Debe validar que el sitio se representa como se esperaba en la configuración regional por defecto.

Migración de activos

Los activos que están asociados a los sitios se migrarán cuando migre sus sitios, pero los activos que no están asociados a los sitios deben migrarse por separado.

Antes de iniciar la migración, tenga en cuenta los siguientes puntos:

Solo se pueden migrar los activos asociados a una recopilación. Si desea migrar activos que no estén asociados a una recopilación, debe agregarlos a una recopilación para poder migrarlos.
Las instancias no medidas no soportan idiomas en los activos, por lo que cuando migre los activos, el idioma por defecto se heredará del idioma por defecto del repositorio. Asegúrese de que el idioma por defecto del repositorio esté definido en el idioma por defecto deseado antes de migrar los archivos.
Solo se migrarán los elementos publicados. Si, después de la migración, faltan elementos, confirme que estos se han publicado en la instancia de origen.
Si alguno de los elementos publicados tiene versiones de borrador, estas se convertirán en las versiones publicadas en la instancia de destino. Las versiones publicadas originales de la instancia de origen se perderán.
En la versión no medida de Oracle Content Management, al visualizar un elemento de contenido, los usuarios pueden seleccionar la vista "Diseño de contenido" o la vista "Contenido". La vista "Contenido" se ha sustituido por Vista de pantalla de contenido en la versión actual de Oracle Content Management y se la eliminado la vista "Diseño de contenido".

Para migrar sus activos, realice los siguientes pasos:

Si aún no lo ha hecho, instale OCE Toolkit.
Registre los servidores de origen y destino.
Migre una recopilación de activos.

Registro de servidores de origen y destino

Registre los detalles de conexión de los servidores de origen y destino.

Registre el servidor de origen (el servidor desde el que va a migrar los activos):

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

El <nombre_servidor_origen> se usa para identificar el punto final de origen y puede ser cualquier nombre que elija.
El <servidor_origen> y el <puerto_origen> forman la URL que se usa para acceder al servidor de origen.
El <nombre_usuario_origen> y la <contraseña_origen> deben ser el nombre de usuario y la contraseña de la persona que pueda acceder a los activos del servidor de origen.
El valor "pod_ic" es el tipo de servidor de origen, que se usa para identificar el tipo de servidor en que se basa la instancia.

Registre el servidor de destino (el servidor al que va a migrar los activos):

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

El <nombre_servidor_destino> se usa para identificar el punto final de destino y puede ser cualquier nombre que elija.
El <servidor_destino> y el <puerto_destino> forman la URL que se usa para acceder al servidor de destino.
El <nombre_usuario_destino> y la <contraseña_destino> deben ser el nombre de usuario y la contraseña de la persona que será la propietaria de los activos en el servidor de destino.
El valor "pod_ec" es el tipo de servidor de destino, que se usa para identificar el tipo de servidor en que se basa la instancia.

Migración de una recopilación de activos

Migre una recopilación de activos ejecutando el siguiente comando:

> 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>

Los activos se crearán en el servidor de destino en el repositorio especificado y se asociarán a la recopilación y al canal. Si es necesario, la recopilación y el canal se crearán automáticamente. El idioma por defecto de todos los activos migrados será el idioma por defecto que se defina en el repositorio especificado.

Comunicación del cambio a los usuarios

Comunique la nueva URL de servicio a los usuarios. Los usuarios de escritorio y móviles deben configurar sus dispositivos con una nueva cuenta y volver a sincronizar todo el contenido.