La peor migración es la que consigue replicar perfectamente todos los problemas del CRM anterior.
Microsoft recomienda tratar la migración de datos como una disciplina del proyecto: descubrir fuentes y volúmenes, definir alcance y estrategia, mapear y transformar información, probar cargas y validar la calidad antes del go-live. Esa lógica debería aplicarse también a procesos, integraciones, seguridad y experiencia de usuario. No todo lo que existe merece sobrevivir a la transición.
Lo que sigue aportando valor
Datos, reglas, procesos y capacidades que responden a una necesidad vigente y funcionan bien. Puede cambiar su implementación, pero no la razón de negocio que representan.
Lo que resuelve bien el problema, pero mal la forma
Workflows antiguos, desarrollos complejos, pantallas sobrecargadas o integraciones frágiles pueden responder a una necesidad real que hoy se resuelve mejor con estándar, Dataverse o Power Platform.
Lo que debe seguir accesible sin vivir en el CRM nuevo
Históricos de consulta, actividades antiguas o información regulatoria pueden mantenerse en una capa de consulta sin cargar el modelo operativo diario.
Lo que sobrevive por inercia
Campos sin uso, automatizaciones duplicadas, informes que nadie consulta, estados heredados, integraciones abandonadas y reglas creadas para limitaciones que ya no existen.
El cambio de enfoque es sencillo: en vez de preguntar “¿cómo migramos todo?”, pregunta “¿qué necesita el negocio en Dynamics 365 y qué parte del sistema actual merece llegar hasta allí?”.
El mayor riesgo no está solo en los datos. Está en todo lo que el CRM ha ido acumulando alrededor.
Campos que nadie entiende, automatizaciones duplicadas, informes paralelos, integraciones punto a punto, permisos heredados y desarrollos que solo conoce una persona pueden convertir una migración aparentemente sencilla en un proyecto difícil de estimar.
Datos sin dueño
Duplicados, registros obsoletos, valores libres y campos inconsistentes afectan reporting, segmentación, automatización y cualquier capacidad futura de IA.
Procesos convertidos en costumbre
Aprobaciones, estados y excepciones pueden haber nacido por limitaciones antiguas. Migrarlas literalmente puede bloquear la oportunidad de simplificar.
Integraciones sin mapa
ERP, web, marketing, telefonía, BI y aplicaciones internas pueden intercambiar datos con el CRM sin documentación completa. Cada dependencia olvidada reaparece durante pruebas o go-live.
Personalización por defecto
Cuando cada necesidad histórica se resolvió con código, la migración debe separar requisitos reales de soluciones heredadas que hoy pueden sustituirse por estándar o Power Platform.
Ocho áreas que conviene analizar antes de estimar una migración a Dynamics 365.
El número de usuarios no basta para estimar esfuerzo. La complejidad real aparece en datos, código, seguridad, integraciones, reporting, uso y expectativas de transformación. Un assessment serio convierte ese punto de partida en decisiones de alcance y riesgo.
Procesos y objetivos de negocio
Qué procesos comerciales y de servicio funcionan, cuáles generan fricción y qué resultado se espera mejorar. No tiene sentido migrar con precisión un proceso que el propio proyecto pretende cambiar.
Modelo y calidad de datos
Tablas, campos, relaciones, duplicidades, históricos, propietarios, formatos, adjuntos y calidad real. Microsoft recomienda definir alcance, transformación, secuencias y validación como parte formal de la estrategia de migración.
Personalizaciones y código
Plugins, workflows, JavaScript, formularios, reglas y componentes. Cada pieza debe clasificarse: conservar, sustituir por estándar, trasladar a Power Platform o retirar.
Integraciones y sistemas maestros
ERP, ecommerce, marketing, telefonía, identidad, web, datos maestros, BI y aplicaciones internas. Hay que saber qué sistema manda, qué frecuencia necesita cada flujo y qué integraciones deberían modernizarse.
Seguridad y ownership
Roles, equipos, unidades de negocio, jerarquías, propietarios y excepciones. Copiar un modelo de seguridad antiguo sin revisarlo puede perpetuar accesos innecesarios y una administración difícil.
Reporting y analítica
Informes nativos, Power BI, Excel, extractos, modelos semánticos y dashboards. Cambiar el modelo de datos puede romper reporting aunque la interfaz CRM funcione correctamente.
Uso y adopción reales
Qué equipos utilizan el CRM, dónde vuelven a Excel, qué campos rellenan tarde y qué procesos ocurren fuera. La adopción revela si el problema está en tecnología, diseño, gobierno o valor percibido.
Cutover y continuidad
Congelación de datos, ventana de cambio, cargas finales, activación de integraciones, validación, rollback, soporte intensivo y convivencia temporal. Debe diseñarse desde el proyecto, no al final.
La página comercial explica el servicio. Este post prepara la decisión.
Si el punto de partida es Dynamics CRM o Dynamics 365 Customer Engagement on-premise, revisa la propuesta de migración de CRM a Dynamics 365 Cloud.
Migrar todo el histórico suele ser una decisión emocional, no necesariamente una decisión útil.
“Por si algún día hace falta” parece prudente, pero cada dato histórico añade extracción, transformación, validación, tiempo de carga, almacenamiento y riesgo. La decisión debe basarse en uso, regulación, necesidad operativa y valor para el usuario.
Activos
Clientes, contactos, oportunidades, casos y registros necesarios para operar desde el primer día.
Maestros
Información de referencia que debe llegar limpia, con ownership y reglas claras.
Histórico útil
Información que aporta contexto real al usuario o soporta reporting, regulación o servicio.
Prescindible
Pruebas, duplicados, leads sin valor, campos nunca usados y actividad que no aporta contexto.
Un CRM nuevo con datos malos sigue tomando decisiones sobre una base mala.
Calidad y consistencia afectan segmentación, asignación comercial, reporting, automatización, deduplicación, servicio y cualquier capacidad futura de Copilot. Migrar sin limpiar puede acelerar el problema porque la nueva plataforma automatiza más sobre una base que sigue siendo inconsistente.
No todas las migraciones deberían seguir la misma estrategia.
La mejor ruta depende de deuda técnica, urgencia, criticidad, capacidad de cambio y cuánto se pretende transformar el proceso. Elegir la estrategia antes de conocer el sistema suele producir alcance inestable y discusiones de presupuesto.
Migrar y optimizar
Adecuada cuando el modelo actual es razonablemente sano. Se conserva gran parte de la lógica, se limpia el dato, se reducen personalizaciones innecesarias y se aprovecha el estándar de Dynamics 365.
Ventaja: transición más directa. Riesgo: conservar deuda por exceso de prudencia.
Reimplantar con criterio
Encaja cuando existen años de personalización, baja adopción o procesos obsoletos. Se conserva la necesidad de negocio, pero se rediseña cómo resolverla en Dynamics 365, Dataverse y Power Platform.
Ventaja: reduce deuda. Riesgo: requiere más implicación de negocio.
Transición por fases
Tiene sentido cuando hay países, unidades de negocio, integraciones o procesos con ritmos distintos. Reduce el riesgo del big bang, pero exige diseñar convivencia, sincronización y ownership temporal.
Ventaja: menor impacto puntual. Riesgo: prolongar la complejidad si la convivencia no tiene fecha de salida.
Migrar el CRM sin revisar cómo se conecta con ERP, datos y productividad es resolver solo media arquitectura.
En muchas empresas el CRM no es el sistema maestro de todo. ERP controla clientes financieros, productos, pedidos, facturación o riesgo. Microsoft 365 contiene conversaciones y documentos. Power BI consolida información para dirección. La migración debe decidir qué dato vive dónde y cómo circula.
Ayesa trabaja esta visión conectada entre ERP, CRM y Power Platform sobre Microsoft porque el valor aparece cuando ventas, servicio y operación comparten contexto sin duplicar ownership.
¿Quién crea el cliente?
CRM, ERP, MDM u otro sistema. Debe existir una fuente de verdad y una regla de validación.
¿Qué vuelve a ventas?
Pedidos, facturación, deuda, contratos o incidencias pueden cambiar la prioridad comercial.
¿Qué se sincroniza?
No todo dato debe duplicarse. Algunas necesidades se resuelven mejor mediante consulta o integración de procesos.
¿Qué ocurre si falla?
Reintentos, trazabilidad, alertas, colas y ownership deben estar diseñados desde el principio.
Seis fases claras. Ninguna debería dejar grandes decisiones para la semana del go-live.
Microsoft recomienda integrar pruebas y migración de datos en el ciclo del proyecto y ensayar el cutover antes de producción. La secuencia debe ser repetible, medible y conocida por negocio y tecnología.
Evaluación y estrategia
Inventario, riesgos, modelo futuro, alcance, datos, integraciones, seguridad, licencias y elección entre migración, reimplantación o transición por fases.
Diseño de solución
Tablas, procesos, formularios, seguridad, integraciones, reporting, entornos y automatización. Se define cómo debería funcionar el CRM nuevo.
Remediación y construcción
Retirada de deuda, configuración, desarrollo imprescindible, integración y preparación de mecanismos de migración y reconciliación.
Migraciones de ensayo
Extracción, transformación, carga, tiempos, errores, relaciones, ownership y validación. Microsoft recomienda probar la migración varias veces antes del cutover.
Pruebas y adopción
SIT, UAT, seguridad, reporting, integraciones, procesos end-to-end, rendimiento y formación con usuarios clave sobre datos suficientemente realistas.
Cutover y estabilización
Congelación, carga final, activación de integraciones, validación, apertura, soporte intensivo, seguimiento y retirada controlada del sistema anterior.
El go-live no debería ser el primer ensayo completo de la migración.
Microsoft recomienda completar y aprobar pruebas de integración, aceptación y rendimiento, preparar el plan de migración de datos y firmar el plan de cutover antes de producción. También recomienda ejecutar migraciones de prueba varias veces y comprobar que caben dentro de la ventana real.
Migración ensayada
El proceso completo se ha ejecutado con datos realistas, tiempos medidos y errores conocidos.
Pruebas cerradas
SIT, UAT, rendimiento, seguridad, reporting e integraciones tienen criterios de salida y aprobación de negocio.
Datos reconciliados
Volúmenes, relaciones, propietarios, registros críticos y estados se validan antes de abrir el sistema.
Soporte activado
Incidencias priorizadas, responsables identificados, escalados operativos y comunicación preparada para los primeros días.
Una regla útil: si el equipo no puede repetir el proceso completo, medir cuánto tarda y saber quién valida cada parte, todavía no existe un cutover controlado.
El mejor diseño técnico fracasa si los usuarios vuelven a Excel la semana siguiente.
La migración cambia pantallas, hábitos, responsabilidades y secuencias de trabajo. La adopción debe formar parte del diseño: usuarios clave, formación, comunicación y feedback real antes del go-live.
Si el CRM actual se percibe como un sistema de control administrativo, replicar la misma experiencia sobre Dynamics 365 no cambia la relación del usuario con la herramienta.
La migración debería resolver comportamientos que hoy están fuera del sistema.
La complejidad de una migración no se explica con una sola cifra.
Dos organizaciones con el mismo número de usuarios pueden tener proyectos completamente distintos. El esfuerzo crece por la combinación de volumen, relaciones, personalización, integraciones, seguridad, reporting, regiones, cambio de proceso y restricciones de cutover.
Datos acotados y procesos cercanos al estándar
Pocas tablas relevantes, relaciones sencillas, personalización limitada, integraciones controladas y usuarios alineados con procesos estándar.
Qué vigilar: no crear complejidad nueva por intentar reproducir hábitos históricos que ya no aportan valor.
Relaciones, automatización e integración relevantes
Más tablas, transformaciones, seguridad, reporting, varias integraciones y procesos que requieren rediseño funcional.
Qué vigilar: secuencias de carga, calidad, históricos, observabilidad de integraciones, pruebas repetibles y adopción.
CRM convertido en plataforma crítica
Muchos años de histórico, regiones, unidades de negocio, código, portales, telefonía, integraciones, altos volúmenes, seguridad compleja o ventanas de indisponibilidad muy reducidas.
Qué vigilar: estrategia por fases, staging, automatización de cargas, pruebas de rendimiento, reconciliación y mock cutover.
Copilot y los agentes no arreglan un modelo de datos que nadie entiende.
La migración crea una oportunidad para preparar cuentas, contactos, actividades, oportunidades, casos, permisos y conocimiento con más consistencia. Esa calidad importa mucho más cuando la organización quiere incorporar IA y automatización.
Esto conecta con la visión de CRM B2B con IA sobre Dynamics 365. La migración no necesita desplegar todos los casos desde el primer día, pero sí debe evitar decisiones que dificulten incorporarlos después.
Cinco bases para evolucionar después del go-live.
Una evaluación previa útil termina en decisiones y entregables concretos, no en una lista interminable de hallazgos.
El assessment no debería limitarse a documentar el CRM actual. Su valor aparece cuando convierte el estado de partida en una ruta ejecutable: qué migrar, qué retirar, qué riesgos pueden alterar plazo o presupuesto, qué dependencias hay que resolver antes y qué decisiones necesita negocio para que la transición no reproduzca la deuda existente.
Mapa del sistema actual
Aplicaciones, módulos, integraciones, fuentes de datos, automatizaciones, reporting, perfiles, portales y dependencias críticas. No hace falta describir cada detalle técnico, pero sí localizar dónde puede aparecer complejidad.
Inventario de deuda
Campos sin uso, procesos duplicados, código obsoleto, integraciones frágiles, roles difíciles de mantener, tareas manuales, reporting paralelo y cualquier componente que no debería trasladarse por defecto.
Clasificación de datos
Datos maestros, operativos, históricos y prescindibles; calidad, volumen, retención, ownership y transformación necesaria. El objetivo es migrar con criterio, no convertir cada registro heredado en un requisito.
Decisiones de arquitectura
Qué se resuelve con estándar Dynamics 365, qué necesita Power Platform, qué integraciones deben modernizarse, dónde residirá cada dato y qué componentes deben permanecer fuera del core.
Ruta de migración
Big bang, fases, convivencia, piloto, países, unidades o procesos. La ruta debe reflejar riesgo y dependencia, no solo conveniencia de calendario.
Backlog priorizado
Requisitos imprescindibles para go-live, mejoras que pueden entrar después y capacidades futuras. Separar “must have” de “sería interesante” protege plazo y presupuesto.
Un assessment responsable también explicita lo que todavía no se sabe. Si faltan inventarios, documentación, acceso a código, estadísticas de uso u owners, esa incertidumbre debe quedar visible antes de comprometer alcance.
Los datos no son responsabilidad exclusiva de IT y el cutover no es responsabilidad exclusiva del partner.
Una migración se atasca cuando nadie sabe quién decide qué. El equipo técnico puede transformar un campo; negocio debe confirmar qué significa. El arquitecto puede diseñar la secuencia de carga; el owner funcional debe validar si el resultado es correcto. El éxito exige responsabilidades explícitas.
Define significado y prioridad
Confirma procesos, reglas, datos críticos, históricos necesarios, criterios de aceptación y qué cambios son realmente prioritarios.
Gobierna calidad y reconciliación
Define reglas de limpieza, transformación, ownership, validación y evidencias que demostrarán que el dato migrado es correcto.
Diseña solución y dependencias
Arquitectura, integraciones, seguridad, entornos, automatización, rendimiento y mecanismos de migración deben estar coordinados con las decisiones funcionales.
Protege alcance y go/no-go
Mantiene dependencias, decisiones, riesgos, fechas, responsables, criterios de entrada y salida y condiciones objetivas para decidir si el go-live es seguro.
Las preguntas pequeñas suelen bloquear proyectos grandes: ¿qué cuenta es la correcta?, ¿qué estado sigue vigente?, ¿qué histórico debe conservarse?, ¿quién será propietario?, ¿qué dato manda cuando ERP y CRM no coinciden? Sin owner, ninguna herramienta de migración resuelve esas decisiones.
El éxito no es que Dynamics 365 arranque el lunes. Es que la organización trabaje mejor después.
El proyecto necesita indicadores posteriores al go-live. Si solo se mide fecha, presupuesto y número de incidencias, podemos declarar éxito aunque los usuarios sigan utilizando hojas paralelas, la calidad de datos no haya mejorado o el CRM continúe sin aportar valor al negocio.
Menos trabajo fuera del CRM
Forecast, actividad, seguimiento y servicio deberían depender menos de Excel, correos paralelos o bases personales. El sistema debe convertirse en parte natural del trabajo.
Más confianza en datos y reporting
Menos duplicados, mejor ownership, definiciones compartidas y reporting consistente deberían traducirse en menos discusiones sobre cuál es la cifra correcta.
Menos fricción para cambiar
El nuevo CRM debería poder incorporar automatización, Power Platform, analítica y futuras capacidades de Copilot sin volver a convertir cada necesidad en un proyecto de alta personalización.
Si el roadmap incluye Copilot, conviene preparar desde ahora permisos, información y conocimiento. La página de Microsoft 365 Copilot para empresas explica por qué la calidad del contexto y el gobierno de acceso importan tanto como la licencia.
Una migración CRM cruza negocio, datos, integración, Power Platform, Microsoft 365, analítica, seguridad y adopción.
El riesgo de la transición no se reduce únicamente con más desarrollo. Se reduce entendiendo mejor procesos, diseñando el dato futuro, identificando dependencias, limitando personalización innecesaria y construyendo una arquitectura que pueda mantenerse y evolucionar después del go-live.
Ayesa reúne capacidades en Dynamics 365, Power Platform, Azure, datos, seguridad y Modern Work. Puedes revisar las designaciones, especializaciones y certificaciones Microsoft de Ayesa.
Ocho decisiones que encarecen la migración antes de empezar.
1. Estimar solo por usuarios
El esfuerzo depende de datos, personalización, integraciones, reporting, seguridad y cambio de proceso, no únicamente del número de licencias.
2. Decidir que “se migra todo”
Elimina la conversación sobre calidad y valor y convierte cada registro histórico en un requisito técnico aunque nadie lo utilice.
3. Diseñar sin usuarios clave
El equipo puede reproducir perfectamente un proceso que negocio lleva años evitando porque no le resulta útil.
4. Descubrir integraciones durante las pruebas
Cada interfaz no identificada puede alterar alcance, seguridad, sincronización, datos maestros y ventana de cutover.
5. Tratar limpieza como tarea de IT
IT puede detectar formatos y duplicados; solo negocio puede decidir qué dato sigue teniendo significado.
6. Probar solo la carga
La validación debe cubrir proceso, reporting, integraciones, permisos y operación diaria, no únicamente que el registro exista.
7. Posponer adopción
Si los usuarios conocen el proceso al final, la organización descubre demasiado tarde fricciones que deberían haberse resuelto durante el diseño.
8. Confundir migración con modernización
Mover al cloud no garantiza un CRM mejor. El valor aparece cuando datos, procesos, experiencia e integración también evolucionan.
Hay decisiones que no debería tomar el equipo técnico en solitario.
Cuando el proyecto entra en la recta final, la presión por cumplir la fecha puede convertir riesgos conocidos en supuestos. Dirección necesita una visión sencilla: qué queda abierto, qué impacto puede tener, qué mitigación existe y qué condición haría recomendable retrasar el go-live. Un comité de decisión útil no revisa cientos de tareas; revisa riesgos que pueden afectar operación, cliente, ingresos o cumplimiento.
Qué problemas aceptamos temporalmente
No todo defecto debe bloquear producción, pero cada excepción aceptada necesita owner, impacto conocido y fecha de resolución. “Lo veremos después” no es un plan.
Qué datos deben estar perfectos desde el primer día
No todas las tablas tienen el mismo impacto. Clientes, oportunidades abiertas, casos activos, contratos, permisos o datos necesarios para facturación y servicio pueden requerir tolerancias mucho más bajas.
Cuál es el punto de no retorno
El rollback debe tener una ventana realista y condiciones claras. Una vez que usuarios, integraciones y nuevos datos empiezan a operar en producción, volver atrás puede ser mucho más complejo que retrasar unas horas.
Qué demostraría que el proyecto necesita más tiempo
Migraciones que no caben en la ventana, integraciones críticas inestables, UAT sin cierre, reconciliaciones sin explicar o ausencia de soporte preparado son señales objetivas. La fecha debe servir al negocio, no al revés.
Dudas habituales antes de preparar una migración CRM a Dynamics 365.
¿Hay que migrar todos los datos?
No necesariamente. Microsoft recomienda migrar información relevante y útil. La decisión debe considerar uso operativo, regulación, reporting, valor para el usuario y coste de transformación y validación.
¿Qué importa más: volumen o complejidad?
Ambos. El volumen afecta tiempos y herramientas; relaciones, transformaciones, personalizaciones e integraciones pueden elevar mucho la complejidad incluso con menos registros.
¿Se puede migrar por fases?
Sí. Puede tener sentido por países, unidades, procesos o colectivos. La convivencia temporal necesita diseño para evitar duplicidades, conflictos de ownership y sincronizaciones difíciles.
¿Cuándo conviene reimplantar?
Cuando el sistema actual acumula mucha personalización, baja adopción, procesos obsoletos o deuda técnica y la organización quiere aprovechar estándar y Power Platform.
¿Qué papel tiene Dataverse?
Es la plataforma de datos que utilizan muchas aplicaciones de Dynamics 365 y Power Platform. Relaciones, seguridad y ownership deben diseñarse con criterio para que la solución evolucione bien.
¿Hay que limpiar antes o después?
Las reglas y decisiones deben definirse antes. Es más eficiente transformar y validar durante la migración que cargar datos defectuosos y empezar un proyecto de limpieza ya en producción.
¿Cómo se reduce el riesgo del go-live?
Con cargas repetibles, reconciliación, pruebas end-to-end, UAT, mock cutover, criterios de aceptación, rollback, owners claros y soporte intensivo.
¿La migración debería preparar el CRM para IA?
Sí, aunque la IA no forme parte del alcance inicial. Calidad de datos, relaciones, permisos, conocimiento e integración condicionan el valor futuro de Copilot y agentes.
Profundiza según la decisión que tengas delante.
Migración CRM a Dynamics 365 Cloud
Servicio para revisar versión, datos, personalizaciones, integraciones, seguridad y ruta de transición.
Dynamics 365 Sales
Pipeline, forecast, actividad comercial y productividad para diseñar el proceso futuro más allá de la migración.
Power Platform
Apps, automatización, Dataverse y extensiones gobernadas para evitar volver a cargar el core del CRM.
CRM + IA con Microsoft
Ventas, servicio, automatización y contexto de cliente conectados con Copilot y el resto del ecosistema.
ERP + CRM + Power Platform
Arquitectura para conectar procesos, datos, automatización e IA sin multiplicar silos.
CRM B2B con IA
Cómo preparar ventas B2B para más contexto, mejores señales, automatización, Copilot y agentes.
Microsoft recomienda planificar la migración, probarla varias veces y validar el cutover con negocio.
La guía Success by Design de Dynamics 365 trata migración de datos, pruebas y preparación para go-live como actividades integradas en el proyecto. Recomienda definir estrategia, roles, secuencias, pruebas en entornos adecuados, validación de calidad y un mock cutover antes de producción.
Migrar bien no es trasladar más. Es llegar a Dynamics 365 con menos deuda y más capacidad de evolucionar.
Una migración debería dejar un CRM más claro, más adoptable, mejor integrado y más gobernable que el anterior. Si después del cambio siguen los mismos campos innecesarios, las mismas hojas paralelas, las mismas integraciones frágiles y las mismas excepciones, habremos cambiado de plataforma sin resolver el problema.
También debería dejar una organización capaz de cambiar con menos fricción. El valor de Dynamics 365 no termina en el go-live: continúa cuando ventas, servicio, datos, Power Platform y Copilot pueden evolucionar sin reconstruir el CRM cada vez que aparece una nueva necesidad. Ese es el verdadero criterio para saber si la migración fue una modernización o solo un traslado.
La estimación debería empezar por un assessment, no por una cifra cerrada.
Podemos revisar procesos, datos, personalizaciones, integraciones, seguridad, reporting, adopción y estrategia de cutover para identificar qué conviene migrar, qué rediseñar y qué retirar.
¿Quieres saber qué complejidad real tiene tu migración a Dynamics 365 antes de comprometer alcance y presupuesto?
Cuéntanos qué CRM utilizas, qué procesos soporta, cuántos años de histórico acumula, qué integraciones existen y qué quieres mejorar. La primera conversación debe servir para entender el problema antes de decidir la solución.
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)