MSTech Geeks

Azure Migrate vs Dr Migrate es una comparación que puede aparecer fácilmente en proyectos de migración a Azure. Sobre todo cuando estamos en esas fases iniciales en las que todavía no está claro qué hay en el entorno, cuánto costaría llevarlo a Azure, qué cargas son candidatas a modernización y cuáles deberían migrarse de forma más conservadora.

Y aquí viene el primer matiz importante: no siempre estamos hablando de herramientas competidoras.

De hecho, después de trabajar con ambas, mi sensación es que Azure Migrate y Dr Migrate responden a preguntas diferentes dentro del mismo viaje de migración. Una está más cerca del assessment técnico y la ejecución. La otra ayuda mucho a acelerar la fase de descubrimiento, estrategia y business case.

Así que más que plantearlo como una pelea de herramientas, me gusta verlo como una conversación bastante más práctica:

¿En qué momento del proyecto estoy y qué pregunta necesito responder?

El problema real: migrar no empieza moviendo servidores

Muchas veces hablamos de migración a Azure como si el proyecto empezara cuando replicamos una máquina virtual o lanzamos un test migration.

Pero en la práctica, el trabajo empieza bastante antes.

Antes de mover nada necesitamos entender:

• Qué servidores existen.
• Qué aplicaciones dependen de ellos.
• Qué bases de datos están en alcance.
• Qué versiones de sistema operativo y SQL Server tenemos.
• Qué cargas están sobredimensionadas.
• Qué podemos modernizar.
• Qué no deberíamos tocar todavía.
• Qué impacto económico tendría cada decisión.

Y como podemos suponer, todo esto no es solo una conversación técnica. También es una conversación con negocio. Un perfil técnico podría pensar en: «Tengo 40 servidores y los puedo migrar a Azure», aunque esta afirmación es cierta, quizás haya que verlo desde otro punto de vista: «Tengo estas cargas, estas dependencias, estos riesgos, estas opciones de modernización y este impacto económico estimado». Aquí es donde herramientas como Azure Migrate y Dr Migrate pueden aportar valor, cada una desde un ángulo diferente.

¿Qué es Azure Migrate?

Azure Migrate es el servicio nativo de Microsoft para descubrir, evaluar y migrar cargas de trabajo hacia Azure.

Microsoft lo posiciona como un hub centralizado para proyectos de migración, permitiendo trabajar con servidores, bases de datos, aplicaciones web y otros escenarios dentro del ecosistema Azure. Su documentación oficial lo describe como una herramienta para descubrir, evaluar y migrar entornos on-premises hacia Azure.

En un proyecto real, Azure Migrate suele ser una pieza muy importante cuando necesitamos bajar al detalle técnico.

Por ejemplo:

• Discovery de servidores.
• Assessment de máquinas virtuales.
• Recomendaciones de right-sizing.
• Estimación de costes.
• Dependency Mapping.
• Evaluación de bases de datos SQL Server.
• Readiness hacia Azure SQL Database o Azure SQL Managed Instance.
• Migración de servidores.
• Seguimiento de replicación y cut-over.

Aquí es donde Azure Migrate brilla.

Cuando ya tenemos claro que una carga está en alcance y queremos entender si está preparada para Azure, qué tamaño debería tener, qué coste estimado tendría o qué bloqueos técnicos existen, Azure Migrate es una herramienta muy natural.

¿Qué es Dr Migrate?

Dr Migrate es una solución de Altra Cloud orientada a planificación, assessment y modernización cloud, especialmente enfocada en migraciones hacia Azure. En Microsoft Marketplace aparece como una solución de Altra y se describe como una plataforma construida sobre capacidades nativas de Azure Migrate, ejecutándose dentro del tenant cloud del cliente. Aunque también existe la posibilidad de usar la versión SaaS.

Y este punto es importante.

Dr Migrate no debería entenderse simplemente como “otro Azure Migrate”. Tampoco como una herramienta que sustituye directamente a Azure Migrate.

Más bien lo veo como una capa adicional que ayuda a convertir datos técnicos en información más accionable para la toma de decisiones.

