Fabric Mirroring en Business Central: cómo replicar datos en OneLake

Una empresa puede gestionar sus ventas, compras, contabilidad e inventario en Business Central y, aun así, tardar días en responder una pregunta aparentemente sencilla: cuál es el margen por cliente y canal después de descontar devoluciones, transporte y costes operativos. El dato existe, pero se encuentra repartido entre tablas del ERP, archivos de planificación, aplicaciones comerciales y herramientas de análisis. Cada extracción manual introduce tiempos de espera, versiones diferentes y dudas sobre qué cifra es la correcta.

Microsoft ha documentado una función de replicación de datos de Business Central hacia Microsoft Fabric mediante Open Mirroring. La organización selecciona sociedades y tablas del ERP, realiza una carga inicial y mantiene sincronizados los cambios posteriores en OneLake. El objetivo es que las cargas analíticas puedan trabajar sobre esa réplica, en lugar de consultar repetidamente las APIs habituales de Business Central. La integración no convierte Fabric en un nuevo ERP ni sustituye la lógica de negocio: separa mejor la transacción de la explotación del dato.

Para dirección general, el interés está en tomar decisiones con información más consistente. Para finanzas, en disponer de una base de análisis que facilite conciliación, previsiones y explicaciones de desviaciones. Para tecnología, en reducir determinadas integraciones hechas a medida y organizar un acceso estable y controlado al dato. Pero ninguna de esas mejoras aparece automáticamente por activar una opción: siguen siendo necesarios un modelo semántico, controles de acceso, calidad, responsables y una definición del retorno esperado.

Esta guía se centra deliberadamente en el mecanismo específico de mirroring para Business Central: funcionamiento, requisitos, límites, posibles costes, controles y casos donde tiene sentido. Las cuestiones generales sobre qué es Fabric, cómo diseñar una plataforma corporativa de datos o cómo integrar todos los sistemas se desarrollan en las guías de Microsoft Fabric y Dynamics 365 de Ayesa365.

En términos sencillos, mirroring es un proceso que mantiene una copia de determinadas tablas de Business Central en Microsoft Fabric. Primero se obtiene una instantánea inicial; después se incorporan altas, modificaciones y eliminaciones admitidas por el mecanismo de sincronización. El resultado se almacena en OneLake, en formato Delta Parquet, donde puede utilizarse con servicios analíticos como Power BI, Data Factory y experiencias de ingeniería de datos.

La diferencia con la integración habitual mediante APIs es importante. Una conexión Power BI basada en APIs del ERP puede ser suficiente para cuadros de mando sencillos. Sin embargo, al crecer el número de informes, sociedades, tablas y transformaciones, las consultas pueden multiplicarse. El nuevo mecanismo utiliza un servicio interno de replicación y, de acuerdo con las preguntas frecuentes publicadas por Microsoft, no consume los límites de las APIs de Business Central. Esto no significa que el análisis sea ilimitado ni gratuito: la capacidad de Fabric, el almacenamiento y el consumo de consultas siguen importando.

También hay que entender lo que mirroring no hace. No limpia por sí mismo los registros duplicados, no decide cuál es el margen correcto, no documenta automáticamente las reglas contables y no garantiza permisos idénticos entre origen y destino. Replica datos para que puedan analizarse; el trabajo de transformar datos transaccionales en información empresarial fiable empieza después. Un informe impecable construido sobre una métrica mal definida sigue siendo un informe equivocado.

Este recorrido es deliberadamente simple. En una implantación real hay que decidir cómo se separan desarrollo y producción, qué sociedades participan, cuáles son las tablas necesarias y qué usuarios pueden consultar información sensible. La existencia de un almacén unificado tampoco evita que finanzas, ventas y operaciones tengan reglas distintas de cálculo. El valor aparece cuando la empresa acuerda definiciones compartidas y las convierte en modelos reutilizables.

