Escenario ilustrativo: Imaginemos una empresa de diseño ficticia de 32 personas, Cedar Studio, que utiliza ownCloud Classic 10 con un directorio LDAP, áreas de archivos personales, recursos compartidos de grupo, enlaces públicos y un punto de montaje externo para el almacenamiento de proyectos. La empresa desea migrar a ownCloud Infinite Scale (oCIS) sin dar por sentado que la instalación de un nuevo servidor conservará sus datos y permisos. Este ejemplo es hipotético; no se trata de un informe de una migración completada.
La ruta compatible documentada por ownCloud consiste en una migración guiada mediante la migrate-to-ocisaplicación en el servidor Classic y occcomandos. Se trata de una transferencia por etapas a un destino oCIS independiente y limpio, no de una actualización in situ de la base de datos o el directorio de datos de Classic. El manual de migración indica que el origen permanece operativo durante la mayor parte del proceso, pero no describe la sincronización continua ni una actualización final sin interrupciones. Planifique una transición controlada y confirme la compatibilidad de la versión del origen y el procedimiento final de bloqueo de escritura con el soporte de ownCloud antes de su uso en producción.
Los pasos que se describen a continuación siguen la guía oficial de migración de ownCloud Server 11.0 y la documentación de autenticación y copia de seguridad de Infinite Scale 8.2, disponibles a partir del 6 de octubre de 2026. La sintaxis de los comandos, las variables de entorno y los acuerdos de soporte pueden cambiar; consúltelos con la documentación de las versiones instaladas.
Para Cedar Studio, la primera tarea consiste en listar usuarios, grupos, cuentas habilitadas y deshabilitadas, carpetas compartidas, recursos compartidos vinculados, montajes externos y cualquier usuario local que no exista en LDAP. Registre qué equipos dependen de cada elemento. Esto evita interpretar una transferencia exitosa de archivos personales como prueba de que todos los flujos de trabajo anteriores se han migrado.
Según la guía de migración, esta puede transferir usuarios y grupos habilitados con sus membresías, los archivos del directorio personal de cada usuario habilitado y los recursos compartidos de usuarios, grupos y enlaces. Los archivos se colocan en el espacio personal de cada usuario en oCIS. Los usuarios deshabilitados y sus archivos se omiten. El proceso no migra contraseñas ni montajes externos. Los bytes que residen en montajes externos y recursos compartidos recibidos se excluyen de la transferencia de archivos personales y deben gestionarse por separado. Inventarie esas ubicaciones y asigne un responsable de migración manual.
| Artículo clásico | Comportamiento migratorio documentado | Plan para el estudio Cedar |
|---|---|---|
| Usuarios y grupos habilitados | Transferido o mapeado, según el sistema de gestión de identidades. | Confirme que todas las cuentas y membresías esperadas sean visibles en oCIS. |
| Archivos en los directorios personales de los usuarios | Transferido al espacio personal de cada usuario. | Compare las carpetas y archivos representativos después de la transferencia. |
| Compartir usuarios, grupos y enlaces | Los registros compartidos se migran, sujetos a la falta de usuarios, grupos o políticas de contraseñas de enlace. | Vuelva a probar el acceso con las cuentas del propietario y del destinatario. |
| Contraseñas y cuentas deshabilitadas | Las contraseñas no se transfieren; los usuarios deshabilitados se omiten. | Prepare la incorporación de cuentas y revise qué cuentas deshabilitadas deben habilitarse antes de la migración. |
| Montajes externos y datos compartidos recibidos | Los datos de montaje externo quedan excluidos de la transferencia de archivos. | Recree los puntos de montaje o copie los datos de origen por separado y, a continuación, pruebe el acceso. |
Registre también si se utilizan enlaces públicos sin contraseña. Por defecto, oCIS requiere una contraseña para los enlaces públicos; estos enlaces clásicos podrían no migrarse a menos que se modifique la política de destino. No debilite dicha política solo para conservar las URL antiguas. Decida si los propietarios de los enlaces deberían crear nuevos enlaces protegidos con contraseña. Las contraseñas de los enlaces migrados protegidos con contraseña no coincidirán con las antiguas, por lo que los usuarios deberán restablecerlas después de la migración.
Cree y pruebe una instancia de oCIS independiente antes de transferir los datos de producción. La guía de migración exige que ambos sistemas estén en funcionamiento y sean accesibles entre sí. También advierte que el destino debe estar limpio y sin cambios: los usuarios o datos preexistentes pueden entrar en conflicto con el contenido importado. Realice una copia de seguridad de la instancia Classic actual y prepare un plan de reversión que la mantenga disponible hasta que los usuarios acepten el nuevo servicio.
La migración requiere la instalación de una aplicación proporcionada por ownCloud en el servidor Classic. Esta aplicación se incluye en una migración guiada; la documentación indica a los administradores que se pongan en contacto con el soporte de ownCloud para obtenerla. La aplicación incluye su propio binario rclone. No utilice un paquete de Marketplace ni una copia de archivos no relacionada como sustitutos del proceso documentado de esta aplicación.
En oCIS, habilite el auth-appservicio y la configuración de autenticación de la aplicación. La guía de migración también requiere que la suplantación de identidad esté activa y que se cree un token de aplicación para el administrador de oCIS. La documentación de la aplicación de autenticación de Infinite Scale 8.2 indica explícitamente que la suplantación de identidad está destinada a la migración y no debe permanecer habilitada en un entorno de producción. Trátela como una configuración de migración temporal: proteja el token, limite quién puede acceder a él y desactive la suplantación de identidad exclusiva para la migración una vez finalizado el proceso. En un entorno distribuido, aplique la configuración al servicio correcto según lo especificado en la documentación.
Para el hipotético Cedar Studio, el destino oCIS debe probarse con el mismo servicio LDAP que utiliza el servidor Classic. Guarde las credenciales en el mecanismo de seguridad de la implementación en lugar de pegar las contraseñas de enlace en el historial de la consola o en un runbook compartido. La guía oficial de migración de ownCloud enumera los requisitos del destino e indica la compatibilidad de ownCloud con la aplicación de migración. La guía de la aplicación de autenticación de oCIS 8.2 explica los tokens de la aplicación y la suplantación de identidad.
oCIS debe poder resolver los usuarios y grupos antes de migrar sus archivos y recursos compartidos. Cedar Studio ya utiliza LDAP, por lo que su administrador conectaría oCIS al mismo directorio, verificaría que los usuarios puedan iniciar sesión y comprobaría que los identificadores se corresponden con las cuentas previstas. La guía de ownCloud especifica direcciones de correo electrónico únicas y válidas para cada usuario de Classic habilitado. Para los usuarios de Classic con respaldo LDAP, también especifica el atributo de nombre de usuario, normalmente uido samAccountName, y la configuración correspondiente del esquema LDAP de oCIS. Asegúrese de que los atributos coincidan con el directorio real; no copie valores de ejemplo sin más.
Si Classic utiliza cuentas locales pero oCIS utiliza un directorio LDAP externo, cree o migre los usuarios y grupos correspondientes a dicho directorio antes de la transferencia de archivos. Los nombres de usuario y grupo deben coincidir. El IDM interno de oCIS es un directorio integrado limitado, diseñado para configuraciones pequeñas o pruebas; ownCloud recomienda un sistema de gestión de identidades LDAP o externo para entornos de producción. El procedimiento de migración oficial no admite una población mixta de usuarios Classic locales y con respaldo LDAP en una misma rama de migración. Resuelva esta arquitectura con el apoyo del soporte técnico en lugar de improvisar a mitad del proceso.
Una vez instalada y habilitada la aplicación de migración en Classic, adapte la ruta y la cuenta de servicio documentadas a su instalación. La guía utiliza /var/www/owncloudlos www-datasiguientes ejemplos:
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:verifyEl comando de verificación comprueba que los usuarios habilitados tengan direcciones de correo electrónico válidas y no duplicadas. Solucione los problemas reportados antes de continuar, en lugar de omitir la verificación. Si un usuario deshabilitado necesita migrar, revise la cuenta, habilítela en Classic antes de la verificación e inclúyala en el plan de migración. Cedar Studio también debe verificar el inicio de sesión LDAP en oCIS con varios usuarios representativos antes de que comience la transferencia de datos.
Siga la rama de la guía oficial que coincida con su configuración de identidad. Si los usuarios clásicos son locales y usarán el IDM integrado de oCIS, la secuencia de la guía incluye la migración de usuarios, la asignación de un rol en oCIS y la migración de grupos. Se asigna un rol a los usuarios migrados; los roles clásicos no se conservan tal cual, y los privilegios de subadministrador clásicos no tienen un rol equivalente en oCIS. Revise el acceso de administrador manualmente. Si ambos sistemas usan el mismo directorio LDAP, asegúrese de que los usuarios y grupos ya estén disponibles para oCIS y siga la rama de LDAP en lugar de crear duplicados.
Una vez que los usuarios, grupos y roles estén listos, los comandos documentados para archivos y recursos compartidos utilizan el nombre de usuario del administrador de oCIS como argumento final. La contraseña del administrador clásico se solicita de forma interactiva:
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 adminEjecute la transferencia de archivos antes de la transferencia de recursos compartidos, tal como se describe en el procedimiento de migración. Los usuarios que nunca han iniciado sesión y no tienen archivos, o los usuarios que faltan en oCIS, se omiten en este paso. Los recursos compartidos que involucran usuarios o grupos faltantes pueden reportarse como errores mientras continúa la migración. Para Cedar Studio, esto significa que el equipo debe inspeccionar la salida del comando y el inventario de recursos compartidos; la finalización sin un error grave no es lo mismo que la prueba de que todos los recursos compartidos funcionan correctamente.
La guía de migración indica que las etapas exitosas no se pueden repetir sin antes eliminar los datos de destino creados. --forceReiniciar la inicialización no elimina los archivos ya migrados de oCIS. No utilice indicadores de reinicio como estrategia de reintento habitual. Si una etapa falla, conserve los registros, identifique qué se creó y consulte la guía de migración o el soporte técnico antes de decidir si reparar el destino o reiniciar con uno nuevo.
Para una transición segura, Cedar Studio programaría un período en el que los empleados dejaran de modificar archivos en Classic, ejecutaría la migración aprobada y, posteriormente, redirigiría a los clientes y usuarios a oCIS solo después de que las comprobaciones fueran satisfactorias. Esta restricción de escritura es una medida de seguridad operativa, no una garantía de que la aplicación de migración realice una sincronización en tiempo real. La guía de migración publicada no documenta la sincronización continua ni un comando final de copia diferencial. Si la empresa no puede tolerar una restricción de escritura, solicite al soporte de ownCloud un plan de transición específico para la versión antes de garantizar una migración sin interrupciones.
Validar mediante una lista de verificación en lugar de iniciar sesión con un único administrador:
Mantenga Classic disponible en un estado de solo lectura controlado o congelado hasta que el propietario del negocio dé su aprobación y se hayan revisado los registros necesarios. Elimine la capacidad de suplantación temporal y revoque el token de la aplicación de migración cuando ya no sea necesario. Luego, realice una copia de seguridad de oCIS y pruébela siguiendo el procedimiento para su diseño de almacenamiento. Las consideraciones oficiales de copia de seguridad de oCIS 8.2 indican que la instancia debe estar completamente apagada para el procedimiento de copia de seguridad documentado y explican que los metadatos y los blobs de archivos pueden tener rutas de almacenamiento separadas.
En el ejemplo de Cedar Studio, el éxito no se limita a que se cargue la interfaz web de oCIS. Significa que los empleados pueden autenticarse con la fuente de identidad prevista, encontrar el contenido de su directorio personal, abrir archivos de equipo y usar recursos compartidos recreados o migrados con los permisos esperados. Se tienen en cuenta los restablecimientos de contraseña, los montajes externos y los cambios de enlaces públicos, mientras que Classic permanece disponible hasta su aceptación. Si alguna de estas comprobaciones falla, se pausa la migración, se registran los usuarios y objetos afectados y se resuelve el problema antes de considerar oCIS como el sistema de registro.
Establezca una fecha de vencimiento máxima para los enlaces públicos de ownCloud Server, comprenda a qué recursos compartidos afecta y verifique la política sin pasar por alto los enlaces más antiguos.
Configure la sincronización automática de la lista global de direcciones (GAL) de Zimbra, establezca el intervalo de sondeo, fuerce una sincronización de prueba, verifique las marcas de tiempo y solucione problemas con contactos LDAP internos o externos obsoletos.
Configure el inicio de sesión basado en LDAP para ownCloud Infinite Scale, asigne usuarios y grupos, elija OIDC integrado o externo, proteja las credenciales y verifique la autenticación de forma segura.
Planifica una migración de ownCloud Classic 10 a Infinite Scale con la aplicación compatible migrate-to-ocis. Descubre qué se transfiere, qué no, los requisitos previos de LDAP, los comandos y las comprobaciones de transición.
Aprende dónde carga Zimbra las reglas personalizadas de SpamAssassin, cómo escribir y validar una regla .cf, reiniciar Amavis, probar los encabezados de los mensajes y revertir los cambios de forma segura.
Realice copias de seguridad y restaure un buzón de correo individual de Zimbra CE con zmmailbox. Exporte un archivo ZIP con metadatos, verifíquelo y pruebe la recuperación de forma segura en una cuenta de prueba.
Aprende a establecer una cuota de espacio personal para un usuario de ownCloud Infinite Scale, a distinguirla de los límites globales y del espacio de proyecto, y a asignar valores predeterminados a los nuevos usuarios según su rol.
Diagnostique los tiempos de espera de registro SIP de BigBlueButton FreeSWITCH comprobando el estado del servicio, los oyentes SIP y ESL, las direcciones NAT, las reglas del firewall y los registros.
Solucione los errores de conexión rechazada de la aplicación móvil ownCloud comprobando la URL del servidor, el puerto HTTPS, el servidor web, el cortafuegos, el proxy, el TLS y los dominios de confianza.
Compara las diferentes formas de controlar las nuevas cuentas de Matrix en Synapse, desde deshabilitar el registro público hasta emitir tokens de uso limitado, con ejemplos de configuración y comprobaciones.
