Cómo migrar a Business Central sin perder datos ni operación

Una migración a Business Central no es copiar archivos de un sistema a otro. Es decidir qué información merece vivir en el nuevo ERP, en qué forma y a partir de qué fecha. Quien la trata como un simple traspaso de datos suele descubrir, después del arranque, que el cierre del mes no cuadra o que los CFDI no se emiten como antes.

Esta página cubre los dos escenarios que aparecen con más frecuencia: pasar a Business Central desde Excel, un software contable o un ERP anterior, y migrar entre versiones de Business Central. Para el panorama general de cualquier cambio de ERP, consulte también la guía de migración de ERP.

Tres puntos de partida, tres migraciones distintas

La palabra «migración» esconde trabajos muy diferentes según el origen.

En Excel el desafío es ordenar: casi siempre hay que crear por primera vez un código único de cliente, de proveedor y de artículo. Con un software contable la contabilidad suele estar en buen estado, pero faltan los módulos de ventas, compras e inventario, que se construyen desde cero. Con un ERP anterior el riesgo está en las costumbres: cada empresa ha doblado su sistema viejo a su manera, y ese comportamiento hay que reproducir o rediseñar a conciencia.

Lo que ofrece Microsoft para migrar

Microsoft documenta una herramienta de migración a la nube para llegar a Business Central en línea. De acuerdo con su documentación, permite migrar desde Business Central instalado en servidores propios (directamente desde la versión 25; las versiones 15 a 24 se actualizan primero a la 25 como mínimo), desde Dynamics GP 2015 y posteriores, desde Dynamics SL 2015 y posteriores, o desde cualquier otro origen SQL mediante migraciones personalizadas.

Hay requisitos técnicos que conviene verificar desde el principio:

• la solución de origen debe funcionar con SQL Server 2016 o posterior, con un nivel de compatibilidad de base de datos de 130 como mínimo;
• un cliente con Dynamics NAV debe pasar antes a Business Central en servidores propios y solo después puede saltar a la nube;
• desde la versión 14 hay dos caminos: una migración completa (actualización local a la versión 25 o superior y después migración) o la herramienta de reimplementación de Business Central 14, que traslada solo los datos esenciales (datos maestros, saldos iniciales y configuración) directamente a la nube.

Si el origen no es SQL, como un archivo de Excel o un sistema propietario, Microsoft indica usar paquetes y plantillas de configuración para cargar los datos en Business Central y, si el destino es la nube, recurrir después a la herramienta de migración. En la práctica, para una pyme que viene de hojas de cálculo o de un programa contable local, el camino habitual es la carga con plantillas de configuración, no la migración SQL.

Esta mecánica forma parte del temario del examen MB-800 de Microsoft para consultores funcionales: creación de la empresa con el asistente de instalación, hojas y paquetes de configuración, asientos de apertura y migración de datos. Es una buena pregunta para su integrador: quién del equipo domina estas herramientas y las ha usado en proyectos reales.

Qué datos migrar y cuáles dejar atrás

Cuanto más se traslada, más se arrastra de basura. El criterio útil es separar tres categorías.

Datos maestros

Clientes, proveedores, artículos, cuentas, almacenes, empleados y listas de materiales. Se migran limpios, deduplicados y con un identificador estable. Es el momento de eliminar a los clientes inactivos, unificar los RFC mal capturados y corregir direcciones fiscales. Un RFC con un error hoy es un CFDI rechazado mañana.

Saldos y documentos abiertos

Saldos de cuentas al corte, cuentas por cobrar y por pagar vivas, pedidos pendientes de entregar o de recibir, existencias valoradas por almacén. Estos datos no se «importan», se cuadran: el total migrado debe coincidir con el balance del sistema anterior, línea por línea, con la firma del contador.

Historial

Aquí está la decisión más debatida. El historial completo de transacciones rara vez aporta valor operativo y multiplica el tiempo de carga y de verificación. Una solución frecuente es cargar solo saldos y, si la operación lo exige, un histórico resumido de ventas por cliente o por artículo, mientras el detalle antiguo se consulta en el sistema previo, mantenido en solo lectura. Para cada ejercicio cerrado, pregunte a su contador qué necesita realmente en caso de revisión del SAT.

Particularidades mexicanas que no pueden dejarse para el final

Migrar en México implica lidiar con obligaciones que el ERP debe cumplir desde el primer día de producción.

• Facturación electrónica. La emisión de CFDI 4.0 con un proveedor autorizado de certificación (PAC) tiene que probarse de extremo a extremo antes del arranque: series y folios, régimen fiscal, uso del CFDI, complementos de pago y cancelaciones. La guía de CFDI en un ERP detalla qué revisar.
• Contabilidad electrónica. El catálogo de cuentas debe poder enviarse al SAT con el código agrupador, y la balanza de comprobación mensual debe salir sin retrabajo. Revise el enfoque de contabilidad electrónica en un ERP antes de diseñar el catálogo nuevo.
• Nómina. Si hoy la nómina corre en otro sistema, decida si seguirá fuera o si se conectará al ERP, y cómo llegarán las pólizas contables.
• Localización. Microsoft ofrece directamente la localización de Business Central para México, entre los 21 países que cubre. Cómo se combina con el timbrado y con los reportes fiscales locales es un punto que su integrador debe demostrar con su propio entorno de pruebas; encontrará el contexto en la página de Business Central en México.

Estrategia de cambio: tres formas de pasar a producción

La elección entre arranque único, arranque escalonado o paralelo depende del tamaño de la empresa, de la tolerancia al riesgo y de la calidad de los datos.