Un ejemplo: la facturación puede salir del ERP, el objetivo comercial de un fichero de planificación y el estado de incidencias del CRM. Mirroring permite que los movimientos del ERP lleguen con menor dependencia de extracciones manuales, pero la relación entre los tres conjuntos de datos requiere diseño. Si se mezclan importes brutos y netos, fechas de pedido y de registro o tipos de cambio inconsistentes, el resultado seguirá siendo difícil de interpretar.

Según Microsoft Learn, pueden incluirse tablas estándar y tablas de extensiones almacenadas en la base SQL de Business Central. La configuración permite seleccionar la frecuencia de sincronización, iniciar o detener exportaciones y consultar el estado de los procesos. La propia documentación describe paquetes de configuración para grupos de tablas habituales. Todo ello puede reducir trabajo repetitivo, pero exige revisar el comportamiento concreto con las extensiones y versiones presentes en cada cliente.

Las preguntas frecuentes indican que las modificaciones incrementales suelen propagarse en minutos, aunque dependen de la actividad y de la configuración. La carga inicial del histórico requiere más tiempo. Por tanto, casi en tiempo real no significa tiempo real garantizado. Un cuadro de mando que admite unos minutos de desfase puede tener buen encaje; una decisión transaccional que exige el saldo exacto en ese mismo instante debe seguir validándose en el sistema operativo apropiado.

Otro aspecto decisivo es la gestión de cambios de esquema. Las guías publicadas advierten de que algunos comportamientos y limitaciones todavía están sin cerrar. Cuando una extensión añade campos o modifica objetos, habrá que comprobar que la réplica y los modelos derivados sigan funcionando. El proyecto debe incluir pruebas de regresión, alertas y procedimientos de recuperación, no solamente una configuración inicial que parece funcionar.

Para una dirección financiera, uno de los principales costes ocultos de la información es el trabajo de preparación. El cierre mensual genera apuntes, saldos, facturas pendientes y conciliaciones; después alguien debe extraerlos, combinarlos, aplicar filtros, contrastarlos con presupuestos y distribuir varias versiones. Cuanto más fragmentado está el dato, más esfuerzo se invierte en discutir de dónde sale una cifra y menos en actuar sobre ella.

Con una réplica bien gobernada, la empresa puede crear un modelo de rentabilidad por cliente, producto y sociedad que reutilice definiciones de costes, devoluciones y periodos. También puede cruzar vencimientos de cobro, previsiones y pedidos para anticipar tensiones de caja. La mejora no es que Fabric calcule automáticamente un margen verdadero; es que permite construir una base central de análisis donde el criterio sea explícito y auditable.

Pensemos en un grupo con seis sociedades. Cada una utiliza Business Central, pero la matriz consolida resultados con hojas Excel enviadas por correo. Un proceso de replicación podría contribuir a actualizar la información de cada entidad hacia un entorno analítico común. Sin embargo, seguiría siendo necesario trabajar eliminaciones intercompany, divisas, calendarios contables, criterios de reconocimiento y conciliaciones. Una réplica de calidad no sustituye la consolidación financiera; la alimenta.

Desde el punto de vista del retorno, propondría medir tres resultados: horas dedicadas a preparar datos para el cierre, discrepancias detectadas entre informes y tiempo para responder una pregunta financiera prioritaria. Si esos indicadores no mejoran, aumentar la capacidad de Fabric o incorporar más tablas puede hacer crecer el proyecto sin aumentar su valor.

Para una empresa constructora o promotora, el mismo patrón puede aplicarse al control económico de proyectos: movimientos contables, proveedores, compras, costes comprometidos, certificaciones y datos de planificación. No todos estos conceptos viven necesariamente en Business Central; pueden proceder de herramientas sectoriales como IB Building 365 o aplicaciones específicas. Fabric permite plantear su combinación, pero la integración de cada fuente debe diseñarse según su disponibilidad real.

