Observaciones acumuladas tras +50 migraciones a Dynamics 365 desde Navision, Business Central, Axapta/F&O, Salesforce, HubSpot, Microsoft Access y Excel. Cada patrón es un error frecuente que hemos visto multiplicar el coste del proyecto o una decisión crítica que separa una migración limpia de un incendio silencioso.
Cada patrón lleva su etiqueta: riesgo (error frecuente que compromete el proyecto), decisión (punto donde hay que elegir y no da igual) o regla (buena práctica que ahorra semanas de trabajo).
Se planifica como una tarea técnica de la última semana. En realidad, condiciona el arranque del sistema, la confianza del usuario y el ROI del primer trimestre. Un CRM con datos malos genera rechazo instantáneo y ese rechazo dura años.
⚠ RiesgoNo hay ETL que arregle un origen sucio. Antes de mapear campos, hay que auditar el dato: cuántos duplicados hay, cuántos registros están incompletos, cuántos son inconsistentes. Ese diagnóstico determina si el proyecto es viable en 4 semanas o requiere 4 meses.
✓ ReglaPretender que Dynamics 365 "detecte los duplicados por nosotros después de la migración" es la fuente número uno de bases de datos irrecuperables. Las reglas de deduplicación se definen en el mapeo, se ejecutan en el ETL, y se validan antes de mover a producción.
⚠ RiesgoEl impulso de "vamos a llevarlo todo por si acaso" es exactamente lo que colapsa el CRM nuevo. Regla práctica: dato activo con menos de 24 meses de actividad va como registro operativo; el resto va como archivo consultable pero fuera del flujo diario.
◇ DecisiónEl error más habitual: replicar en Dynamics la estructura de tablas del sistema anterior. Resultado: un CRM con 80 campos que nadie sabe para qué sirven. El diseño del modelo se hace desde el proceso de negocio TO-BE, no desde el AS-IS del sistema viejo.
✓ ReglaMigrar 15 años de actividades sin migrar quién estaba en cada momento (comercial responsable, estado del cliente, campaña asociada) produce un histórico que nadie sabe interpretar. Si no se puede preservar el contexto, mejor archivar completo que traer datos huérfanos.
◇ DecisiónLa migración se ejecuta primero en un entorno espejo con datos reales. Se valida con un panel de usuarios clave (comercial, supervisor, financiero). Solo cuando el equipo confirma que "los datos están bien", se ejecuta la migración a producción. Un go-live con datos rotos es prácticamente irreversible.
✓ ReglaCada campo migrado tiene su origen documentado: de qué tabla y campo del sistema anterior viene, qué transformación se le aplicó y qué reglas de deduplicación. Sin este mapeo escrito, cualquier duda posterior sobre un dato requiere una arqueología imposible.
✓ ReglaCada registro migrado guarda un campo con el ID del sistema original. Vale muy poco a los usuarios pero mucho al equipo técnico: permite auditar, reejecutar migraciones, hacer conciliaciones y responder preguntas del tipo "¿este cliente es el mismo que teníamos como número X?".
✓ ReglaEn cada empresa hay Excels privados que la gente no menciona en el kick-off pero de los que depende su trabajo diario. Aparecen en la semana 3 del proyecto, obligan a rediseñar el modelo de datos y multiplican el alcance. Preguntar por ellos explícitamente en el discovery ahorra semanas.
⚠ RiesgoCuentas y contactos antes que oportunidades. Productos y precios antes que pedidos. Casos y usuarios antes que actividades. Migrar en el orden correcto evita huérfanos y facilita la reejecución si algo falla.
✓ ReglaAntes de mover datos personales al nuevo sistema hay que validar consentimientos, aplicar el derecho al olvido pendiente y anonimizar los históricos que ya no procede conservar. Una migración es la ocasión perfecta para regularizar la situación de RGPD que llevaba años pendiente.
◇ DecisiónEl corte no se produce en un día. Hay un periodo de coexistencia donde el sistema viejo sigue vivo en lectura mientras Dynamics 365 va tomando el relevo operativo. Diseñar ese solapamiento (¿1 semana? ¿1 mes? ¿por departamentos?) es una decisión estratégica, no técnica.
◇ DecisiónLa migración inicial cubre el arranque. Pero durante las primeras 4-8 semanas siempre aparecen datos que no se migraron, correcciones que hay que aplicar y ajustes de mapeo. Reservar capacidad técnica del equipo de proyecto para esa fase evita que las correcciones se hagan "a mano" en producción y generen inconsistencias.
✓ ReglaLa migración de datos es una fase específica dentro del proyecto global. Puedes ver la metodología completa en la página pilar de implementación de Microsoft Dynamics 365 — con fases, entregables y modelo de soporte post go-live.
No todas las migraciones son iguales. Estas son las observaciones específicas por origen, con el veredicto práctico de WHY Dynamics para cada caso.
Navision (NAV) es un ERP sólido, pero muchas empresas lo usan como CRM de facto porque nunca implementaron uno real. Notas de comercial en el campo "observaciones" del cliente. Oportunidades como pedidos en borrador. Actividades comerciales en Outlook sin conexión con NAV.
La migración típica: la parte comercial va a Dynamics 365 Sales y libera a NAV de una función para la que no está diseñado. La parte de compras, almacén y contabilidad se queda en NAV (o se migra a Business Central) con integración bidireccional.
Business Central es la evolución cloud de Navision. Como ERP para pyme funciona muy bien y su integración nativa con Dynamics 365 Sales es la más sólida del mercado Microsoft.
Nuestra opinión: si ya estás en NAV y funciona, no hay urgencia de migrar solo por estar en cloud. Si estás valorando ERP nuevo, Business Central + Dynamics 365 Sales es hoy la combinación más equilibrada para pyme española en coste, funcionalidad e integración.
Axapta (AX 2009, 2012, R2, R3) y su sucesor Dynamics 365 Finance & Operations son ERPs de gama alta con lógica de negocio pesada. Migrarlos completos es un proyecto entre 4 y 9 meses según nivel de personalización.
La parte comercial (CRM) puede migrar a Dynamics 365 Sales de forma independiente y en semanas, sin esperar a la migración del ERP. Es la vía habitual: descargar de responsabilidades comerciales a AX/F&O y planificar la migración financiera con horizonte más largo.
Salesforce → Dynamics 365 es la migración más habitual cuando el ecosistema Microsoft 365 (Teams, Outlook, SharePoint) ya está consolidado y Salesforce empieza a percibirse como caro o desintegrado.
La migración de datos en sí es sencilla porque hay conectores maduros. Lo complejo es el mapeo conceptual: las etapas del pipeline, los objetos personalizados y las automatizaciones no traducen 1:1 y hay que rediseñarlas para el estándar de Dynamics 365, no replicarlas.
Migración habitual cuando la empresa creció con HubSpot en marketing y ya necesita un CRM con gestión de operación comercial y postventa completa, no solo pipeline.
La migración de contactos, empresas y deals es directa. El mapeo del ciclo de vida del contacto de HubSpot al modelo de Dynamics 365 requiere trabajo específico. La parte de marketing suele quedarse en HubSpot con integración bidireccional o se traslada a Dynamics 365 Marketing según volumen.
La migración más frecuente en pyme española. Access y Excel han cumplido su función durante años pero se han convertido en un cuello de botella: sin concurrencia robusta, sin permisos granulares, sin auditoría, sin app móvil.
Técnicamente es sencillo por volumen moderado. Requiere rediseño previo del modelo: los Excel llevan años acumulando columnas ad-hoc y macros que no se replican tal cual. Es también la ocasión ideal para consolidar los N ficheros que existen por toda la empresa en un modelo único.
Respuestas directas, sin evasivas comerciales.
Auditoría inicial del dato de origen sin compromiso. Sin propuesta económica antes de entender la calidad del dato con el que trabajamos.
📞 918 991 604Lun–Vie · 9:00h a 18:00h · Madrid, España
En 30 minutos analizamos qué sistema tienes hoy, qué volumen de datos hay, qué calidad tiene el dato de origen y qué riesgos concretos tiene tu caso. Sin propuesta económica antes de entender bien la situación.
O llámanos directamente:
918 991 604
Lun–Vie · 9:00h a 18:00h · Madrid y toda España