🚚 D365FO abre la migración irreversible de LCS a PPAC
🚚 D365FO abre la migración irreversible de LCS a PPAC
Microsoft ha abierto en public preview la migración autoservicio de entornos existentes de Finance and Operations desde Lifecycle Services (LCS) a Power Platform admin center (PPAC). No mueve la base de datos ni reconstruye la infraestructura: cambia el plano de control que gobierna el ciclo de vida del entorno. A partir del corte, copia, backup, restore, actualización, monitorización y servicing se administran desde PPAC, mientras LCS queda en modo de solo lectura para ese entorno.
La distinción importa porque esta migración es unidireccional, por entorno y sin rollback iniciado por el cliente. Tampoco migra el proyecto de LCS completo ni devuelve su slot. Es una decisión de arquitectura y operación, no un cambio de portal.
Diagrama original. Los datos permanecen en el entorno; cambian el plano de administración y la ruta de ALM.
Qué ha cambiado
La guía técnica, publicada el 22 de septiembre de 2026, confirma que los clientes existentes ya pueden iniciar la migración desde el detalle de cada entorno en LCS. La función comprueba estado, vinculación con Power Platform, capacidad de base de datos y privilegios antes de habilitar la operación.
| Antes | Public preview actual |
|---|---|
| LCS seguía siendo el plano de control de los entornos existentes. | Un entorno elegible puede transferir su administración a PPAC. |
| Los despliegues y promociones seguían el flujo de paquetes de LCS. | El entorno migrado usa paquetes unificados, Power Platform y Azure Pipelines. |
| El dimensionamiento se asociaba a slots de entorno de LCS. | El entorno consume el modelo de capacidad de Power Platform. |
| La transición dependía del calendario de Microsoft. | El cliente ejecuta una migración autoservicio por entorno. |
Microsoft recomienda migrar primero sandboxes y no recomienda producción durante la public preview. Que la acción pueda aparecer en un entorno productivo no equivale a una recomendación de uso productivo.
Qué cambia por dentro
La operación actualiza metadatos entre servicios de Microsoft para que PPAC pase a ser la autoridad del ciclo de vida. Según la documentación oficial:
- la base de datos no se traslada;
- la infraestructura del entorno no cambia materialmente;
- el entorno queda indisponible durante parte del proceso;
- LCS conserva una vista de solo lectura;
- PPAC asume las operaciones de entorno;
- el pipeline de aplicación debe cambiar al modelo unificado.
La indisponibilidad estimada es de aproximadamente 15 minutos por instancia AOS. Es una estimación, no un SLA: reserva margen adicional y evita otras operaciones de lifecycle dentro de la ventana.
El cambio puede resumirse así:
Antes: Azure DevOps -> paquete desplegable -> LCS -> entorno D365FO
Después: Azure DevOps -> paquete unificado -> Power Platform pipeline/PPAC -> entorno D365FO
Por eso no conviene migrar primero y adaptar CI/CD después. El nuevo camino de despliegue debe existir, estar probado y producir el artefacto correcto antes del corte.
Disponibilidad y límites confirmados
La capacidad está en public preview desde septiembre de 2026. Microsoft documenta esta matriz:
| Tipo o carga | Estado |
|---|---|
| Sandbox self-service | Soportado para migración y validación. |
| Producción self-service | La acción puede estar disponible, pero Microsoft no recomienda migrarla durante la preview. |
| Entorno developer cloud-hosted | No soportado; sustituir por Unified Developer Environment o VHD local. |
| Entorno con funcionalidad de Dynamics 365 Commerce | No soportado durante la preview. |
Hay una limitación especialmente peligrosa: el chequeo previo no detecta actualmente el uso de Commerce. El hecho de que los cuatro indicadores de LCS aparezcan en verde no demuestra que el entorno sea elegible. El equipo debe verificar Commerce de forma independiente.
No es necesario habilitar dual-write. Sí es obligatorio que el entorno esté vinculado a un entorno de Power Platform.
Requisitos previos
Antes de reservar la ventana, valida y conserva evidencia de lo siguiente:
- El entorno no usa ninguna funcionalidad de Commerce.
- Su estado en LCS es Deployed y no hay operaciones de lifecycle activas.
- Existe una vinculación correcta con Power Platform.
- No hay déficit de capacidad de almacenamiento de base de datos en Power Platform.
- La persona que inicia la migración es administradora del entorno de Power Platform vinculado.
- Los developer cloud-hosted tienen un reemplazo planificado.
- Un pipeline probado genera y despliega paquetes unificados.
- Integraciones, add-ins, autenticación y procesos críticos tienen casos de prueba repetibles.
- La ventana contempla unos 15 minutos por AOS más margen de contingencia.
- Los usuarios y equipos de soporte conocen la indisponibilidad y la ausencia de rollback autoservicio.
La comprobación de capacidad tiene consecuencia económica: después del corte, el entorno se gobierna por el modelo de capacidad de Power Platform. Microsoft no anuncia una licencia nueva para la operación, pero sí cambia la unidad operativa con la que se provisiona capacidad. El slot de LCS no se libera ni puede reutilizarse para levantar otro entorno.
Secuencia segura de adopción
Trata la migración como un programa de oleadas:
- Despliega Unified Developer Environments y prepara CI/CD en paralelo con el flujo existente.
- Elige un sandbox poco crítico y representativo.
- Captura inventario, configuración, integraciones y pruebas antes del corte.
- Migra ese sandbox.
- Valida acceso, operaciones de entorno, un despliegue de código, integraciones y add-ins.
- Ejecuta una copia desde PPAC y valida también el destino.
- Migra el resto de sandboxes de uno en uno.
- Plantea producción únicamente cuando Microsoft la recomiende para la fase de lanzamiento y tus sandboxes hayan superado el ensayo.
Coordina la última oleada de sandboxes con el corte de ALM. Una vez migrados, los workflows de despliegue y promoción de LCS dejan de administrarlos.
Migración paso a paso
1. Abrir el entorno en LCS
Entra en el proyecto, localiza el sandbox y selecciona Full details. La operación se repite de forma independiente para cada entorno; no existe una migración del proyecto entero.
2. Revisar Power Platform migration (Preview)
Expande la sección y exige cuatro indicadores verdes:
- Environment is in Deployed status;
- Power Platform environment is linked;
- Database storage capacity is available;
- You are an administrator of the linked Power Platform environment.
Añade a esa lista la comprobación manual de Commerce. Los indicadores integrados no la cubren.
3. Confirmar el corte
Selecciona Migrate to Power Platform Admin Center, revisa la advertencia de indisponibilidad y operación unidireccional, escribe exactamente el nombre del entorno y pulsa Start migration.
No inicies actualizaciones, copias, despliegues o mantenimientos en paralelo. Conserva hora de inicio, operador, ID del entorno, número de AOS y registro de cambio.
4. Esperar el estado final
Mantén la ventana abierta hasta que Migration status sea Migrated. Usa entonces Open in Power Platform Admin Center. No interpretes la desaparición temporal de controles como un fallo ni intentes repetir la acción mientras el proceso está activo.
Validación después del corte
Antes de autorizar la siguiente oleada, ejecuta una prueba de aceptación:
- inicio de sesión de administradores y usuarios funcionales;
- detalles, health y monitorización en PPAC;
- backup, restore, copy, servicing y actualización disponibles;
- despliegue de una personalización validada mediante el nuevo pipeline;
- ejecución de batch, impresión, Electronic Reporting y servicios críticos;
- integraciones entrantes y salientes, service endpoints y autenticación;
- add-ins instalados en el entorno;
- copia del entorno y validación del destino;
- observabilidad, alertas y procedimiento de soporte actualizados.
Si aparece un problema, detén las siguientes migraciones. Volver a LCS no es una estrategia de rollback disponible para el cliente. El plan de contingencia debe consistir en diagnosticar y escalar el entorno migrado, no en revertir el plano de control.
Seguridad y gobierno
La comprobación de migración exige ser administrador del entorno de Power Platform. Usa una identidad nominativa o de operación controlada, con MFA y acceso temporal cuando sea posible; evita compartir una cuenta privilegiada. Separa además quién aprueba la oleada, quién ejecuta el cambio y quién valida el resultado.
Después del corte, revisa:
- roles administrativos en PPAC;
- permisos de las conexiones de Azure DevOps y Power Platform;
- service connections usadas por los pipelines;
- acceso a copias, backups y restores;
- retención de evidencias del cambio y resultados de prueba.
La migración del control plane no modifica automáticamente los roles funcionales dentro de Finance and Operations, pero sí cambia quién puede realizar operaciones potencialmente destructivas sobre el entorno.
Problemas en las comprobaciones previas
| Fallo | Acción |
|---|---|
El entorno no está Deployed | Esperar a que termine la operación activa y resolver su estado de salud. |
| No está vinculado a Power Platform | Completar la integración desde LCS antes de migrar. |
| Falta capacidad de base de datos | Liberar o adquirir capacidad hasta eliminar el déficit. |
| El usuario no es administrador | Asignar el rol adecuado en el entorno vinculado y refrescar LCS. |
| Usa Commerce | No migrar durante esta preview, aunque los checks aparezcan en verde. |
Recomendación práctica
La preview merece un laboratorio inmediato, pero no una carrera hacia producción. Construye primero el nuevo camino de ALM, ensaya con un sandbox poco crítico y exige una copia completa como prueba del nuevo plano de control. Documenta explícitamente dos hechos en la aprobación del cambio: el slot de LCS no se recupera y la migración no tiene retorno autoservicio.
La gran novedad no es PPAC como pantalla. Es que Microsoft ya ofrece el mecanismo que permite a los clientes existentes cruzar, entorno a entorno, del modelo LCS al modelo unificado. Ese puente cambia administración, capacidad, desarrollo y despliegue a la vez.