En real estate, la posibilidad de conectar sociedades, inmuebles, contratos, facturación y previsiones puede aportar una visión común para gestión y finanzas. Aquí también conviene evitar una promesa exagerada: el mirroring cubre datos del ERP seleccionados; no convierte automáticamente propiedades, contratos y operaciones de terceros en un modelo integrado. El valor aparece cuando la empresa identifica las entidades maestras, sus relaciones y una agenda de decisión concreta.

Estos escenarios son especialmente atractivos para empresas que ya han invertido en Business Central, Power BI y otras soluciones Microsoft. En lugar de repetir una integración independiente para cada necesidad, pueden evaluar una base analítica compartida. Aun así, si el número de informes es pequeño y las APIs actuales cumplen sus requisitos, tal vez no exista un beneficio económico suficiente para adoptar un enfoque más complejo.

La pregunta no debería formularse como «¿qué tecnología es más moderna?», sino como «¿qué patrón resuelve nuestra necesidad con menor coste y riesgo total?». Power BI conectado mediante APIs puede ser la opción correcta para una compañía pequeña con indicadores básicos. Mirroring puede resultar más atractivo para una organización con mucha analítica recurrente, varios conjuntos de datos y un equipo capaz de gobernar Fabric. Y las integraciones por pipelines conservan su utilidad cuando hay que combinar fuentes heterogéneas, normalizar históricos o ejecutar transformaciones específicas.

Los shortcuts tampoco son equivalentes a replicar Business Central directamente. Referencian datos que ya están disponibles en ubicaciones compatibles; no sustituyen por sí solos la extracción del ERP. Si se presenta todo como si fuese la misma tecnología, el cliente puede terminar comprando una arquitectura inadecuada. Por eso la selección debe empezar por casos de negocio, volumen, frescura, latencia tolerable, permisos y esfuerzo de operación.

Business Central contiene información de clientes, proveedores, empleados, precios, cuentas bancarias, facturas y movimientos. Cuando se replica una tabla, pueden viajar campos que no son necesarios para el informe previsto. Microsoft documenta que, en la configuración actual, la elección se realiza por tabla completa y no por columnas individuales. Por eso copiar muchas tablas «por si acaso» aumenta la superficie de exposición y puede encarecer la revisión de permisos.

La primera defensa es la minimización: escoger únicamente sociedades y tablas justificadas por un caso de uso. La segunda está en la configuración y explotación de Fabric: establecer permisos de workspace, control de acceso a los elementos, modelos que filtren información, seguridad por filas cuando proceda y clasificación adecuada de los datos. Es igualmente importante verificar la residencia, las políticas de retención, la compartición y los procedimientos frente a accesos indebidos.

En organizaciones con múltiples filiales, un riesgo frecuente es ofrecer a una persona la visión consolidada que necesita para tomar decisiones, pero permitirle accidentalmente navegar a datos de sociedades para las que no tiene autorización. La solución no es esconder una columna en un gráfico. Es construir el acceso a partir de roles, etiquetas, modelos y pruebas con perfiles reales. Una revisión de cumplimiento debe incluir tanto el dato bruto replicado como los modelos y paneles que lo exponen.

También conviene definir el ciclo de vida del acceso técnico. La documentación preliminar describe una identidad de aplicación en Microsoft Entra, credenciales de conexión y permisos para interactuar con el workspace. Las credenciales deben almacenarse y rotarse de forma segura; no aparecer en capturas ni documentos de soporte. Los equipos de seguridad deben saber qué cuenta técnica se utiliza, qué permisos tiene y quién responde de su renovación o revocación.

Las preguntas frecuentes publicadas por Microsoft indican que Business Central no incorpora, en esta fase documentada, un cargo adicional de licencia o consumo por el propio mirroring. Pero eso no equivale a un proyecto gratuito. Se necesita una capacidad de Microsoft Fabric activa y pueden existir costes de capacidad, almacenamiento adicional, consumo de consultas y modelos, configuración, pruebas, seguridad, mantenimiento y soporte. Además, las condiciones de una vista previa pueden modificarse antes de su disponibilidad general.