La fecha de corte rara vez coincide con un día cualquiera. Lo habitual es elegir el cierre de un mes o de un periodo fiscal, para que los saldos iniciales sean limpios y el contador pueda cerrar el sistema anterior sin arrastrar movimientos a medias. Evite los cierres de ejercicio y los picos de temporada.

Si le preocupa dónde se aloja Business Central después del cambio, revise las opciones de alojamiento en la nube: condiciona el tipo de migración que le corresponde.

Pruebas: lo que separa un arranque tranquilo de uno doloroso

Una migración se ensaya varias veces antes de ejecutarla de verdad. El esquema que mejor funciona es simple:

1. Carga de prueba en un entorno aislado, para medir tiempos y descubrir errores de formato.
2. Verificación contable: los saldos migrados deben coincidir con los del sistema de origen, firmados por el contador.
3. Pruebas por proceso: una venta completa con CFDI, una compra con recepción, un cobro, un pago, un cierre mensual y la balanza electrónica.
4. Pruebas de usuarios clave: quienes van a trabajar a diario recorren su propio flujo, no un guion del integrador.
5. Ensayo general de la carga final, cronometrado, con la secuencia exacta del fin de semana de corte.

Si el entorno es en línea, aproveche los entornos de pruebas (sandbox). Microsoft abre los de vista previa de cada versión mayor aproximadamente un mes antes de su lanzamiento, en marzo y septiembre, y los elimina 30 días después de la disponibilidad oficial; úselos para comprobar que sus extensiones y personalizaciones siguen funcionando antes de que la versión llegue a producción.

Plan de retorno: ensayar la marcha atrás antes de necesitarla

El plan de retorno no es pesimismo: es lo que permite decidir con serenidad cuando algo falla. Debe estar escrito antes de la fecha de corte e incluir:

• el estado en que queda el sistema anterior (intacto, en solo lectura, con copia verificada);
• el punto de no retorno: a partir de qué momento deshacer cuesta más que seguir;
• los criterios que activan la vuelta atrás (saldos que no cuadran, CFDI que no se timbran, usuarios clave incapaces de operar);
• qué hacer con los documentos capturados en Business Central durante ese lapso;
• quién decide y a qué hora se toma la decisión.

En la nube, Microsoft facilita una red de seguridad técnica: un entorno puede restaurarse hasta 10 veces por mes calendario y a cualquier momento de los últimos 28 días, en la misma región de Azure y con la misma localización, siempre que se cuente con una suscripción de pago. Es útil, pero no sustituye el plan: restaurar un entorno devuelve los datos de Business Central, no lo que ocurrió mientras tanto en bancos, almacén o con sus clientes.

Migrar entre versiones de Business Central

Quien ya usa Business Central también «migra», aunque más bien actualiza. En línea, Microsoft publica dos actualizaciones mayores al año, en abril y octubre, y actualizaciones menores cada mes sin versión mayor; estas incluyen correcciones críticas y cambios regulatorios. El producto en línea se rige por la Modern Lifecycle Policy: actualizaciones continuas y una versión mayor cada seis meses.

El periodo de actualización de una versión mayor arranca con su disponibilidad general (normalmente el primer día hábil de abril u octubre) y dura cinco meses; la versión se ofrece a los entornos existentes alrededor de una semana después y sigue un mes de gracia. Cada entorno tiene por defecto una ventana de actualización entre las 20:00 y las 06:00 horas locales del país. El administrador puede cambiarla, con una duración mínima de seis horas, y si una actualización no termina dentro de la ventana se cancela y se reprograma siete días más tarde.

Con estos plazos, la buena práctica es:

• elegir una ventana que no coincida con el cierre mensual ni con las fechas de declaraciones;
• probar cada versión mayor en un sandbox con una copia reciente del entorno de producción;
• revisar las extensiones propias y de terceros, sobre todo las de integraciones y de desarrollo a medida;
• confiar el seguimiento a un servicio de soporte y mantenimiento si no cuenta con un responsable interno.

Para conocer las diferencias entre ediciones y versiones, visite la página de versiones y ediciones.

Errores frecuentes que conviene evitar

• Migrar todo «por si acaso». Datos sucios en el sistema nuevo son un problema que se paga cada día.
• Dejar la limpieza para el final. Depurar catálogos lleva más tiempo que cargarlos; empiece semanas antes.
• Ignorar al contador. Es quien valida saldos, catálogo y pólizas; debe participar desde el diseño, no en la firma final.
• Probar solo el camino feliz. Las notas de crédito, las cancelaciones de CFDI y los pagos parciales son donde aparecen los fallos.
• No entrenar a los usuarios. Un ERP bien migrado y mal usado produce los mismos errores que el anterior; planee la formación antes del arranque.
• Sin plan de retorno. Sin criterios previos, la decisión se toma bajo presión y a destiempo.
• Elegir al integrador solo por precio. Pregunte por proyectos de migración reales desde su mismo origen y por su experiencia con CFDI y contabilidad electrónica.

Cómo preparar su proyecto

Antes de pedir propuestas, junte un inventario simple: de dónde vienen los datos, cuántas entidades fiscales hay, qué procesos son críticos y cuáles hay que rediseñar. Con eso, las propuestas serán comparables. Si la migración forma parte de un proyecto más amplio, la página sobre la implantación de Business Central explica el recorrido completo, y si ya tiene un ERP en problemas, el servicio de auditoría y rescate ayuda a decidir si conviene corregir o migrar.

Nuestro servicio es gratuito: describe su origen, su sector y sus plazos, y le ponemos en contacto con un integrador de Business Central con experiencia en migraciones similares. Para afinar la elección, lea cómo elegir al integrador y valore su capacidad para acompañar la contabilidad.

Los nombres de software mencionados son marcas de sus respectivos editores y se citan únicamente a título informativo. Este sitio es independiente y no está afiliado a ningún editor.