Por ejemplo:

• Inventario rápido del entorno.
• Identificación de oportunidades de modernización.
• Recomendaciones de estrategia de migración.
• Análisis económico.
• Business case.
• Informes ejecutivos.
• Priorización de cargas.
• Visión orientada a stakeholders técnicos y no técnicos.

En otras palabras: Dr Migrate ayuda a contar mejor la historia de la migración.

Y esto en proyectos reales es bastante importante. Ya que muchas veces el problema no es solo saber si una VM puede moverse a Azure. El problema es justificar por qué moverla, cuándo moverla, cómo moverla y qué beneficios puede obtener el cliente.

Diferencia principal: técnica vs estratégica

Si tuviera que resumir la diferencia en una frase, diría esto: «Azure Migrate ayuda a validar y ejecutar la migración. Dr Migrate ayuda a entender, justificar y planificar mejor la migración.»

Azure Migrate se siente más técnico mientras que Dr. Migrate se siente más estratégico.

Azure Migrate responde muy bien a preguntas como:

• ¿Está preparada esta máquina para Azure?
• ¿Qué tamaño de VM recomienda?
• ¿Qué coste estimado tendría?
• ¿Qué dependencias tiene?
• ¿Puedo migrarla?
• ¿Puedo replicarla?
• ¿Puedo hacer un test migration?

Dr Migrate ayuda más con preguntas como:

• ¿Qué cargas debería priorizar?
• ¿Qué estrategia tiene más sentido?
• ¿Dónde hay oportunidades de ahorro?
• ¿Qué puedo modernizar?
• ¿Cómo presento esto a dirección?
• ¿Cuál podría ser el business case?
• ¿Qué quick wins puedo enseñar pronto?

Y para mí, esta es la clave del artículo.

No se trata de decidir cuál es mejor de forma absoluta. Se trata de saber qué pregunta estás intentando responder.

Comparativa rápida

Aspecto	Azure Migrate	Dr Migrate

Propietario

Microsoft

Altra Cloud

Enfoque principal

Assessment técnico y migración

Discovery, estrategia y business case

Momento natural de uso

Assessment detallado y ejecución

Fases iniciales y planificación

Migración de servidores

Sí

No es su foco principal

Readiness técnico

Muy fuerte

Útil como visión complementaria

Business case

Disponible, especialmente en assessments

Muy orientado a informes ejecutivos

Modernización

Sí, según workload

Muy orientado a oportunidades

Audiencia

Arquitectos, cloud engineers, equipos técnicos

Arquitectos, preventa, dirección, stakeholders

Valor diferencial

Integración nativa con Azure

Rapidez, análisis y narrativa ejecutiva

Una diferencia importante: la ventana de observación

Aunque ambas herramientas permiten analizar el entorno actual, existe una diferencia importante en la forma en la que recopilan la información.

En muchos escenarios, Dr Migrate realiza un descubrimiento y una recopilación de métricas durante una ventana temporal determinada, mediante su Dr Migrate Collector (DMC) generando una fotografía del entorno en el momento del assessment. Esta aproximación suele ser suficiente para obtener una visión global del estate, identificar oportunidades de modernización y construir un business case inicial.

Azure Migrate, por el contrario, puede recopilar métricas de rendimiento de forma continuada durante días o semanas. Esto permite observar patrones de consumo reales, picos de utilización, variaciones estacionales y comportamientos que podrían pasar desapercibidos en una captura puntual.

Dicho de otra forma, Dr Migrate ayuda a entender rápidamente el entorno, mientras que Azure Migrate permite afinar las decisiones técnicas basándose en datos observados durante un periodo más prolongado.

En mi experiencia, esta diferencia es especialmente relevante cuando hablamos de dimensionamiento. Un servidor que parece infrautilizado durante una captura puntual puede presentar picos significativos durante cierres mensuales, procesos batch o campañas de negocio. Cuanto más largo sea el periodo de observación, mayor confianza tendremos en las recomendaciones de right-sizing.

¿En qué fase usaría cada herramienta?

