Blog
Qué revisar antes de migrar un proyecto de AEM 6.5 a AEM as a Cloud Service.
En resumen. Antes de mover una sola página hay que revisar cinco frentes: la compatibilidad del código con un repositorio inmutable y con las API vigentes; el volumen y la estructura del contenido y los assets; la configuración de Dispatcher; las integraciones y la red; y el plan de corte. Adobe ofrece herramientas para casi todo este diagnóstico, pero las decisiones de remediación, y el orden en que se hacen, siguen siendo del equipo.
Qué cambia en AEM as a Cloud Service
La migración no es una actualización de versión: cambia el modelo de operación. Estas son las diferencias que más impacto tienen en un proyecto que viene de AEM 6.5:
- Adobe aplica las actualizaciones de forma continua; ya no hay proyectos de upgrade, pero el código tiene que tolerarlas.
- Las rutas /apps y /libs son inmutables en tiempo de ejecución: lo que antes se cambiaba en el servidor ahora tiene que llegar por código.
- Todo despliegue pasa por los pipelines de Cloud Manager, con revisiones de calidad de código que pueden detenerlo.
- Los run modes se limitan a author y publish combinados con los ambientes dev, stage y prod.
- Las configuraciones OSGi se escriben en formato JSON (.cfg.json).
- Los agentes de replicación desaparecen; la publicación usa Sling Content Distribution.
- El procesamiento de assets pasa a los asset microservices, así que las personalizaciones del flujo DAM Update Asset hay que replantearlas.
- La interfaz clásica (Classic UI) ya no está disponible.
Las herramientas de Adobe que conviene usar
Adobe documenta el recorrido de migración en Experience League y ofrece herramientas específicas. No sustituyen el criterio del equipo, pero dan un inventario objetivo desde el primer día:
- Best Practices Analyzer: se ejecuta en la instancia de 6.5 y lista los patrones incompatibles con Cloud Service.
- Cloud Acceleration Manager: organiza los hallazgos y acompaña la planeación de la migración.
- Content Transfer Tool: mueve contenido del repositorio y admite transferencias incrementales posteriores.
- Repository Modernizer: reorganiza la estructura de paquetes del proyecto a la que espera Cloud Service.
- Dispatcher Converter e Index Converter: adaptan la configuración de Dispatcher y los índices de Oak personalizados.
- AEM Modernization Tools: ayudan a pasar de plantillas estáticas a editables y de componentes de fundación a Core Components.
Qué revisar en el código
El informe de Best Practices Analyzer suele ser largo. Para priorizar, estas son las preguntas que nos hacemos sobre el código de un proyecto antes de estimar:
- ¿Hay código que escribe en /apps o /libs en tiempo de ejecución, o configuraciones que se editaban a mano en el servidor?
- ¿Qué API deprecadas o retiradas usa, y qué dependencias de terceros no compilan con la versión de Java que soporta Cloud Manager?
- ¿Hay tareas programadas o procesos largos que asumen una sola instancia? En la nube las instancias escalan y se reemplazan.
- ¿Qué personalizaciones hay sobre los flujos de assets, y cuáles se pueden resolver con perfiles de procesamiento?
- ¿El proyecto usa plantillas estáticas o componentes de fundación que convenga modernizar ahora y no después?
- ¿Cuánta cobertura de pruebas existe? Sin ella, cada corrección es una apuesta.
Contenido y assets
El contenido es donde más se subestima el esfuerzo. Conviene medir antes el tamaño del repositorio y de la biblioteca de assets, depurar versiones antiguas y registros de auditoría que no aportan, y decidir qué contenido ya no se migra.
La transferencia se planea en al menos dos momentos: una carga inicial con tiempo para probar y una o varias cargas incrementales cerca del corte. Entre la última carga y el lanzamiento se acuerda un periodo de congelamiento editorial, corto y conocido por todos los autores. Los usuarios y grupos también cambian: en Cloud Service la identidad se gestiona con Adobe IMS, y el mapeo de permisos es una tarea en sí misma.
Dispatcher y CDN
La configuración de Dispatcher cambia de estructura: hay archivos que Adobe fija y otros que el proyecto puede modificar, y todo se valida con las herramientas del SDK antes de desplegar. Probarla en local desde el principio evita descubrir en el pipeline que una regla de caché o un filtro no son válidos.
Cloud Service incluye una CDN administrada por Adobe. Las cabeceras de caché que antes se ajustaban en el servidor web ahora tienen que pensarse para esa capa, y conviene revisar qué contenido debe invalidarse y cuándo.
Integraciones y red
Si AEM se conecta con sistemas que filtran por dirección IP, como un ERP, una API interna o un servicio de terceros con lista de acceso, hace falta configurar la red avanzada de Cloud Service para tener una IP de salida dedicada o una VPN. Es una tarea con tiempos de coordinación con otros equipos, así que se identifica al inicio y no en la semana del corte.
Cómo ordenamos el plan
Con el diagnóstico en la mano, el orden que seguimos es este:
- Inventario: Best Practices Analyzer, tamaño del contenido e integraciones.
- Remediación del código y reestructura del proyecto.
- Pipeline de Cloud Manager funcionando en el ambiente de desarrollo.
- Primera transferencia de contenido y pruebas funcionales con autores reales.
- Pruebas de rendimiento y de Dispatcher en stage.
- Transferencia incremental, congelamiento editorial y corte.
Errores que conviene evitar
Los tropiezos más frecuentes no son técnicos sino de planeación: dejar la remediación del código para el final, estimar el contenido por número de páginas y no por tamaño real del repositorio, probar Dispatcher por primera vez en el pipeline, y no reservar tiempo para que los autores validen su contenido antes del corte.
Si tu proyecto de AEM ya es difícil de mantener en 6.5, la migración es también la oportunidad de corregirlo. Una auditoría previa separa lo que hay que remediar para migrar de lo que conviene rehacer.