En los unified environments administrados desde Power Platform admin center (PPAC), conocer que Dynamics 365 Finance and Operations 10.0.49 está en auto-update no es suficiente. Microsoft publica un calendario específico de despliegue por Stations, que determina cuándo una región recibe el service update en sandbox y posteriormente en producción.
Para un equipo que certifica productos ISV o localizaciones en varios países, este calendario permite convertir Evergreen en una planificación concreta de pruebas y no simplemente en una fecha general de actualización.
¿Qué es una Station?
Microsoft agrupa las regiones Azure en estaciones de despliegue. Para determinar cuándo se actualizará un ambiente hay que identificar primero su región, localizar la Station correspondiente y cruzarla con el calendario del service update.
Station 1 se reserva para ambientes que optan por recibir actualizaciones anticipadamente. Las demás Stations agrupan regiones específicas.
10.0.49: build exacto del rollout unificado
Para el rollout documentado de 10.0.49 en unified environments, Microsoft publica:
- App version: 10.0.2790.46
- Platform version: 7.0.8199.32
- Unified Environment Provisioning Application: 10.0.49.2
Esto demuestra por qué una evidencia de certificación debería registrar más que “10.0.49”: aplicación, plataforma y componentes de provisioning forman parte del baseline técnico real.
Calendario de 10.0.49 por Station
| Station | Sandbox | Producción |
|---|---|---|
| 1 | 23–24 sep 2026 | No aplica |
| 2 | 28–29 sep 2026 | 10–11 oct 2026 |
| 3 | 28–29 sep 2026 | 10–11 oct 2026 |
| 4 | 5–6 oct 2026 | 17–18 oct 2026 |
| 5 | 12–13 oct 2026 | 24–25 oct 2026 |
| 6 | 12–13 oct 2026 | 24–25 oct 2026 |
Un ejemplo relevante para LATAM: Brazil South
Brazil South pertenece a Station 4. Para 10.0.49, Microsoft programa el rollout de sandbox de esa Station para el 5–6 de octubre y producción para el 17–18 de octubre de 2026.
Esto no significa que todos los ambientes de Latinoamérica sigan esas fechas. La Station depende de la región Azure donde esté ubicado el ambiente. Brazil South es simplemente un ejemplo regional especialmente relevante para una estrategia LATAM.
Sandbox se convierte en la ventana formal de certificación
El calendario deja aproximadamente una ventana entre el despliegue de sandbox y producción. Esa separación debería utilizarse deliberadamente para ejecutar smoke tests, regresión funcional, integraciones, procesos batch, Electronic Reporting y escenarios regulatorios.
Para un producto multinacional, una estrategia práctica es mantener una matriz Región → Station → Sandbox date → Production date → Resultado de certificación.
Service Update y PQU no son el mismo calendario
Los Proactive Quality Updates tienen su propio release train. Microsoft publica también su calendario por Stations. Por ejemplo, el tren 10.0.49 PQU-1 está programado para comenzar el 7 de octubre de 2026. Por ello conviene separar en el control operativo el baseline del service update y el PQU/build exacto instalado.
Qué debería incorporar un equipo ISV
- registrar la región Azure de cada ambiente;
- mapearla con su Station;
- utilizar el sandbox como puerta de certificación antes de producción;
- registrar App version, Platform version y PQU/build;
- automatizar la evidencia de regresión asociándola al baseline certificado;
- no asumir una única fecha de actualización para todos los clientes LATAM.
El cambio hacia PPAC hace que el calendario regional pase a formar parte de la arquitectura operativa del producto. Para un ISV regional, saber qué versión soporta es tan importante como saber cuándo y dónde Microsoft la desplegará.
Fuentes oficiales
Microsoft Learn — Release schedule for service updates (unified environments)
Microsoft Learn — Service update availability
Microsoft Learn — Release schedule for proactive quality updates