La documentación general de mirroring en Fabric explica que la réplica puede contar con determinadas franquicias de almacenamiento según la capacidad contratada y que ciertas operaciones de replicación no consumen las unidades de capacidad de la misma manera que las consultas analíticas. No debemos convertir esos conceptos generales en una cotización automática para Business Central: dimensionar el caso exige comprobar volumen, capacidad disponible, cargas concurrentes y reglas comerciales vigentes.

El análisis económico debería comparar dos escenarios completos. El primero es el coste actual de extracción, mantenimiento, actualizaciones, errores y tiempo del personal que prepara la información. El segundo es el coste de la nueva plataforma analítica y del trabajo necesario para que los usuarios realmente obtengan mejores informes. Si se contabiliza solo el precio de Fabric y se ignora el mantenimiento actual, la comparación estará sesgada. Si se asume que una función de preview ahorrará horas desde el primer día, también.

Una buena evaluación puede empezar con un único caso de negocio. Supongamos que el equipo financiero dedica varias jornadas a consolidar información de sociedades. Deben medirse las horas actuales, cuántas desaparecerían razonablemente, qué incidencias se corrigen, cuántos usuarios se benefician y cuánto cuesta mantener el nuevo proceso. No es imprescindible prometer porcentajes espectaculares: un ahorro modesto, repetible y demostrable puede justificar mejor la inversión que una estimación ambiciosa sin evidencia.

Desde el punto de vista de la demanda comercial, conviene explicar este coste total antes de solicitar una reunión. Un CIO no necesita que le aseguren que la nube será más barata; necesita identificar qué integraciones se simplifican, cuáles permanecerán, cómo se gobernará el dato y qué cargas afectarán a la capacidad. Un CFO busca criterios verificables. Alinear ambos objetivos suele acelerar la decisión más que centrar la conversación en la novedad tecnológica.

Este orden reduce un error habitual: invertir primero en la infraestructura y buscar después qué problema resuelve. En proyectos de datos, la presión por «tener todas las tablas» es comprensible, pero introduce retrasos y complejidad. Empezar con un conjunto pequeño, bien definido y conciliado permite corregir el modelo antes de que lo utilicen decenas de informes. También facilita detectar requisitos no previstos, como una extensión que modifica una tabla crítica o una sociedad con criterios distintos de valoración.

El piloto debe terminar con una decisión, no solo con una demostración técnica. Si la nueva arquitectura mejora frescura, gobernanza o coste total, se puede ampliar. Si los informes actuales ya son suficientes, quizá la prioridad sea depurar maestros o reorganizar indicadores antes de replicar datos masivamente. Una evaluación profesional también debe permitir concluir que todavía no es el momento adecuado.

Otro riesgo es convertir el modelo analítico en una copia de la lógica interna del ERP. Business Central contiene tablas y campos preparados para procesos transaccionales, no necesariamente para consumo directivo. Una métrica como «ventas netas» debe describir cuándo se contabiliza, qué documentos incluye, cómo se tratan abonos y descuentos y qué sociedad o moneda se considera. Sin esa capa semántica, el informe reproduce el detalle técnico y deja al usuario la tarea de interpretarlo.

Por último, cada ampliación debe considerar la operación futura. No basta con que el proveedor configure la primera réplica. La empresa debe poder responder quién comprueba las sincronizaciones, qué ocurre si se interrumpe una carga, cómo se informa de una incidencia al CFO y quién aprueba el acceso de un nuevo equipo. El mantenimiento del dato es una responsabilidad compartida entre aplicaciones, plataforma, seguridad y negocio.

Los agentes de IA y las experiencias de análisis conversacional necesitan una capa de información coherente. Una réplica de Business Central hacia OneLake puede formar parte de esa base, al aportar datos de facturación, compras, inventario o contabilidad. Pero no se debe presentar como un acceso transaccional directo: consultar información consolidada y ejecutar una operación en el ERP son necesidades diferentes, con permisos, interfaces y controles distintos.

