Migrar todos los datos disponibles no es prudencia. Muchas veces es la forma más rápida de contaminar el nuevo ERP.
Un ERP antiguo suele acumular años de historia: clientes duplicados, proveedores inactivos, artículos que ya no se venden, dimensiones que nadie recuerda, códigos creados para resolver una excepción, cuentas antiguas, documentos cerrados, registros inconsistentes y datos que existen únicamente porque nadie se atrevió a borrarlos. Llevar todo ese universo a Business Central puede parecer seguro, pero añade coste, pruebas, reconciliación y complejidad sin mejorar la operación.
Lo que Business Central necesita para operar desde el primer día
Maestros activos, saldos reconciliados, documentos abiertos, inventario real, dimensiones necesarias, condiciones comerciales y configuraciones que soportan procesos vigentes.
Lo que debe seguir disponible sin vivir dentro del ERP nuevo
Históricos cerrados, documentación antigua, ejercicios pasados o detalle transaccional que deba conservarse por auditoría, consulta o regulación, pero que no necesite participar en la operación diaria.
La tercera categoría es la más incómoda: datos que deberían desaparecer
Duplicados, registros sin propietario, códigos muertos, estructuras inventadas para el sistema antiguo, valores sin uso y datos que nadie puede explicar no deberían entrar ni en Business Central ni en un archivo “por si acaso”. Una migración también es una oportunidad de cerrar etapas.
Los seis grupos de datos que deberían tener una decisión explícita antes del primer ensayo de carga
Microsoft documenta herramientas de migración para clientes, proveedores, inventario y cuentas, además de mecanismos para importar maestros y saldos. En un proyecto real, el alcance suele ser mayor y debe acordarse entidad por entidad. La decisión debe responder a una pregunta simple: ¿qué necesita estar en Business Central para que el proceso funcione correctamente desde el arranque?
Clientes y proveedores
Datos fiscales, direcciones, contactos, condiciones de pago, métodos de pago, grupos contables, divisas, vendedores o compradores, dimensiones y otra información necesaria para facturar, comprar, cobrar y pagar.
Artículos, servicios y maestros operativos
Referencias activas, unidades, variantes, almacenes, ubicaciones, costes, precios, categorías, atributos, trazabilidad, reposición y otros parámetros que condicionan compra, venta, stock o producción.
Plan de cuentas, dimensiones y configuraciones
Cuentas activas, dimensiones analíticas, grupos contables, series numéricas, términos, métodos y estructuras que permiten registrar correctamente las operaciones desde el primer asiento.
Saldos iniciales
Contabilidad, clientes, proveedores, bancos e inventario deben arrancar con cifras reconciliadas. Un saldo correcto en mayor pero incorrecto en auxiliares genera problemas desde el primer cierre.
Documentos y transacciones abiertas
Facturas pendientes, abonos, pagos, pedidos abiertos y otros compromisos que seguirán vivos tras el go-live. Aquí importa conservar referencia, vencimiento, moneda, importe y trazabilidad suficiente.
Inventario y datos específicos de negocio
Existencias por almacén o ubicación, lotes, series, proyectos abiertos, activos, contratos, producción u otras entidades necesarias según el alcance funcional del proyecto.
La decisión no es técnica: depende de consulta, auditoría, regulación, reporting y coste de mantener el pasado vivo
Microsoft distingue distintos caminos de migración y, para determinados escenarios, incluso documenta opciones de reimplantación que trasladan datos esenciales como maestros, saldos iniciales y configuración en lugar de todo el histórico. Esa idea es útil más allá de una versión concreta: una empresa debe decidir si quiere una continuidad transaccional completa o un arranque limpio con acceso separado al pasado.
Migración de histórico amplio
Tiene sentido cuando el negocio necesita navegar operaciones antiguas dentro del ERP, mantener continuidad detallada de consultas o aprovechar relaciones históricas que resultarían difíciles de reconstruir fuera.
Coste: más extracción, transformación, validación, reconciliación, pruebas y tiempo de carga.
Arranque con esenciales + archivo histórico
Maestros activos, saldos, documentos abiertos y datos necesarios para continuar la operación. El resto se conserva en el sistema anterior en modo consulta o en una capa de archivo gobernada.
Ventaja: menos volumen y una oportunidad real de simplificar el nuevo modelo.
Pregunta de control: si un movimiento de hace siete años no participa en ningún proceso actual, ¿qué necesidad concreta obliga a reconstruirlo dentro de Business Central? Si la respuesta es únicamente “por si alguien lo consulta”, probablemente el archivo sea una mejor arquitectura.
Haz un perfilado del origen antes de diseñar el fichero de migración
El peor momento para descubrir que un campo crítico está vacío en el 40 % de los registros es durante el ensayo final. La primera fase debería analizar el dato de origen: cuántos registros existen, cuántos están activos, qué campos son obligatorios, qué valores se repiten, qué códigos no tienen descripción, qué relaciones están rotas y qué información depende de lógica que solo existe en el ERP antiguo.
El perfilado evita discusiones abstractas. En lugar de “los clientes están bastante limpios”, el equipo puede saber que existen 12.400 clientes, 3.100 con movimiento en los últimos tres años, 430 duplicados potenciales, 250 sin identificación fiscal completa y 600 con condiciones comerciales que ya no corresponden a ningún modelo futuro.
Ese diagnóstico permite decidir alcance, esfuerzo y responsable de limpieza antes de que el calendario de proyecto dependa de una tarea que nadie había dimensionado.
Qué medir en cada entidad
Limpiar datos no es borrar errores. Es decidir cuál será el lenguaje común del nuevo ERP.
Una migración bien planteada transforma estructuras antiguas en un modelo coherente con Business Central. Eso implica definir códigos, nombres, unidades, dimensiones, grupos, categorías, divisas, condiciones comerciales y reglas de negocio. La limpieza no puede limitarse a Excel: tiene que producir decisiones funcionales.
Fusionar duplicados
Decidir qué registro sobrevive, qué código se mantiene y cómo se conserva la relación con documentos, contactos, saldos o históricos.
Normalizar catálogos
Países, provincias, unidades, familias, métodos de pago, divisas, almacenes y códigos deben tener valores controlados que no dependan de abreviaturas históricas.
Rediseñar dimensiones
Un código analítico heredado no tiene por qué convertirse automáticamente en una dimensión de Business Central. El modelo debe responder al reporting y al control futuro.
Convertir reglas antiguas
Campos calculados, textos libres o códigos creados por personalizaciones deben mapearse a la lógica estándar, una extensión o una integración cuando sigan siendo necesarios.
Los maestros determinan si Business Central empieza ordenado o hereda el caos el primer día
Microsoft recomienda capturar especialmente datos maestros como clientes, artículos, proveedores y mayor cuando se utilizan paquetes de configuración. Tiene sentido: esos registros alimentan miles de operaciones futuras. Un cliente mal clasificado o un artículo con una unidad incorrecta no es un defecto histórico; es un error que se repetirá cada vez que alguien venda, compre, facture o planifique.
Clientes y proveedores
Revisar identificadores fiscales, direcciones, contactos, divisas, pagos, bancos, grupos contables, retenciones o impuestos, vendedores, compradores y dimensiones.
Conviene separar claramente registros activos de históricos. Un proveedor creado para una compra puntual de 2014 probablemente no necesita vivir en el nuevo maestro.
Artículos y servicios
Códigos, descripción, unidades, categorías, inventariable/no inventariable, costes, precios, reposición, proveedores, trazabilidad, lotes, series, dimensiones y reglas de almacén.
Los artículos inactivos pueden conservarse solo cuando existe una razón operativa, de servicio, repuesto, garantía o consulta que lo justifique.
Plan de cuentas y dimensiones
Migrar un plan de cuentas no debería significar reproducir cientos de cuentas creadas para suplir un mal modelo analítico. Business Central permite separar contabilidad financiera y dimensiones.
La migración es una oportunidad para revisar qué necesita existir como cuenta y qué debería convertirse en dimensión, categoría o atributo.
Datos industriales o sectoriales
Escandallos, rutas, centros, capacidades, proyectos, activos, contratos, precios especiales o datos sectoriales requieren su propia estrategia.
No deberían cargarse hasta que el modelo funcional esté validado, porque un error estructural puede multiplicarse en miles de registros dependientes.
El go-live financiero se gana en la reconciliación, no en la carga
Conseguir que el mayor cuadre no es suficiente. Clientes, proveedores, bancos, inventario y otras áreas auxiliares deben reconciliar con contabilidad. Si el saldo de clientes en Business Central coincide con el sistema anterior, pero el detalle por documento o vencimiento no cuadra, el equipo empieza el nuevo ERP con problemas de cobro y conciliación.
Microsoft documenta la creación de saldos iniciales y, para bancos, advierte específicamente sobre cómo registrar el saldo para no romper la conciliación bancaria. Este tipo de detalle confirma algo importante: un saldo no es solo una cifra. Tiene estructura contable y operativa.
La reconciliación debe diseñarse por capas y tener criterios de aceptación firmados por finanzas antes de cada ensayo relevante.
Cuadres que deberían existir antes del arranque
Lo que sigue vivo después del go-live necesita más detalle que un simple saldo
Una factura pendiente de cobro no es únicamente un importe contra una cuenta. Tiene cliente, documento, fecha, vencimiento, moneda, forma de pago, posible retención, dimensión, referencia y estado. Si el equipo necesita continuar una gestión después del arranque, la migración debe conservar el nivel de detalle suficiente para no perder el proceso.
Clientes y proveedores abiertos
Facturas, abonos, pagos y aplicaciones pendientes deben permitir continuar cobros, pagos, vencimientos y conciliaciones sin reconstrucciones manuales.
Pedidos y compromisos
Pedidos de venta, compra, contratos o proyectos abiertos deben migrarse solo si seguirán gestionándose en Business Central y el esfuerzo de reconstrucción está justificado.
Divisas y tipos de cambio
Los documentos abiertos en moneda extranjera requieren revisar tipos, importes y lógica de valoración. Microsoft contempla específicamente la migración de tipos relacionados con transacciones abiertas en algunas extensiones.
Referencias externas
Conservar número original, referencia bancaria, factura externa o identificador legacy puede ser necesario para soporte, auditoría y conciliaciones posteriores.
La foto inicial del stock debe ser operativa, contable y físicamente defendible
En empresas con inventario, este bloque puede ser el más delicado del cutover. No basta con exportar cantidades. Hay que acordar la fecha de corte, congelar o controlar movimientos, realizar recuentos cuando sea necesario, identificar documentos en tránsito y explicar diferencias entre sistema y físico. La migración debe terminar con un stock que el almacén pueda reconocer.
Cantidad por ubicación
Almacén, ubicación, variante y unidad deben reflejar dónde está realmente el material y cómo se moverá después del arranque.
Lotes y series
Si existe trazabilidad, no se puede cargar solo una cantidad agregada. Deben conservarse los identificadores necesarios y su relación con la existencia disponible.
Valoración
El valor inicial debe reconciliar con contabilidad y respetar el modelo de coste. Diferencias aparentemente pequeñas pueden afectar margen y cierre desde el primer mes.
Movimientos durante el corte
Recepciones, expediciones, consumos y ajustes entre extracción y arranque necesitan una estrategia. Sin control, el fichero nace desactualizado antes de cargarse.
Excel, paquetes de configuración, asistentes y migraciones específicas: la herramienta depende del origen y del volumen
Business Central ofrece distintas vías para cargar datos. Microsoft documenta asistentes de migración para determinados productos y escenarios, importación desde Excel y paquetes de configuración para la puesta en marcha de nuevas compañías. También existen caminos específicos para migraciones desde Business Central on-premises, Dynamics NAV, Dynamics GP, Dynamics SL y fuentes SQL personalizadas.
La elección no debería basarse en “qué herramienta conocemos mejor”, sino en el tipo de dato, origen, volumen, relaciones, frecuencia, necesidad de transformación y capacidad de repetir el proceso. Una carga de clientes y proveedores no exige necesariamente el mismo mecanismo que una migración completa desde un entorno on-premises.
Microsoft también advierte de que los paquetes RapidStart no están pensados para importar grandes volúmenes en compañías ya productivas, porque pueden afectar al rendimiento. Es otra razón para separar migración inicial de integraciones o cargas recurrentes posteriores.
El mecanismo debe poder repetirse
El primer fichero no debería llegar al go-live. Debería llegar a una lista larga de errores.
Una migración fiable se construye mediante ciclos. El primer ensayo valida mapeos básicos. Los siguientes reducen errores, afinan tiempos, incorporan casos excepcionales y mejoran reconciliaciones. El objetivo es que el ensayo final sea aburrido: mismas reglas, mismo proceso y desviaciones conocidas.
Ensayo estructural
Probar formatos, claves, dependencias, tablas, validaciones y reglas de transformación con un volumen representativo.
Ensayo funcional
Validar que los datos permiten comprar, vender, cobrar, pagar, planificar, producir o gestionar proyectos según el alcance.
Ensayo completo
Cargar el perímetro acordado, medir tiempo, ejecutar reconciliaciones y confirmar que usuarios clave reconocen el resultado.
Dress rehearsal
Repetir el cutover con condiciones próximas a producción: ventana, responsables, secuencia, tiempos, validaciones y decisión final de aceptación.
“La carga terminó sin errores” no significa que la migración sea correcta
Una importación puede completarse técnicamente y contener datos funcionalmente incorrectos. El éxito exige validación de negocio: un cliente puede existir y tener un grupo contable erróneo; un artículo puede cargarse y usar una unidad incorrecta; un saldo puede cuadrar y tener vencimientos mal asignados. Los criterios de aceptación deben combinar controles técnicos y funcionales.
Conteos
Número de registros de origen, descartados, fusionados, transformados y cargados. Toda diferencia debe estar explicada.
Muestras funcionales
Usuarios clave revisan casos normales y excepcionales y confirman que la información es utilizable, no solo visible.
Reconciliación
Saldos y auxiliares cuadran contra la fuente y contra los informes de control definidos para el arranque.
Procesos completos
Los datos cargados permiten ejecutar escenarios end-to-end sin corregir manualmente maestros o saldos para que el proceso funcione.
El último fin de semana no debería convertirse en el momento de decidir reglas que llevan meses abiertas
El cutover necesita una secuencia acordada: cuándo se detiene el sistema antiguo, qué transacciones siguen permitidas, quién extrae, quién transforma, quién carga, quién reconcilia y quién autoriza el arranque. Cada actividad debería tener responsable, duración prevista, dependencia y criterio para detenerse si algo falla.
También debe existir un tratamiento para movimientos tardíos. Una factura contabilizada después de la extracción, una recepción urgente o una expedición durante la ventana puede dejar diferencias si no existe un procedimiento. El objetivo no es congelar el negocio más de lo necesario, sino controlar cada cambio entre la foto de origen y el estado final de Business Central.
El plan de rollback debe definirse antes. Cuando llega una incidencia grave, no es buen momento para discutir cuánto tiempo puede mantenerse parado el negocio o si el ERP antiguo todavía admite nuevas transacciones.
La secuencia mínima de un cutover controlado
El partner puede cargar datos. No puede decidir qué significa un cliente correcto para tu negocio.
La migración necesita responsabilidad compartida. El partner aporta método, herramientas, conocimiento de Business Central, transformación y controles técnicos. El cliente conoce qué registros siguen vigentes, qué reglas comerciales son correctas, qué duplicados deben fusionarse y qué cifras deben aceptarse. Delegar toda la calidad del dato al proveedor crea una falsa sensación de seguridad.
Responsabilidad del negocio
Definir validez, propietarios, reglas, alcance, registros activos, criterios de archivo, prioridades y aceptación funcional.
Responsabilidad de IT
Acceso a fuentes, seguridad, extracción, entornos, dependencias, integraciones, archivo y conservación técnica.
Responsabilidad del partner
Diseñar mapeos, transformación, mecanismos de carga, dependencias, controles, errores, ensayos y soporte al cutover.
Responsabilidad de finanzas y usuarios clave
Reconciliar, validar casos, confirmar saldos y aceptar que los datos son suficientes para operar desde el día uno.
Cuanto más personalizado está el origen, menos conviene tratar la migración como un movimiento de tablas
En Dynamics NAV, Navision o un ERP propio, parte de la información puede vivir en campos personalizados, tablas específicas, informes calculados o lógicas de negocio que no existen de la misma forma en Business Central. El mapeo debe entender qué representa cada dato y si sigue siendo necesario. Copiar estructuras personalizadas sin revisar su propósito puede recrear deuda técnica en el nuevo ERP.
NAV / Navision
Revisar personalizaciones, dimensiones, maestros, histórico, integraciones, versiones y dependencia de campos específicos antes de decidir camino de upgrade o reimplantación.
ERP no Microsoft
Mapear semántica, catálogos y lógica de negocio. No asumir que una entidad con el mismo nombre significa exactamente lo mismo en ambos sistemas.
Excel y aplicaciones satélite
Muchas verdades de negocio están fuera del ERP. Precios, clasificaciones, contactos, proyectos o atributos pueden vivir en hojas paralelas y deben entrar en el inventario de fuentes.
Integraciones
CRM, ecommerce, logística o verticales pueden seguir enviando datos. Hay que decidir qué sistema será maestro después del go-live para evitar duplicidad y sobrescrituras.
Hay datos que deberían demostrar por qué merecen entrar en Business Central
Cambiar el criterio por defecto ayuda mucho. En vez de preguntar “¿por qué no migramos esto?”, pregunta “¿qué proceso, consulta o obligación necesita que este dato exista dentro del nuevo ERP?”. Esta inversión de carga de prueba reduce volumen y obliga a pensar en utilidad.
Maestros inactivos sin obligación de consulta
Clientes, proveedores o artículos sin movimiento durante años y sin necesidad contractual, regulatoria o operativa.
Histórico transaccional cerrado
Facturas, pedidos o movimientos antiguos que pueden consultarse en archivo y no participan en procesos futuros.
Campos de personalizaciones obsoletas
Información creada para una pantalla o proceso que no formará parte del modelo futuro no necesita una nueva ubicación por defecto.
Datos sin propietario ni significado claro
Si nadie puede explicar qué significa un valor ni qué decisión soporta, cargarlo solo pospone la pregunta.
Seis formas de convertir la migración de datos en el cuello de botella del proyecto
Empezar a limpiar demasiado tarde
Si el negocio descubre la calidad real de los maestros cerca del go-live, el calendario termina compitiendo con decisiones que necesitan semanas.
Corregir manualmente cada ensayo
Una corrección que no queda incorporada a la regla de transformación volverá a aparecer en la siguiente carga.
Migrar histórico sin caso de uso
Aumenta volumen y pruebas para conservar información que después apenas se consulta o podría estar disponible de forma más simple.
No reconciliar auxiliares
El mayor puede cuadrar y seguir existiendo errores en clientes, proveedores, bancos o inventario que explotarán después.
No asignar Data Owners
Sin un responsable de negocio, las decisiones sobre duplicados y validez se convierten en discusiones interminables entre IT y consultoría.
Separar migración de procesos
Los datos solo pueden validarse correctamente cuando se sabe cómo se usarán. Diseñar ambos mundos por separado genera sorpresas en pruebas.
Una secuencia práctica para preparar la migración sin dejarla para el final del proyecto
Inventario de fuentes
ERP, Excel, CRM, logística, verticales, bancos, aplicaciones y bases auxiliares. Identificar qué fuente gobierna cada dato.
Perfilado y alcance
Medir calidad y decidir qué entidades, años, estados y registros deben migrarse, archivarse o eliminarse.
Mapeo y transformación
Relacionar origen y destino, definir conversiones, reglas de limpieza, valores por defecto y tratamiento de excepciones.
Ensayos iterativos
Cargar, validar, corregir reglas y repetir hasta reducir errores y estabilizar tiempos.
Reconciliación y aceptación
Finanzas y usuarios clave validan cifras, muestras y procesos completos con criterios explícitos.
Cutover y estabilización
Carga final, go/no-go, soporte de arranque, corrección controlada y cierre del sistema antiguo o paso a modo consulta.
Continúa la preparación de Business Central desde implantación, migración e integración
La migración de datos es una parte del proyecto. Estas páginas ayudan a revisar el destino, el modelo de implantación, el ERP de origen y las integraciones que deben seguir funcionando después del arranque.
Dynamics 365 Business Central
Migración ERP legacy a Microsoft Cloud
Migrar NAV a Business Central
Business Central API e integraciones
Implantar Business Central en fabricación
Cuánto cuesta implantar Business Central en industria
Qué documenta Microsoft sobre migrar e importar datos en Business Central
Business Central dispone de asistentes, importación desde Excel, paquetes de configuración y rutas específicas de migración según el origen. Microsoft recomienda validar datos antes de aplicarlos y diferencia claramente las herramientas de puesta en marcha de los mecanismos adecuados para cargas en compañías ya productivas.
Importar datos empresariales
Paquetes de configuración
Migrar datos on-premises a Business Central online
Dudas habituales sobre migración de datos a Business Central
¿Qué datos se suelen migrar a Business Central?
Normalmente maestros activos, configuraciones necesarias, saldos iniciales, documentos abiertos, inventario y datos específicos requeridos para continuar los procesos. El alcance exacto depende del origen y del modelo de negocio.
¿Es necesario migrar todo el histórico?
No. Muchas organizaciones migran datos esenciales y conservan el histórico en un entorno de consulta o archivo. La decisión debe considerar regulación, auditoría, reporting, uso y coste.
¿Se puede usar Excel para migrar datos?
Sí. Microsoft documenta importación desde Excel y paquetes de configuración para escenarios de puesta en marcha. El mecanismo concreto depende del origen, volumen y complejidad.
¿Quién debe limpiar los datos?
El negocio debe decidir validez, duplicados y reglas. El partner puede aportar herramientas, transformación y metodología. La calidad no puede delegarse completamente porque requiere conocimiento funcional.
¿Cuántos ensayos de migración hacen falta?
No existe un número universal. Deben realizarse suficientes ciclos para estabilizar reglas, errores, reconciliaciones y tiempos. Un proyecto complejo suele necesitar varios ensayos y un dress rehearsal cercano al go-live.
¿Cómo se valida que la migración es correcta?
Con conteos, muestras, controles de integridad, reconciliación financiera y validación de procesos completos por usuarios clave. No basta con que la importación termine sin errores técnicos.
¿Qué ocurre con el ERP antiguo después del go-live?
Puede mantenerse temporalmente en modo consulta, archivarse o retirarse según obligaciones y arquitectura. Debe definirse quién tendrá acceso, durante cuánto tiempo y cómo se conservará la información.
¿La migración cambia si vengo de NAV?
Sí. Versiones, personalizaciones, modelo de datos, integraciones y camino técnico condicionan la estrategia. Microsoft documenta rutas específicas para NAV y Business Central on-premises.
La migración de datos debe conectar negocio, ERP, integración, reporting y evolución futura
Ayesa aborda Business Central desde una visión de plataforma: procesos, datos, migración, integración, Power BI, Power Platform, Azure y evolución hacia Copilot e IA. Esto permite diseñar el dato no solo para llegar al go-live, sino para que siga siendo útil después.
Designaciones, especializaciones y certificaciones Microsoft
Consulta las capacidades Microsoft de Ayesa en Business Applications, Azure, datos, IA, Modern Work y seguridad.
Antes de construir la migración, comprueba si tus datos están preparados para llegar a Business Central
Podemos revisar fuentes, maestros, históricos, saldos, documentos abiertos, inventario, integraciones y criterios de archivo para dimensionar el trabajo y detectar riesgos antes de que la migración condicione el calendario del proyecto.
Qué conviene traer a esa conversación
¿Qué datos merece la pena llevar a Business Central?
Cuéntanos de qué sistema partes, qué histórico necesitas conservar y qué procesos deben seguir funcionando desde el primer día. Podemos ayudarte a definir una estrategia de migración controlada y verificable.
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)