Hay una conversación que se repite en casi todas las revisiones de arquitectura de datos que Algoritmia hace con clientes. El CIO o el director de IT sabe que el data warehouse actual tiene los días contados: tecnología de hace una década, costes de mantenimiento crecientes, incapacidad para escalar con los volúmenes actuales y una deuda técnica que se acumula cada trimestre. También sabe que debería migrar a una plataforma moderna. Y aun así, el proyecto no arranca.
El motivo no es falta de presupuesto ni falta de voluntad. Es miedo a la complejidad. Un proyecto de migración de data warehouse convencional implica meses de análisis de dependencias, reescritura manual de queries y procedimientos almacenados, testing exhaustivo y un período de marcha paralela que consume recursos que nadie tiene disponibles. El resultado es que el proyecto se pospone hasta que el sistema legacy falla de una forma que ya no tiene solución.
El Migration Assistant de Microsoft Fabric, disponible con carácter general y con mejoras continuas incorporadas, está diseñado para romper exactamente ese ciclo.
Qué hace el Migration Assistant y qué no hace
La función central del Migration Assistant es el análisis automatizado del warehouse existente y la conversión asistida por IA de su lógica de negocio al entorno de Microsoft Fabric. El proceso comienza con un escaneo del sistema de origen (compatible con SQL Server, Azure Synapse Analytics, Amazon Redshift, Snowflake y otros sistemas principales) que genera un inventario completo de tablas, vistas, procedimientos almacenados, dependencias y patrones de uso.
A partir de ese inventario, el asistente clasifica cada objeto según su complejidad de migración: objetos que se pueden convertir automáticamente sin intervención, objetos que requieren revisión pero tienen una propuesta de conversión clara, y objetos que necesitan reescritura manual porque su lógica es demasiado específica para traducirse de forma fiable. Esta clasificación es el primer output real del proceso, y ya tiene valor antes de haber movido ningún dato: por primera vez, el equipo tiene una imagen honesta de lo que implica la migración.
Lo que el Migration Assistant no hace es eliminar completamente el trabajo humano. Los objetos de alta complejidad siguen requiriendo criterio técnico. La validación de los resultados de negocio no se puede automatizar: alguien tiene que confirmar que los números en el nuevo sistema coinciden con los del sistema origen. Y la gestión del cambio en los equipos que consumen los datos tampoco es algo que ninguna herramienta resuelve por sí sola.
Las mejoras de diciembre de 2025: qué cambió
La versión inicial de GA de julio de 2025 ya era funcional, pero tenía limitaciones relevantes en la cobertura de dialectos SQL específicos y en la capacidad de gestionar procedimientos almacenados de alta complejidad. La actualización de diciembre amplió la cobertura de T-SQL (especialmente construcciones complejas con CTEs anidados y lógica de ventanas), mejoró la interfaz de revisión de código convertido (ahora muestra el original y la conversión lado a lado con anotaciones sobre los cambios) y añadió soporte para migraciones incrementales, lo que permite mover el warehouse por fases en lugar de hacer un cutover completo.
Esta última capacidad es especialmente relevante para organizaciones con sistemas en producción que no pueden permitirse una ventana de migración amplia. La migración por fases reduce el riesgo operativo de forma significativa: se empieza por los dominios de datos menos críticos, se valida el proceso, y se avanza hacia los núcleos de negocio cuando el equipo tiene confianza en el resultado.
Cómo se estructura un proyecto de migración real
Un proyecto típico con el Migration Assistant sigue cuatro fases. La primera es el assessment: el asistente escanea el sistema origen y entrega el inventario de objetos con su clasificación de complejidad. Esta fase suele completarse en días, no semanas. La segunda es la conversión asistida: los objetos automáticos se migran directamente, los objetos con propuesta de conversión se revisan y aprueban en la interfaz del asistente, y los objetos complejos se gestionan con el equipo técnico. La tercera es la validación de negocio: los equipos que consumen los datos (analistas, controllers, equipos de operaciones) verifican que los informes y dashboards producen los mismos resultados en el nuevo entorno. La cuarta es el cutover y el desmantelamiento progresivo del sistema origen.
El horizonte temporal depende del tamaño y la complejidad del warehouse. Para warehouses medianos (hasta 500 objetos, lógica de negocio moderada), el tiempo total se sitúa habitualmente entre 6 y 12 semanas. Para sistemas de mayor complejidad, el rango se amplía, pero sigue siendo significativamente inferior al proyecto de 18 meses que la mayoría de los directores de IT tienen en mente cuando piensan en una migración.
Microsoft Fabric como destino: por qué ahora
La elección de Fabric como plataforma de destino no es neutral. Microsoft ha apostado por Fabric como la plataforma de datos unificada que reemplaza a Azure Synapse, integra Power BI de forma nativa y consolida en un único entorno las capacidades de ingesta, almacenamiento, procesamiento y visualización de datos.
Para organizaciones que ya usan Power BI como herramienta de reporting, la migración a Fabric supone adicionalmente una simplificación arquitectónica: el warehouse y los informes viven en el mismo entorno, la latencia entre el dato y el informe se reduce, y la gestión de permisos y gobernanza se centraliza. Para organizaciones que todavía no han adoptado Power BI, Fabric ofrece un punto de entrada moderno que evita construir sobre tecnología que Microsoft ya está deprecando.
El riesgo de esperar no es solo el coste creciente del sistema legacy. Es que cada año que pasa, la brecha entre las capacidades analíticas que tienen y las que tiene la competencia se amplía.
Cuándo tiene sentido y cuándo no
El Migration Assistant es la herramienta adecuada cuando el sistema origen es SQL Server, Azure Synapse u otro de los sistemas compatibles, cuando el warehouse tiene una deuda técnica visible pero la lógica de negocio está documentada (aunque sea en el código), y cuando la organización tiene equipo técnico disponible para validar los resultados.
No es la herramienta adecuada cuando el warehouse está tan mal documentado que ni el equipo actual sabe qué hace la mitad de los procedimientos almacenados, cuando los datos de origen tienen problemas de calidad que la migración no va a resolver (cambiar de plataforma no limpia datos sucios), o cuando la organización no tiene capacidad para gestionar el cambio en los equipos consumidores. En esos casos, el problema a resolver no es técnico: es previo a cualquier herramienta de migración.
La conversación correcta no empieza con «¿cuándo migramos?» sino con «¿qué queremos que el sistema de datos nuevo nos permita hacer que el actual no nos permite?». Si la respuesta es concreta y tiene valor de negocio, el Migration Assistant es la vía más corta para llegar allí.
Preguntas frecuentes
¿El Migration Assistant requiere licencia especial de Microsoft Fabric?
El Migration Assistant está disponible dentro del entorno de Microsoft Fabric. Requiere una capacidad de Fabric activa (F SKU o equivalente). Para proyectos de migración, es habitual arrancar con una capacidad temporal de evaluación y escalar una vez validado el entorno de destino.
¿Qué sistemas de origen son compatibles?
La lista actual incluye SQL Server (on-premises y Azure SQL Database), Azure Synapse Analytics, Amazon Redshift y Snowflake como sistemas principales. La compatibilidad se amplía con cada actualización. Verificar la documentación oficial de Microsoft Fabric para la lista actualizada antes de iniciar el assessment.
¿Qué pasa con los informes de Power BI conectados al warehouse actual?
La migración del warehouse a Fabric simplifica la reconexión de los informes de Power BI: al estar en el mismo entorno, la actualización de las fuentes de datos es directa en la mayoría de los casos. Los informes con consultas directas al warehouse (DirectQuery) requieren revisión específica, pero es un proceso sistemático y bien documentado.