En un escenario de análisis financiero, el equipo puede utilizar Power BI para construir un modelo que relacione ventas, cobros y rentabilidad, y después incorporar experiencias de consulta y análisis según las capacidades disponibles en su entorno. En un escenario de previsión de demanda, los datos históricos del ERP pueden combinarse con campañas, estacionalidad y comportamiento de clientes. Aquí la calidad de los conjuntos de entrenamiento, las hipótesis del modelo y la validación humana pesan tanto como la frescura de la réplica.

La integración con una estrategia Azure + IA empresarial permite ir más allá de la visualización. Ayesa365 desarrolla este planteamiento en su hub de arquitectura Azure para agentes inteligentes. El vínculo lógico no consiste en que Mirroring convierta automáticamente los datos en agentes, sino en preparar información bajo un gobierno común para que pueda reutilizarse en iniciativas posteriores.

También es importante evitar que los usuarios confundan una respuesta plausible con una cifra autorizada. Cualquier experiencia de IA que consulte resultados financieros debería apoyarse en métricas documentadas, fechas de actualización visibles y políticas claras para datos sensibles. Si el agente debe desencadenar una acción —por ejemplo, bloquear un pedido, modificar un límite o aprobar un pago—, la ejecución debe pasar por aplicaciones y procesos autorizados, no por una consulta a la réplica analítica.

La conversación entre esos perfiles suele revelar por qué fracasan algunos proyectos de datos. Dirección general espera decisiones más rápidas, finanzas pide reconciliación, tecnología habla de pipelines y operaciones necesita actuar antes de que aparezca un problema. El diseño correcto debe traducir esas prioridades en una secuencia de entregas: una métrica confiable, un modelo reutilizable, usuarios responsables y una forma sencilla de comprobar el resultado.

Antes de solicitar una propuesta comercial, tiene sentido elaborar una ficha de alcance de una página: objetivo, sociedades y tablas, información sensible, usuarios, frecuencia deseada, informes prioritarios, capacidad existente y situación actual. No hace falta definir toda la arquitectura en esa fase, pero sí lo suficiente para evitar que cada departamento imagine un proyecto distinto.

Ayesa Digital trabaja sobre el ecosistema empresarial de Microsoft, combinando experiencia en Dynamics 365 Business Central, aplicaciones de negocio, Azure, Power Platform, Power BI y proyectos de datos e inteligencia artificial. Esa combinación resulta relevante en escenarios como Mirroring: la tecnología de réplica pertenece a la plataforma, pero la interpretación del dato exige comprender cómo se registran compras, ventas, costes, inventario y operaciones en el ERP.

En una primera conversación, el foco debería estar en identificar si la situación actual merece una arquitectura de este tipo. Una empresa puede requerir modernizar integraciones API, ordenar su modelo Power BI, consolidar varias sociedades o crear un producto de datos empresarial. Mirroring será una opción a evaluar, no necesariamente la respuesta para todos los casos. Esta independencia de criterio favorece inversiones más sostenibles y evita implantar complejidad que después nadie utiliza.

La capacidad de conectar ERP, CRM, datos e IA también permite abordar escenarios transversales: margen por cliente que combine ventas y servicio; aprovisionamiento alineado con previsión comercial; control de proyectos conectado con finanzas; o análisis de explotación inmobiliaria. El objetivo es una arquitectura que pueda crecer por dominios sin multiplicar definiciones de negocio, copias innecesarias y herramientas de reporting aisladas.

Las referencias a estados de preview, requisitos y límites corresponden a las guías de Microsoft disponibles en la fecha de elaboración. Las capacidades previstas no son una garantía contractual de disponibilidad, rendimiento o precio. Para cualquier decisión de inversión conviene contrastar documentación, licencias y estado del entorno.