Tomando como punto de partida una división del proyecto en 5 fases.

1. Discovery inicial

En esta fase todavía estamos intentando entender el entorno.

Puede que el cliente tenga un inventario incompleto o que existan servidores que nadie tiene del todo controlados. Incluso que hayan bases de datos antiguas, aplicaciones heredadas o dependencias que no están documentadas.

Aquí Dr Migrate puede aportar mucho valor porque permite acelerar esa primera visión del estate.

También Azure Migrate puede entrar aquí, especialmente si vamos a desplegar appliances para descubrir servidores y dependencias.

Mi enfoque sería:

2. Business case

Esta es una fase crítica.

Aquí dejamos de hablar solo de servidores y empezamos a hablar de decisión.

¿Cuánto cuesta quedarnos como estamos?
¿Cuánto costaría movernos a Azure?
¿Qué pasa si hacemos lift and shift?
¿Y si modernizamos?
¿Qué savings podríamos conseguir con Azure Hybrid Benefit, Reserved Instances o right-sizing?

Dr Migrate encaja muy bien en esta fase porque está muy orientado a generar una historia entendible para negocio

Una vez completado el discovery, el siguiente paso suele ser construir un business case que permita responder si la migración tiene sentido desde un punto de vista económico. En este punto es donde herramientas como Dr Migrate aportan un valor diferencial, transformando métricas técnicas en información orientada a la toma de decisiones.

.

En el ejemplo mostrado, la plataforma analiza dos servidores SQL Server y estima un ahorro anual superior a los 9.000 € mediante una estrategia de modernización hacia Azure SQL Managed Instance con optimización de recursos y aprovechamiento de beneficios como Azure Hybrid Benefit.

3. Assessment técnico

En esta fase, Azure Migrate toma mucho protagonismo. Una vez completado el discovery y el business case, el siguiente paso es determinar qué destino técnico es el más adecuado para cada carga de trabajo. Aquí Azure Migrate comienza a aportar un nivel de detalle que normalmente no encontramos en herramientas orientadas a discovery o estrategia.

Ya no basta con tener una visión ejecutiva. Ahora necesitamos validar técnicamente cada workload.

Por ejemplo:

• Compatibilidad.
• Sizing.
• Dependencias.
• Sistema operativo.
• Versión de SQL Server.
• Requisitos de red.
• Requisitos de almacenamiento.
• Estimación de costes.
• Posibles bloqueos.

Microsoft indica que los assessments de Azure Migrate permiten evaluar workloads on-premises u otros clouds para su migración a Azure, incluyendo recomendaciones basadas en rendimiento o as-is.

4. Diseño y estrategia de migración

Esta es la parte donde las herramientas no sustituyen al arquitecto.

Y aquí hay que decirlo claro.

Una herramienta puede decirte que una base de datos tiene problemas para ir a Azure SQL Database. Pero alguien tiene que interpretar si eso implica:

• Corregir la aplicación.
• Ir a Azure SQL Managed Instance.
• Mantener SQL Server en Azure VM.
• Dividir la migración en fases.
• Modernizar más adelante.

Lo mismo con servidores.

Una herramienta puede recomendar un tamaño de VM, pero alguien tiene que revisar:

• Alta disponibilidad.
• Backup.
• Monitorización.
• Seguridad.
• Identidad.
• Redes.
• Private Endpoints.
• DNS.
• Modelo operativo.

Aquí tanto Azure Migrate como Dr Migrate aportan datos, pero la decisión final sigue siendo arquitectura.

5. Migración y optimización

Cuando llega el momento de migrar, Azure Migrate vuelve a ser protagonista.

Aquí hablamos de replicación, test migration, cut-over y seguimiento del estado de la migración.

Pero el trabajo no termina al apagar el servidor on-premises.

Después llega la optimización:

• Rightsizing real tras observar consumo.
• Azure Hybrid Benefit.
• Reserved Instances.
• Savings Plans.
• Revisión de almacenamiento.
• Monitorización de costes.
• Modernización progresiva.
• Revisión de seguridad.

