Microsoft confirmó hace unos meses la retirada definitiva de Project Online para el 30 de septiembre de 2026. En España y LATAM, numerosas organizaciones del ecosistema Microsoft 365 todavía mantienen activa su cartera completa de proyectos sobre la plataforma.
Toda la información operativa de esos proyectos debe trasladarse al nuevo entorno antes del cierre:
- Tareas, subtareas, dependencias e hitos acumulados durante años de gestión.
- Líneas base históricas de cada proyecto y sus campos de referencia.
- Recursos genéricos y asignaciones vinculadas a cada tarea.
- Calendarios laborales propios y valores de listas personalizadas (lookups).
La pregunta operativa que primero deben responder los responsables del proceso es siempre la misma. Qué se migra exactamente de Project Online a Planner Premium, qué no, y bajo qué condiciones.
El destino más extendido es Planner Premium combinado con Power Platform, una arquitectura más moderna e integrada de forma nativa en Microsoft 365. Conviene, sin embargo, desactivar desde el inicio una idea muy extendida.
Planner Premium no es una réplica funcional de Project Online. Es una plataforma diferente, con su propio modelo de datos, sus propios límites técnicos y su propia lógica de programación.
Esa diferencia tiene consecuencias muy concretas en la migración. La mayor parte de los datos de planificación se traslada sin incidencias, pero algunos elementos se recalculan, otros se transforman en estructuras distintas y otros quedan fuera del alcance del proceso automatizado.
Desconocer estas reglas antes de ejecutar la migración suele traducirse en pérdidas de información, reprocesos manuales y validaciones costosas a posteriori.
Nota: Este artículo describe qué información se traslada de Project Online a Planner Premium, qué se transforma, qué queda fuera del alcance y qué buenas prácticas conviene aplicar antes, durante y después del proceso. Los datos técnicos están atribuidos a la documentación oficial de Microsoft. Está orientado a Directores de PMO, CIOs, CTOs y responsables de transformación digital que afronten la migración en los próximos meses.
También te puede interesar:
- Los 6 pasos para migrar de Project Online a Planner
- Checklist de pre-migración a Planner Premium: 15 puntos críticos antes de migrar tu Project Online
- ¿Cuánto cuesta migrar de Project Online a Planner Premium en 2026?
Resumen ejecutivo: qué se traslada y qué no en la migración
La migración automatizada de Project Online a Planner Premium clasifica la información de origen en tres categorías de comportamiento. Cada una requiere un tratamiento distinto en la fase de preparación y validación.
Conocer esta clasificación de entrada permite anticipar qué proyectos pueden migrarse sin intervención adicional, cuáles necesitan ajustes previos y dónde se concentrará el trabajo manual posterior al traslado automatizado.A continuación se desglosan las tres categorías con el detalle operativo que aplica a cada una.
Lo que migra correctamente
Estos elementos se trasladan de forma íntegra, sin transformaciones ni intervención manual, siempre que los proyectos de origen se mantengan dentro de los límites de capacidad del entorno de destino:
- Tareas y subtareas con sus fechas, duración y porcentaje de progreso, hasta 3.000 tareas por proyecto.
- Dependencias entre tareas (relaciones de precedencia) conservadas tal cual.
- Hitos (milestones) del proyecto original.
- Asignaciones de usuarios previamente mapeados en el proceso de configuración.
- Línea base por defecto con sus campos de inicio, fin, trabajo, coste y duración.
- Valores de los campos personalizados y de las listas de origen (no las listas en sí mismas).
Lo que se migra con condiciones o se transforma
Este bloque concentra los elementos que cambian de forma, se recalculan o requieren configuración específica para trasladarse. Es la categoría que más sorpresas suele generar en la validación posterior:
- Tareas de resumen: no se migran como tales; se recalculan automáticamente a partir de las subtareas. Sus asignaciones propias no se trasladan.
- Calendarios laborales: se recomienda recrearlos manualmente en el entorno de destino antes de iniciar la migración.
- Jerarquía de tareas: se admiten un máximo de 10 niveles; los niveles más profundos se colapsan al último nivel disponible.
- Etiquetas (labels): límite de 25 por proyecto y 25 por tarea; el resto se omite.
- Estructura de buckets: todas las tareas se agrupan en un único bucket por defecto. La organización por buckets debe reconstruirse después en destino.
- Recursos genéricos: se convierten en recursos reservables (Bookable Resources) del modelo de Dynamics.
- Fechas fuera de rango admitido o del rango del proyecto: se ajustan automáticamente según las reglas que se detallan en el artículo.
- Línea base y campos personalizados a nivel de tarea: requieren un token de API durante la conexión para que se migren correctamente.
Lo que no migra o queda fuera de alcance
Estos elementos quedan fuera del proceso automatizado. Su gestión exige acciones previas en el tenant de destino o reconstrucción manual posterior:
- Usuarios: no se crean automáticamente; deben existir previamente en el tenant de destino.
- Definiciones de listas y lookups: solo se trasladan sus valores, no las listas como estructura.
- Líneas base adicionales: únicamente se migra la línea base por defecto; el resto de baselines numerados se pierde.
- Asignaciones asociadas a tareas de resumen: quedan fuera por construcción del nuevo modelo.
- Todo lo que supere los límites de capacidad: tareas por encima de 3.000, recursos por encima de 150 por proyecto, asignaciones por encima de 20 usuarios por tarea.
Esta clasificación general se desarrolla con detalle técnico, valores numéricos y comportamiento exacto más adelante en el artículo. Conviene leerlos antes de planificar la ejecución del proceso o validar el alcance de la migración con el equipo técnico responsable.
→ Descarga la Guía de Migración Project Online a Planner Premium (PDF gratuito).
Limitaciones generales: tareas, fechas y estructura del proyecto
Este apartado recoge las reglas que aplican a cómo se trasladan las tareas, sus fechas, su jerarquía y los límites máximos de capacidad de cada proyecto. Los valores numéricos provienen de la documentación oficial de Microsoft sobre Project Online y Project for the web y de la herramienta de migración automatizada.
Conviene revisarlas antes de la ejecución. Cualquier proyecto que exceda alguno de estos límites debe simplificarse o dividirse en origen para evitar la pérdida automática de información durante el proceso.
Calendarios laborales y modo de programación «Duración fija»
Los calendarios laborales no se trasladan automáticamente. Se recomienda crear en el entorno de destino un calendario equivalente al de origen antes de iniciar la migración.
Si se define un calendario personalizado a nivel de proyecto en Planner Premium, conviene aplicar también ese mismo calendario a los recursos reservables (Bookable Resources) asignados a las tareas. Esta sincronización evita inconsistencias en el recálculo posterior de fechas.
Respecto al modo de programación, Planner Premium opera por defecto en modo «Duración fija» (Fixed Duration). Es el modo recomendado para una migración precisa, pero esta configuración no se gestiona desde la interfaz de Planner.
Su comprobación o ajuste se realiza desde los parámetros del entorno de Power Platform (Power Apps). Si previamente se ha modificado el modo por defecto a nivel de entorno, el cambio puede afectar al traslado de los datos de tarea.
Tareas de resumen: el recálculo automático en Planner Premium
Las tareas de resumen no se migran como entidades propias. En su lugar, Planner Premium las recalcula automáticamente a partir de las subtareas que las componen.
Esto introduce dos efectos prácticos que conviene conocer antes de validar la migración:
- Las asignaciones aplicadas directamente sobre una tarea de resumen no se trasladan. Solo se conservan las asignaciones de las subtareas que cuelgan de ella.
- El esfuerzo total del proyecto puede diferir del trabajo total de origen. Si en Project Online se aplicaba esfuerzo directamente al nivel de resumen, esa información no se recuperará en destino.
Las PMOs maduras que utilizan asignaciones a nivel de resumen para gestión de líderes de proyecto deben anticipar esta divergencia y planificar la reasignación manual posterior.
Tareas sin fechas, hitos y duraciones especiales
El motor de migración aplica reglas distintas según los campos cumplimentados en origen. La regla general es: Fecha de fin = Fecha de inicio + duración.
Para las tareas sin fechas asignadas, el comportamiento varía según el resto de campos:
- Tarea sin fechas pero con valores de trabajo: se migra fijando la fecha del día de ejecución como fecha de inicio.
- Tarea sin fechas pero con solo duración definida: se migra sin fechas ni duración.
- Tarea sin fechas pero con dependencia hacia otra tarea: se migra con fechas calculadas automáticamente desde la dependencia.
Los hitos también tienen un comportamiento específico. Los hitos con un progreso superior al 0% pero inferior al 100% y con duración igual a cero se migran como «No iniciado», independientemente del avance que reflejen en origen.
Las tareas con una sola fecha (solo inicio o solo fin) se migran fijando ambas fechas al mismo valor. Y las duraciones expresadas en días naturales (eDays) se convierten automáticamente a duraciones en días estándar laborables.
Niveles de jerarquía, fines de semana y rango de fechas admitido
Planner Premium impone un máximo de 10 niveles de jerarquía de tareas. Las estructuras de origen más profundas se colapsan al último nivel disponible, perdiendo la profundidad adicional.
Esta limitación afecta especialmente a proyectos de gran envergadura con desgloses WBS muy detallados. Estos proyectos deben simplificarse antes de la migración o reorganizarse en múltiples proyectos enlazados.
Las fechas que caigan en fin de semana se desplazan automáticamente al siguiente día laborable disponible, conforme al calendario de destino. Por eso es crítico tener el calendario laboral correctamente configurado antes de iniciar el proceso.
El rango de fechas admitido por Planner Premium es 1/1/2000 – 31/12/2149. Los proyectos con fechas fuera de este rango se ajustan automáticamente:
- Si ambas fechas son anteriores al 1/1/2000: no se establecen fechas en la tarea de destino.
- Si una fecha es anterior al 1/1/2000 y la otra posterior: ambas se fijan al valor posterior.
Límites de capacidad por proyecto: tareas, duración total y duración por tarea
Estos son los tres techos cuantitativos que definen el alcance máximo de un proyecto migrable a Planner Premium:
- Máximo de tareas por proyecto: 3.000 tareas. Las tareas que excedan este número se omiten.
- Duración total máxima del proyecto: 3.650 días laborables (equivalente a 10 años). Si se supera, la fecha de inicio se recalcula a 3.650 días desde la fecha de fin, y la fecha de fin se fija a la más tardía de origen.
- Duración máxima de una tarea individual: 1.250 días laborables. Las tareas que excedan ese valor tendrán fecha de inicio igual a fecha de fin.
Adicionalmente, las fechas de tareas que caigan fuera del rango temporal del proyecto se ajustan según dos reglas. Si ambas fechas están fuera de rango, no se establecen. Si solo una está fuera, la segunda fecha se fija a la que sí esté dentro del rango admitido.
En carteras complejas con proyectos que rocen estos límites, conviene apoyarse en una estrategia previa de gestión de cartera para identificar qué proyectos deben dividirse o simplificarse antes del traslado.
Buckets, etiquetas y valores de lista (lookups)
La estructura de buckets de origen no se conserva. Todas las tareas del proyecto de origen se migran a un único bucket por defecto en destino, y la organización por buckets debe reconstruirse manualmente después.
Para las etiquetas (labels), el sistema aplica un límite estricto de 25 etiquetas por proyecto. Si el proyecto de origen contiene más, solo se migran las 25 primeras y el resto se omite sin aviso.
Los valores de lista (lookups) tienen un tratamiento específico que conviene distinguir por nivel de aplicación:
- A nivel de proyecto: los campos y las listas no se migran como estructuras. Solo se trasladan sus valores a los campos de Planner, y únicamente si dichos campos ya existen previamente en destino.
- A nivel de tarea: los campos personalizados y los valores de lista pueden migrarse a campos personalizados de destino si se proporciona un token de API en la conexión.
- Sin token: los valores pueden trasladarse a campos de tarea estándar o convertirse en etiquetas si se configura el mapeo, respetando el límite de 25 por tarea y 25 por proyecto.
Esta lógica explica por qué la preparación previa del entorno de destino, con los campos personalizados ya creados, es uno de los factores que más influye en la calidad final del traslado.
Línea base: por qué solo migra la línea base por defecto
De todas las líneas base que un proyecto pueda tener en Project Online, el proceso automatizado migra únicamente la línea base por defecto (la que no lleva sufijo numérico).
Los baselines numerados (Baseline1, Baseline2, hasta Baseline10) no se trasladan al entorno de destino. Para PMOs maduras que utilizan múltiples líneas base como mecanismo de gobernanza o auditoría histórica, esta es una de las limitaciones más relevantes del proceso.
De la línea base por defecto se migran cinco campos:
- Inicio y fin de línea base: se trasladan a los campos nativos de la tarea en Planner Premium.
- Coste, duración y trabajo de línea base: se trasladan a campos personalizados creados en destino.
La migración de estos cinco campos requiere un token de API generado al conectar con el entorno de Planner Premium. Sin token, ni la línea base ni los campos personalizados a nivel de tarea se migran correctamente. Por eso este paso debe planificarse desde el inicio del proceso, no como ajuste posterior.
Si el equipo todavía no tiene definido el plan operativo de traslado, conviene apoyarse en los pasos generales de migración a Planner antes de entrar en estos detalles técnicos.
Migración de asignaciones, recursos y usuarios
Las personas y los recursos asignados a las tareas siguen reglas de migración distintas a las de los datos de planificación. Es uno de los bloques que más preparación previa requiere por parte del equipo de TI.
A diferencia de los datos de tarea, que se trasladan en su mayor parte de forma automática, los usuarios y los recursos exigen acciones explícitas antes de iniciar el proceso. Sin esa preparación, las asignaciones de origen no podrán reconstruirse correctamente en destino.
→ Descarga la Guía de Migración Project Online a Planner Premium (PDF gratuito).
Usuarios: alta previa en el tenant de destino y mapeo
Los usuarios no se migran automáticamente. La herramienta de migración asume que los usuarios necesarios existen ya en el tenant de destino con las cuentas activas y los permisos correspondientes.
Esto implica que el primer paso operativo del proceso es dar de alta en el tenant de destino a todos los usuarios que aparezcan como miembros, propietarios o recursos asignados en cualquier proyecto del alcance migrable.
Una vez completado el alta, los usuarios de origen deben mapearse a sus equivalentes de destino en la pantalla de «Mapeo de usuarios» de la herramienta. Sobre este mapeo conviene tener presente lo siguiente:
- No se requiere coincidencia exacta de nombres ni de cuentas. El sistema permite mapear, por ejemplo, un usuario juan.perez@dominioantiguo.com a un usuario j.perez@dominionuevo.com.
- Los recursos y usuarios se obtienen de los miembros del equipo de los proyectos seleccionados. Este comportamiento aplica con hasta 100 proyectos seleccionados.
- Por encima de 100 proyectos seleccionados, el sistema recupera todos los recursos disponibles en Project Online, lo que puede ralentizar el mapeo en carteras extensas.
Este umbral de 100 proyectos es uno de los factores que conviene considerar al definir la estrategia de migración por lotes. En carteras grandes, conviene agrupar proyectos en bloques de hasta 100 para mantener el mapeo manejable.
Asignaciones de tarea: a qué se convierten los usuarios mapeados
Las asignaciones de tarea se migran exclusivamente para los usuarios que hayan sido mapeados en el paso anterior. Los usuarios sin mapear quedan fuera del proceso, y sus asignaciones se pierden.
Cada usuario mapeado se añade en destino con cuatro roles paralelos:
- Miembro del proyecto y del equipo de destino, con visibilidad y permisos sobre las tareas en las que tenía asignación.
- Recurso reservable (Bookable Resource) de Dynamics, lo que permite gestionar su carga de trabajo desde el modelo de recursos de Power Platform.
- Si era propietario del proyecto en origen, se añade además como miembro del grupo de Microsoft 365 vinculado.
- La cuenta de sincronización utilizada para ejecutar la migración se establece como propietaria y miembro del grupo de Microsoft 365 generado.
Este último punto es importante para la gobernanza posterior. La cuenta que ejecuta la migración hereda propiedad sobre los grupos creados, lo que conviene revisar y reasignar después del proceso si la cuenta de migración no debe quedar como propietaria permanente.
Recursos genéricos transformados en Bookable Resources
Project Online distingue entre recursos individuales y recursos genéricos (perfiles abstractos como «Desarrollador Senior» o «Consultor Junior») utilizados para planificación de capacidad sin asignar a una persona concreta.
Planner Premium no mantiene esta distinción conceptual del mismo modo. En el mapeo de la herramienta de migración solo aparecen los recursos reservables (Bookable Resources) como entidades disponibles.
Esto tiene una consecuencia operativa directa para las PMOs que utilizan planificación por capacidad genérica:
- Los recursos genéricos de Project Online solo pueden migrarse como recursos reservables de otro tipo en destino. No existe un equivalente nativo al recurso genérico en el modelo de Planner Premium.
- El modelo de capacidad debe rediseñarse después de la migración utilizando las capacidades de Bookable Resources combinadas con Power Apps o con la vista People de Planner Premium.
Para PMOs que dependen fuertemente de planificación por perfiles genéricos, este cambio de modelo es una de las decisiones de diseño más relevantes a abordar antes del traslado. Suele requerir una sesión específica de rediseño del modelo de recursos.
¿Tu cartera tiene proyectos que rozan los límites de 3.000 tareas o 150 recursos? En AIC identificamos en 45 minutos qué proyectos de tu cartera requieren rediseño antes del traslado, qué información se perderá si se migra tal cual, y qué secuencia de ejecución minimiza el trabajo manual posterior. Solicita una auditoría previa de migración →
Límites: 150 recursos por proyecto y 20 usuarios por tarea
Planner Premium aplica dos límites duros sobre asignaciones que conviene contrastar con la cartera de origen antes de iniciar la migración:
- Máximo de 150 asignaciones únicas de recursos por proyecto. Las asignaciones que excedan este número se omiten sin aviso.
- Máximo de 20 usuarios asignados a una misma tarea. Las asignaciones adicionales en una tarea se descartan automáticamente.
Estos límites suelen no afectar a proyectos de tamaño medio, pero en carteras industriales o de construcción con cientos de recursos coordinados o tareas colectivas de gran tamaño pueden ser bloqueantes.
Identificarlos en la fase de auditoría previa permite anticipar el rediseño necesario. En la práctica, suele resolverse dividiendo proyectos demasiado grandes en subproyectos enlazados o reagrupando asignaciones por equipos en lugar de por personas individuales.
Esta reorganización del modelo de recursos forma parte del esfuerzo de implementación y consultoría que debe contemplarse en el presupuesto de la migración, especialmente en organizaciones con carteras complejas.
Grupos de Microsoft 365 y estrategias de creación de proyectos
Cada proyecto migrado a Planner Premium se asocia a un grupo de Microsoft 365 en el tenant de destino. La elección de cómo crear o reutilizar esos grupos condiciona el modelo de gobernanza posterior y, en algunos casos, la integridad de los datos existentes.
Este apartado describe los requisitos de cuenta, los límites operativos y las cuatro estrategias disponibles para gestionar la creación o la fusión de proyectos en destino.
Migrar a grupos de Microsoft 365 existentes: requisitos de cuenta
Migrar proyectos a grupos de Microsoft 365 que ya existen en el tenant exige que la cuenta de conexión utilizada para la migración cumpla con dos condiciones simultáneas. Debe ser miembro del grupo y, además, propietaria del mismo.
Esta exigencia aplica especialmente cuando la cuenta que ejecuta la migración no tiene rol de Administrador Global del tenant. En ese escenario, sin propiedad explícita sobre el grupo, la herramienta no podrá añadir miembros durante el proceso.
Esto tiene una implicación práctica directa para el equipo de TI:
- Antes de iniciar la migración, debe verificarse que la cuenta de conexión esté añadida como propietaria y como miembro en cada grupo de destino al que se quiera migrar proyectos.
- Esta verificación es manual y debe hacerse desde el centro de administración de Microsoft 365 o vía PowerShell para escenarios masivos.
- Saltarse este paso suele detectarse demasiado tarde, cuando la herramienta ya devuelve errores de permisos sobre grupos concretos.
En migraciones con muchos grupos preexistentes, automatizar esta verificación mediante un script PowerShell de validación previa ahorra horas de reproceso durante la ejecución.
Creación de grupos nuevos y límite de 250 grupos para cuentas no-admin
Cuando la herramienta crea grupos de Microsoft 365 nuevos durante la migración, la cuenta de migración de destino se establece automáticamente como propietaria y como miembro de cada uno.
Sobre esta creación automática aplica un límite que conviene conocer de antemano:
- Las cuentas que no son administradoras globales pueden crear un máximo de 250 grupos de Microsoft 365 en el tenant. Es un techo nativo de Microsoft 365, no de la herramienta de migración.
- Este total acumula con los grupos previos creados por esa misma cuenta. No son 250 grupos nuevos en cada migración: son 250 grupos totales históricos creados por la cuenta.
- Solo se añadirán los grupos creados durante la migración que entren dentro de ese total acumulado de 250. El resto fallará al crearse.
En migraciones grandes con carteras de más de 250 proyectos, este límite obliga a una de dos decisiones. O se ejecuta la migración con una cuenta de Administrador Global del tenant, o se segmenta el proceso utilizando varias cuentas de migración con distribución de carga entre ellas.
Adicionalmente, todos los grupos nuevos creados durante la migración se generan con visibilidad pública. Los grupos ya existentes mantienen su configuración previa. Esto debe revisarse después de la migración si la política de gobernanza interna requiere que ciertos proyectos operen sobre grupos privados.
Las estrategias de creación y fusión de proyectos
La herramienta ofrece cuatro modos de operar respecto a los grupos de Microsoft 365 y los proyectos preexistentes en destino. Cada uno tiene implicaciones distintas sobre los datos:
- Crear grupos con los nombres de proyecto: si ya existe un grupo o proyecto con el mismo nombre que el proyecto de origen, los datos se fusionan en el existente. Útil cuando se quiere consolidar información en estructuras ya creadas.
- Crear todos los proyectos en un grupo (crear nuevos o fusionar): todos los proyectos de origen se ubican bajo un único grupo de Microsoft 365. Si existen proyectos con nombres coincidentes en ese grupo, los datos se fusionan con los existentes.
- Crear nuevos y eliminar los existentes antes de crear (opción destructiva, ver aviso abajo).
- Mantener proyectos preexistentes intactos y crear los nuevos solo donde no haya conflicto de nombres.
⚠️ Aviso sobre la opción destructiva. La estrategia «Crear nuevos y eliminar los existentes antes de crear» borra los proyectos de destino cuyos nombres coincidan con los proyectos de origen seleccionados. Junto con los proyectos, se eliminan también todas sus tareas asociadas antes de crear los nuevos con el mismo nombre. Esta opción debe utilizarse únicamente cuando se quiere reemplazar deliberadamente proyectos de destino. Conviene aislar su uso a entornos de prueba o requerir doble validación antes de ejecutarla en producción.
La selección de la estrategia adecuada no es una decisión técnica menor. Define qué proyectos del entorno actual sobreviven a la migración y cuáles se sobrescriben, lo que afecta directamente a la continuidad operativa del portafolio.
Visibilidad de los grupos y miembros del equipo
Todos los miembros mapeados del equipo de origen se añaden al grupo de Microsoft 365 del proyecto en destino, siempre que esos usuarios sean usuarios de Graph (es decir, usuarios activos del tenant accesibles vía Microsoft Graph API).
Esta incorporación automática reconstruye el equipo del proyecto sin intervención manual. No obstante, hay dos consideraciones de gobernanza que conviene revisar tras la ejecución:
- Los grupos nuevos se crean siempre como públicos. Si la política interna exige privacidad por defecto, debe modificarse manualmente la configuración del grupo después de la migración.
- Los grupos preexistentes mantienen su visibilidad previa. No hay alteración automática de su configuración por el hecho de recibir proyectos nuevos.
En carteras donde conviven proyectos confidenciales (por ejemplo, iniciativas financieras o de I+D) con proyectos operativos abiertos, esta revisión post-migración de la visibilidad de cada grupo es un paso obligatorio para mantener el modelo de gobernanza de información de la organización.
→ Descarga la Guía de Migración Project Online a Planner Premium (PDF gratuito).
Buenas prácticas antes, durante y después de la migración
Una migración bien preparada evita pérdidas de datos y reprocesos. Estas recomendaciones se organizan en tres fases secuenciales, alineadas con el ciclo operativo del proceso.
Antes de migrar: depurar portfolio, revisar límites y preparar mapeo
La fase previa es donde se decide la calidad final de la migración. Las acciones imprescindibles son:
- Depurar el portfolio: archivar proyectos cerrados y eliminar tareas obsoletas para no arrastrar datos innecesarios.
- Revisar los proyectos que superen los límites (3.000 tareas, jerarquías de más de 10 niveles, más de 150 recursos) y dividirlos o simplificarlos en origen.
- Dar de alta en el tenant de destino a todos los usuarios necesarios antes de iniciar el proceso.
- Recrear en destino los calendarios laborales equivalentes a los de origen.
- Verificar la configuración del entorno de Power Platform en modo «Duración fija».
- Preparar el mapeo de usuarios y recursos de origen a destino.
Esta fase exige también claridad sobre el modelo de gestión que se quiere reproducir en el nuevo entorno. Conviene apoyarse en una definición previa de roles de PMO y en una comprensión funcional del destino Planner Premium, para que el traslado responda al modelo deseado y no replique inercias del entorno anterior.
Durante la migración: token de API, estrategia de grupos y cuenta de conexión
Durante la ejecución, tres puntos concentran la mayor parte de incidencias técnicas:
- Generar el token de API para habilitar la migración de líneas base y de campos personalizados a nivel de tarea.
- Definir la estrategia de grupos de Microsoft 365 con criterio (crear nuevos, fusionar o reemplazar), evitando la opción destructiva salvo que sea intencional.
- Verificar que la cuenta de conexión es propietaria y miembro de los grupos de destino antes de iniciar el proceso.
Ejecutar la migración sin estos tres controles suele traducirse en reprocesos parciales o pérdida silenciosa de datos. El servicio de migración Project Online → Planner Premium de AIC contempla estos pasos como parte de la fase técnica del proyecto.
Después de migrar: validación de tareas, fechas y reconstrucción de buckets
La validación post-migración no es un trámite. Es la fase donde se detectan los ajustes manuales necesarios para que el entorno funcione operativamente. Las acciones de revisión clave son:
- Contrastar el número de tareas, fechas y asignaciones migradas frente al origen.
- Revisar las tareas sin fechas, las tareas de resumen recalculadas y las etiquetas.
- Reconstruir la estructura de buckets y de vistas según el modelo de gestión definido.
- Reconfigurar el reporting que dependía de Project Online sobre Power Platform y Power BI.
Preguntas frecuentes sobre la migración de Project Online a Planner Premium
¿Se migran los usuarios automáticamente?
No. Los usuarios deben existir previamente en el tenant de destino y mapearse manualmente a sus equivalentes en la herramienta de migración. Sin ese mapeo, sus asignaciones no se trasladan.
¿Cuántas tareas máximas admite un proyecto en Planner Premium?
3.000 tareas por proyecto. Las tareas que excedan ese número se omiten durante la migración. En proyectos que rocen el límite, conviene dividirlos en subproyectos enlazados antes del traslado.
¿Migran todas las líneas base de un proyecto?
No. Solo migra la línea base por defecto (sin sufijo numérico). Las líneas base adicionales (Baseline1, Baseline2…) no se trasladan. La migración requiere además un token de API generado al conectar con el entorno de Planner Premium.
¿Qué pasa con los calendarios laborales?
No se migran automáticamente. Deben recrearse manualmente en destino antes de iniciar el proceso, y aplicarse también a los recursos reservables asignados a las tareas.
¿Las tareas de resumen se migran tal cual?
No. Planner Premium las recalcula automáticamente a partir de sus subtareas. Las asignaciones aplicadas directamente sobre una tarea de resumen no se trasladan, y el esfuerzo total puede diferir respecto a Project Online.
¿Qué diferencia hay entre Planner básico y Planner Premium en este contexto?
Solo Planner Premium incorpora las funcionalidades necesarias para sustituir a Project Online (dependencias, líneas base, ruta crítica, Power Platform). El paso de plan básico a plan premium es un proceso independiente y previo a esta migración.
Próximos pasos: migrar con criterio antes del 30 de septiembre de 2026
La migración de Project Online a Planner Premium es la última oportunidad operativa para trasladar la información histórica de proyectos antes del cierre definitivo de la plataforma. Después de esa fecha, los datos dejan de estar accesibles.
Conocer en detalle qué se migra, qué se transforma y qué queda fuera del proceso es lo que permite planificar la ejecución con criterio. Permite anticipar dónde se concentrará el trabajo manual, qué proyectos requieren ajustes en origen y qué reconstrucciones serán necesarias en destino.
Para PMOs que utilizan Project Online como soporte central de su modelo operativo, la migración no es solo un cambio de herramienta. Es una transición que afecta al modelo de datos, al modelo de recursos y al modelo de reporting de la organización.
Según el PMI Pulse of the Profession 2025, solo el 18% de los profesionales de proyectos demuestra un nivel alto de visión estratégica de negocio — y ese grupo reduce en un 27% la tasa de fracaso de sus iniciativas. La migración de Project Online no es una excepción: quienes la abordan como un cambio de modelo operativo, no como un traslado técnico de datos, obtienen resultados sustancialmente distintos.
En AIC acompañamos a organizaciones de España y LATAM en este proceso, desde la auditoría previa hasta la validación post-migración, integrando la migración con la evolución del modelo de PMO sobre Microsoft 365.
Las modalidades de servicio disponibles pueden consultarse en la página de migración desde Project Online y en la oferta general de consultoría de gestión de proyectos.
Si tu organización todavía opera sobre Project Online y necesita evaluar el alcance, los riesgos y los plazos de su migración, solicita una sesión de diagnóstico con nuestro equipo.