Y aquí podemos volver a utilizar outputs del assessment inicial para comprobar si las hipótesis se cumplen.

Ejemplo práctico: SQL Server

SQL Server es probablemente uno de los mejores ejemplos para explicar por qué estas herramientas no deberían verse como rivales.

Imaginemos un entorno con varias bases de datos SQL Server heredadas.

Desde una visión inicial, Dr Migrate puede ayudarnos a entender:

• Qué servidores SQL existen.
• Qué bases de datos están en alcance.
• Qué coste estimado tendría moverlas.
• Qué oportunidades de modernización aparecen.
• Qué estrategia general podría tener sentido.

Pero cuando bajamos al detalle técnico, necesitamos saber mucho más.

Por ejemplo:

• ¿La base de datos puede ir a Azure SQL Database?
• ¿Tiene cross-database queries?
• ¿Usa SQL Server Agent?
• ¿Usa Service Broker?
• ¿Hay linked servers?
• ¿Hay dependencias externas?
• ¿La aplicación soporta el cambio?
• ¿Qué nivel de compatibilidad necesita?

Aquí Azure Migrate y los assessments de base de datos ayudan mucho a identificar readiness y posibles bloqueos.

Y este punto es clave: que una base de datos no esté lista para Azure SQL Database no significa que no pueda migrarse a Azure.

Puede significar que la mejor opción inicial sea:

• Azure SQL Managed Instance.
• SQL Server sobre Azure VM.
• Una modernización posterior.
• Una migración por fases.

Por eso, para mí, el output de la herramienta no es el final del análisis. Es el principio de una buena conversación de arquitectura.

Un posible flujo de trabajo combinado

Si tuviera que plantear un flujo práctico usando ambas herramientas, sería algo así:

1. Empezar con discovery inicial.
2. Usar Dr Migrate para generar visión ejecutiva, estrategia y business case.
3. Usar Azure Migrate para validar técnicamente servidores, bases de datos y dependencias.
4. Revisar los resultados con arquitectura.
5. Definir oleadas de migración.
6. Ejecutar migración con Azure Migrate cuando aplique.
7. Optimizar costes y modernizar después de la migración.

Errores habituales que evitaría

Pensar que la herramienta decide por ti

Ni Azure Migrate ni Dr Migrate sustituyen el criterio del arquitecto.

Ayudan, aceleran y ordenan información. Pero no diseñan por sí solas una landing zone, una estrategia de red, un modelo de seguridad o un plan de operación. Esto es solo una pieza del puzzle.

Quedarse solo con el coste mensual

El coste estimado es importante, pero no debería ser la única métrica.

También hay que revisar:

• Seguridad.
• Soporte.
• Obsolescencia.
• Dependencias.
• Riesgo operativo.
• Capacidad de modernización.
• Complejidad del cambio.

Confundir readiness con recomendación final

Que algo sea técnicamente posible no significa que sea la mejor opción.

Y que algo aparezca como no preparado para un destino concreto no significa que no tenga camino hacia Azure.

Conclusión

Azure Migrate y Dr Migrate no deberían verse únicamente como herramientas enfrentadas.

Azure Migrate es la herramienta nativa de Microsoft para assessment técnico y migración. Es clave cuando necesitamos validar compatibilidad, dimensionamiento, dependencias y ejecutar la migración.

Dr Migrate, por su parte, aporta una capa adicional de análisis, estrategia y business case que puede ser muy útil en fases iniciales, especialmente cuando necesitamos convertir datos técnicos en una historia clara para tomar decisiones.

Mi recomendación sería no plantearlo como “una u otra”, sino como “qué necesito responder ahora”.

Si necesito justificar, priorizar y construir una estrategia, Dr Migrate puede aportar mucho valor.

Si necesito validar técnicamente y ejecutar, Azure Migrate es fundamental.

Y si el proyecto tiene cierta complejidad, probablemente ambas herramientas tengan sitio.

Porque una migración a Azure no empieza cuando movemos servidores. Empieza cuando entendemos bien qué tenemos, qué queremos conseguir y qué camino tiene más sentido.