Cuándo NO conviene migrar de NAV a Business Central todavía

La decisión antes del proyecto

Business Central puede ser el destino correcto y la migración, prematura

Un director financiero puede recibir una propuesta convincente para migrar su ERP: actualizaciones continuas, menos infraestructura propia, automatización, integración con Microsoft 365 y una base moderna para analítica e inteligencia artificial. Todas esas ventajas pueden ser ciertas. Pero una ventaja tecnológica no convierte cualquier momento en el momento correcto para transformar los sistemas que sostienen la facturación, los inventarios, la fabricación o el cierre de varias sociedades.

Dynamics NAV ha acompañado durante años a organizaciones que cambiaron de tamaño, se internacionalizaron, adquirieron empresas, desarrollaron verticales específicas y añadieron procesos que quizá nunca se documentaron formalmente. En algunos casos, el NAV actual es más que un ERP: es la memoria operativa del negocio. Su complejidad no justifica permanecer indefinidamente en el pasado, pero sí exige saber qué hay dentro antes de decidir cómo salir.

El error más caro no suele ser elegir Business Central. Suele ser aprobar una fecha de arranque, un presupuesto y una ruta de migración antes de haber identificado las dependencias críticas. Entonces aparece la presión por reproducir cada personalización, por conservar todos los históricos y por resolver a última hora las diferencias entre países. El proyecto termina heredando la complejidad que pretendía eliminar.

Esta guía no pretende sustituir la página de migración de NAV a Business Central, que desarrolla el recorrido completo, ni nuestra guía de costes. Se centra exclusivamente en un punto anterior: identificar las condiciones que justifican un no-go, una preparación adicional, una reimplantación o incluso una reconsideración del ERP objetivo.

Seis señales de alerta

Cuándo conviene detener la decisión antes de firmar

Hay una diferencia entre tener un ERP antiguo y tener un ERP listo para sustituirse. La edad del software aumenta ciertas preocupaciones de soporte, seguridad, mantenimiento y capacidades futuras; no revela, por sí sola, cuánto esfuerzo exige trasladar los procesos reales. La evaluación inicial debe descubrir dónde existe conocimiento que no aparece en los manuales y qué fallaría si ese conocimiento no viaja al nuevo sistema.

Estas seis señales no son prohibiciones absolutas. Una empresa puede tener cientos de modificaciones y aun así migrar con éxito si están clasificadas, se conoce su uso y existe una ruta de transformación probada. En cambio, una organización aparentemente sencilla puede estar en situación de alto riesgo por una única integración crítica con almacén o facturación que nadie controla.

Tampoco debe utilizarse el coste como atajo. El presupuesto de una migración depende de versiones, datos, extensiones, pruebas, sociedades, países y cambios en el negocio. Una propuesta de importe reducido puede ser la correcta para un alcance pequeño. Puede ser peligrosa si excluye precisamente lo que hace funcionar la empresa.

El riesgo del código heredado

Muchas personalizaciones no significan que no puedas migrar; significan que debes decidir qué merece sobrevivir

En los entornos NAV maduros, las personalizaciones suelen tener orígenes muy distintos. Algunas se incorporaron para cubrir un vacío real de la versión implantada. Otras respondían a una exigencia de un cliente, a una antigua regulación, a una integración temporal o a una preferencia interna. Unas pocas representan la ventaja competitiva del negocio. Tratarlas a todas como si tuvieran el mismo valor produce dos riesgos opuestos: perder funciones esenciales o pagar por reconstruir código que debería desaparecer.

Para pasar a Business Central online, el modelo de modificaciones del núcleo de NAV debe revisarse. Microsoft documenta la conversión de personalizaciones C/AL a extensiones AL, la necesidad de tratar correctamente los datos de tablas personalizadas y los cambios de arquitectura. No basta con afirmar que una herramienta convertirá todo el código de forma automática: después hay que compilar, rediseñar dependencias, comprobar la semántica de los datos y realizar pruebas funcionales. En especial, .NET interop y otros patrones propios de servidores on-premises no se trasladan sin rediseño a SaaS.

Imaginemos un NAV que calcula descuentos de proyecto con reglas especiales. Antes de convertir el desarrollo, habría que estudiar si esas reglas siguen vigentes, quién las aprueba, qué clientes las necesitan, qué impacto tienen en márgenes y si pueden expresarse con capacidades estándar o una extensión contenida. Ese análisis funcional puede ahorrar más que cualquier automatización de código, porque evita conservar decisiones de negocio que la propia organización ya habría cambiado.

Además, los desarrollos que almacenan datos propios merecen una evaluación distinta de los que solo alteran pantallas o informes. Una tabla personalizada puede contener trazabilidad imprescindible para garantías, litigios, contratos o producción. El inventario debe indicar objetos, tablas, uso, propietario, dependencia, volumen, restricciones de acceso y destino previsto. Sin esa clasificación, una estimación cerrada de conversión resulta débil.

Una empresa también debe decidir si migra con continuidad técnica o reimplanta procesos. Microsoft contempla una alternativa de reimplantación desde Business Central 14 que permite trasladar datos esenciales bajo condiciones específicas, sin pretender reproducir todo el histórico y el código antiguo. Es una opción que exige diseño funcional y una política clara sobre la información que queda fuera; no es una migración de todo NAV por un camino simplificado.

Multinacional no significa estándar global

Localizaciones internacionales: el riesgo que no aparece en una demo de ERP

La internacionalización es uno de los terrenos donde más se simplifica indebidamente una migración. Cuando una empresa opera con varias sociedades y países, no basta con comprobar que Business Central tiene soporte para múltiples empresas y divisas. Hay que verificar que el modelo previsto cubre la forma exacta en que cada entidad factura, liquida impuestos, prepara sus cuentas, opera con bancos, informa al grupo y cumple con las autoridades locales.

Business Central dispone de capacidades de consolidación entre sociedades que pueden usar diferentes planes de cuentas, ejercicios y monedas, incluso entre entornos distintos. Eso es una fortaleza, no una garantía de encaje automático. Hay que configurar y validar conversiones, participaciones, eliminaciones, mapas contables, periodos y reglas específicas del grupo. Una empresa con consolidación compleja debe preguntar quién será responsable de esas reglas y cómo se comprobarán frente a las cuentas históricas.

La localización no equivale a traducir la interfaz. Microsoft combina funcionalidades locales propias y aplicaciones de localización proporcionadas por partners. Según el país, pueden intervenir normas de facturación electrónica, declaraciones fiscales, informes legales, planes contables, bancos y otros requisitos. La disponibilidad de una app en un mercado no implica que cubra todas las excepciones regulatorias de tu empresa; hay que validar alcance, mantenimiento, compatibilidad y responsabilidad de soporte.

Supongamos un grupo con filiales en España, Francia y México. Una implantación piloto puede funcionar en España y no demostrar nada sobre los documentos fiscales, complementos de localización o flujos bancarios de las otras dos entidades. La decisión sensata es ejecutar una prueba por país con escenarios reales y comprobar el circuito completo antes de comprometer una fecha global. No hace falta que todas las filiales migren simultáneamente: puede existir un despliegue por oleadas, pero debe diseñarse bien la convivencia y la reconciliación.

La expansión internacional futura también importa. Si el negocio tiene previstas adquisiciones, apertura de filiales o modelos de operación que exigen mayor control corporativo, la selección debe contemplar la arquitectura de los próximos años. Las licencias, el número de usuarios y el ahorro en infraestructura no son suficientes para decidir la escala del ERP.

Lo que conecta NAV con el negocio

Integraciones e ISV: las dependencias invisibles que pueden bloquear una transición

Una parte del NAV heredado suele operar fuera de la vista de los responsables financieros: intercambio electrónico de documentos, interfaces con almacén, captura de pedidos, sistemas de fabricación, portales de proveedores, trazabilidad, etiquetado, transportistas, bancos, herramientas de cálculo o aplicaciones desarrolladas por distintos proveedores. Algunas interfaces se ejecutan en momentos muy concretos y pueden pasar inadvertidas hasta que falla una operación crítica.

La migración al modelo SaaS exige reconsiderar accesos directos a SQL, componentes locales, trabajos programados y mecanismos de integración que dependían del servidor NAV. No sería riguroso afirmar que todo deja de funcionar: existen APIs, conectores, servicios, extensiones y patrones de integración válidos. Pero el diseño debe cambiar cuando una interfaz presupone control directo sobre base de datos o infraestructura. Y cambiar una interfaz no consiste únicamente en volver a conectarla; hay que preservar semántica, errores, orden de operaciones y capacidad de recuperación.

En una empresa industrial, por ejemplo, el ERP puede comunicar órdenes de fabricación a un MES, recibir consumos reales y trasladar información de calidad. Si esas interfaces no se prueban con excepciones, devoluciones, paradas, diferencias de inventario y cierres de lote, una prueba de “pedido correcto” puede dar una falsa sensación de seguridad. En logística ocurre algo parecido con WMS, radiofrecuencia, rutas y facturación asociada a eventos operativos.

También hay dependencias contractuales de terceros. Un vertical adquirido años atrás puede haber sido actualizado por otro fabricante, haber desaparecido del mercado o requerir una nueva versión para AL. Un contrato de soporte del proveedor original no equivale a un compromiso de compatibilidad con cualquier versión online. Antes de migrar, pide confirmación explícita de la solución objetivo, de sus versiones, de la propiedad de los datos y del responsable de resolver incidencias cruzadas.

Datos que sostienen decisiones

No conviene prometer una migración completa si no sabemos qué histórico merece continuar

El histórico no es una sola cosa. Parte de los registros es imprescindible para continuar operando: saldos, partidas abiertas, pedidos en curso, contratos, inventario, relaciones de datos maestras y trazabilidad de procesos. Otra parte se necesita para auditoría, reclamaciones, garantía o comparativas. Y otra puede almacenarse en un repositorio consultable sin cargar el nuevo ERP con años de datos de escasa utilidad operativa.

La decisión de mover o no mover cada conjunto debe tener un propietario funcional. Finanzas validará balances y libros, compras y ventas revisarán documentos abiertos, operaciones comprobará inventario y proyectos, cumplimiento revisará conservación y acceso, e IT controlará calidad, formato y seguridad. Un dato técnicamente migrado puede seguir siendo un dato incorrecto si perdió su significado o se asignó a la entidad equivocada.

En NAV muy personalizado, los campos añadidos pueden contener información clave para calcular márgenes, reconocer ingresos, determinar impuestos o identificar contratos. No basta con trasladar una columna que tiene nombre similar. Hay que demostrar que el dato conserva la lógica de negocio y que su historial se puede interpretar en el nuevo sistema. Microsoft advierte especialmente sobre las personalizaciones de tablas y la necesidad de gestionarlas adecuadamente al migrar a online.

Una política práctica clasifica los datos en cuatro grupos: operativos esenciales, históricos consultables, registros con obligación de conservación y datos obsoletos o duplicados. Esa clasificación precede al esfuerzo de transformación. El proyecto debe especificar qué queda en Business Central, qué se consulta mediante herramientas externas, cómo se enlaza y qué controles impiden que dos sistemas ofrezcan cifras contradictorias.

La prueba de migración no debería limitarse a verificar que coinciden los números de registros. Debe demostrar conciliaciones completas, accesibilidad a documentos, integridad referencial, coherencia de divisas y que los usuarios pueden cerrar un periodo con resultados defendibles. La calidad de los datos es una condición de entrada del proyecto, no una tarea secundaria que puede resolverse al final.

Elegir bien el momento

El calendario de negocio importa más que la fecha prometida para el go-live

Hay negocios que no pueden permitirse un cambio mayor de ERP durante determinados periodos: un cierre anual, una auditoría, el inventario general, un pico estacional de campañas, una implantación de almacén, una integración de adquisición o una operación industrial de alta carga. En ese contexto, la urgencia del calendario tecnológico debe subordinarse a la continuidad de negocio. Un proyecto correcto puede fracasar por arrancar en la semana equivocada.

Es frecuente que dirección marque el 1 de enero como fecha objetivo por el nuevo ejercicio. Puede ser una buena referencia si existen datos probados, cuentas preparadas, procesos estabilizados y responsables disponibles. Pero puede ser especialmente incómoda para finanzas y operaciones si coincide con ajustes de cierre, inventarios, arranque de presupuestos o ausencia de personal clave. La fecha no debe convertirse en una promesa comercial antes de validar el esfuerzo de cutover.

El modelo de transición debe contemplar ensayos de migración, preparación de entornos, pruebas con usuarios, formación y soporte reforzado. Microsoft recomienda realizar al menos un ensayo completo en un entorno sandbox antes del cambio definitivo. En proyectos exigentes puede necesitarse más de un ensayo, con pruebas de cargas, fallos, excepciones y recuperación. Cada simulación debe producir un informe de tiempos, diferencias, problemas abiertos y acciones correctoras.

La falta de capacidad del negocio es una causa frecuente de subestimación. Si las personas que conocen el proceso real no pueden dedicar tiempo a documentar, probar y decidir, el proveedor trabaja sobre supuestos. Un sponsor ejecutivo puede liberar recursos y resolver prioridades; no puede sustituir a los responsables funcionales de cada país o línea operativa. Antes de aprobar el arranque, define quién firma finanzas, compras, ventas, operaciones, impuestos, integraciones y soporte.

No todo NAV acaba igual

Cuándo debes comparar Business Central con Finance antes de decidir

Cuando un grupo ha crecido mucho, la decisión no es necesariamente “NAV o Business Central”. Puede ser “¿cuál debe ser la arquitectura ERP objetivo para el modelo operativo de los próximos cinco años?”. Una filial relativamente autónoma puede encajar muy bien en Business Central. Otra puede requerir procesos financieros, operativos, de fabricación o supply chain cuyo diseño merece una comparación formal con Dynamics 365 Finance y otras soluciones empresariales.

No recomiendo asociar automáticamente Business Central a empresas pequeñas ni Dynamics 365 Finance & Operations a organizaciones grandes. Hay compañías medianas con una gran complejidad regulatoria o productiva y grupos extensos con procesos muy estandarizados. La decisión se basa en profundidad funcional, gobierno, alcance internacional, operaciones, costes y capacidad de evolucionar. Una arquitectura híbrida de varias aplicaciones puede ser válida, aunque aumentará las exigencias de integración y responsabilidad del dato.

El riesgo de forzar Business Central aparece cuando se intenta resolver mediante decenas de extensiones lo que debería haberse cuestionado en el análisis de encaje. El riesgo contrario también existe: implantar una plataforma corporativa excesiva para un negocio relativamente sencillo, elevando inversión, tiempo de implantación y dependencia externa sin obtener valor proporcional.

Antes de validar el destino, compara procesos críticos sobre escenarios reales, no sobre listas genéricas de funcionalidades. ¿Cómo se ejecuta el cierre de varias sociedades? ¿Cómo se gestionan previsiones y producción? ¿Qué margen de autonomía necesita cada país? ¿Qué información debe consolidar el grupo? ¿Qué integración con CRM, analítica e IA se espera? ¿Qué partes del modelo son comunes y cuáles deben seguir siendo locales?

Para profundizar en esa comparación, resulta útil la comparativa Business Central frente a Finance & Operations y la sesión con Microsoft y Ayesa Digital. Ambas complementan esta guía y evitan que la discusión se limite a conservar o abandonar NAV.

Matriz para comité de dirección

Siete condiciones que justifican un no-go temporal

Una decisión de inversión necesita algo más que una opinión técnica. La siguiente matriz es una herramienta cualitativa de trabajo para preparar un comité de dirección. Sus categorías no son un cálculo automático de riesgo ni sustituyen un assessment. Ayudan a ordenar preguntas y a separar tres situaciones: preparación insuficiente, destino tecnológico incierto y proyecto listo para ejecutarse.

El objetivo de esta matriz no es detener proyectos por precaución excesiva. Es transformarlos en decisiones financiables y ejecutables. Una compañía puede aprobar inmediatamente un diagnóstico que resuelva estas incertidumbres, aunque todavía no apruebe la migración completa. Eso permite avanzar sin convertir riesgos desconocidos en una promesa contractual.

Para decidir formalmente el go/no-go deben definirse criterios verificables: funcionalidades críticas demostradas, conciliaciones aprobadas, integraciones probadas, extensiones compatibles, responsables de país conformes, plan de reversión cuando sea viable, soporte disponible y discrepancias abiertas aceptadas explícitamente por el negocio. El comité no debe confundir un porcentaje de pruebas ejecutadas con la ausencia de riesgos relevantes.

Esperar no es no hacer nada

Qué opciones reales existen si ahora no conviene migrar

Aplazar una migración no significa quedarse inmóvil. La continuidad temporal puede ser razonable cuando se acompaña de un plan explícito de seguridad, soporte, documentación, control de cambios y transición. El error sería convertir “no estamos preparados” en una excusa sin plazo para seguir acumulando deuda técnica. En muchas versiones antiguas de NAV, el soporte y el acceso a correcciones tienen limitaciones concretas: hay que comprobar el ciclo de vida del producto y de cada componente que participa en la operación.

Una continuidad gobernada comienza con un inventario de versiones, servidores, base de datos, componentes, terceros, usuarios privilegiados, copias, restauración y dependencias externas. También debe evaluar exposición, segmentación de red, cambios normativos, accesos remotos y capacidad de resolver una incidencia crítica. Una organización que decide posponer el proyecto necesita conocer el coste y el riesgo de esa decisión, no solo el presupuesto de una migración.

El siguiente paso lógico es una fase acotada de descubrimiento. No tiene por qué ser extensa por definición. Su alcance puede organizarse en procesos representativos, objetos personalizados, interfaces críticas, localizaciones más exigentes y datos problemáticos. Es preferible un piloto que pruebe un circuito completo de negocio a una demostración convincente que solo recorra pantallas estándar.

La reimplantación puede ser una alternativa cuando el NAV actual concentra demasiados desarrollos y datos que ya no representan la forma futura de operar. Esa decisión no consiste en perder el histórico sin control. Supone diseñar qué se conserva en el nuevo sistema, qué se consulta desde un archivo gobernado y qué funcionalidades se reconstruyen. Debe compararse en esfuerzo, continuidad y riesgo con una migración de mayor fidelidad.

No todas las alternativas son equivalentes técnicamente. La ruta soportada depende de la versión de origen, del objetivo, de la arquitectura y de la forma de tratar datos y extensiones. Microsoft explica pasos intermedios desde NAV hacia Business Central on-premises antes de determinados escenarios de online y documenta una herramienta específica de reimplantación desde BC14. Una propuesta seria debe citar la ruta aplicable al cliente, no asumir que todos los NAV migran de forma directa.

De la duda a la decisión financiable

Qué debería entregar una evaluación previa de NAV y Business Central

Para que la decisión sea ejecutable, recomiendo separar dos aprobaciones que a menudo se mezclan. La primera es autorizar un assessment con entregables definidos: mapa del NAV actual, clasificación de código, escenarios de migración, pruebas representativas, riesgo internacional y recomendación de arquitectura. La segunda es aprobar la transformación una vez que el alcance, las responsabilidades y los costes están suficientemente fundamentados.

El assessment debería obtener evidencia de áreas que suelen hablar lenguajes distintos. Dirección financiera necesita ver cierre, consolidación, previsión y control. Operaciones necesita garantizar que el ERP no interrumpe fabricación, inventario, pedidos o entregas. IT necesita un diseño gobernable. Los responsables locales requieren garantías fiscales y capacidad de trabajo. La dirección general necesita saber si se compra una actualización técnica o una oportunidad de rediseñar negocio.

No basta con entregar un documento de arquitectura de alto nivel. Hay que producir un registro de decisiones por personalización, un inventario de interfaces y sistemas de terceros, un mapa de datos y políticas de histórico, un mapa por país y compañía, una ruta técnica condicionada por versiones, un calendario por oleadas y una estimación por escenarios. Las incertidumbres deben figurar como tales; ocultarlas en una cifra cerrada solo traslada el problema al proyecto.

La fase de pruebas necesita escenarios representativos y firmas de negocio. Por ejemplo, desde un pedido de cliente hasta la facturación y el cobro; desde una orden de compra hasta inventario y contabilidad; desde producción hasta coste final; y desde cierre de filial hasta consolidación. En organizaciones internacionales, algunos casos deberán ejecutarse país por país. Las cifras finales deben conciliarse con NAV y las excepciones deben quedar explicadas.

La capacidad diferencial de Ayesa Digital está en ayudar a convertir estas incógnitas en una decisión de negocio. El resultado de esa conversación puede ser Business Central online, una evolución por fases, una reimplantación o una comparación con Dynamics 365 Finance. La oportunidad comercial no está únicamente en ejecutar la migración: también está en definir bien el camino para que el cliente no compre una transformación que todavía no puede absorber.

Escenario ilustrativo

Un grupo internacional con NAV muy personalizado: por qué la fecha no puede ser el primer dato

Consideremos una empresa ficticia de distribución industrial con doce sociedades en siete países. Utiliza una versión antigua de NAV, dispone de modificaciones de tarifas y márgenes, trabaja con varios proveedores de localización, conecta almacenes y mantiene informes de dirección muy personalizados. La dirección se plantea migrar todo a Business Central online antes del cierre del siguiente ejercicio. No conocemos su solución exacta ni su coste: el ejemplo sirve para ilustrar cómo ordenar el análisis, no para presentar resultados de un proyecto real.

El primer error sería considerar que el número de usuarios determina la complejidad. Lo decisivo es que siete países puedan funcionar con sus obligaciones locales, que se conserven las reglas comerciales vigentes y que los pedidos sigan entrando y saliendo de almacenes sin discontinuidades. El equipo debe identificar una sociedad representativa y otra especialmente compleja, probar los principales procesos y decidir si las personalizaciones se sustituyen por estándar o requieren extensiones.

El segundo error sería fijar una única fecha global sin diseñar intercompany, consolidación y coexistencia. Puede que el piloto demuestre que Business Central es correcto para la mayoría del grupo, pero que una filial necesite un plazo adicional para validar su localización. En ese caso, una ruta por oleadas podría proteger el negocio mejor que un arranque total. Sin embargo, habría que valorar los costes y riesgos de mantener temporalmente dos entornos y reconciliar sus datos.

El tercero sería trasladar todos los informes antiguos. La organización debe separar los indicadores realmente utilizados por la dirección, los extractos regulatorios y las consultas históricas. Algunos cuadros podrían reconstruirse con Power BI, otros conservarse en un repositorio consultable y otros desaparecer. Esa decisión reduce complejidad, pero debe respetar las necesidades de auditoría y de trazabilidad.

El resultado del análisis puede ser “sí, migrar por fases”, “sí, pero primero modernizar las interfaces”, “reimplantar parte del modelo” o “revisar si Finance encaja mejor para determinadas entidades”. Ninguna respuesta garantiza por sí sola la adjudicación del proyecto. Lo importante es que Ayesa Digital pueda acompañar a la empresa en una evaluación que culmina en decisiones defendibles y un camino ejecutable.

El coste de quedarse y el de precipitarse

Cómo presentar la decisión al CFO sin simplificarla a licencias y plazos

No conviene confundir aplazar con ahorrar. Continuar en NAV puede implicar soporte especializado, mantenimiento de infraestructura, riesgo de dependencia del conocimiento interno, menor disponibilidad de mejoras y restricciones para introducir integraciones modernas. Migrar de forma precipitada puede generar interrupciones, sobrecostes, deuda técnica trasladada a AL y retrasos en el negocio. Ambos caminos tienen un coste que debe compararse de forma explícita.

El comité debería estudiar al menos tres escenarios de horizonte plurianual: continuidad gobernada con modernización selectiva, migración con preservación de una parte significativa del modelo y reimplantación con mayor estandarización. Para cada alternativa hay que valorar licencias, implementación, desarrollos, interfaces, migración y conservación de datos, pruebas, formación, soporte, convivencia y gestión futura de cambios. También resulta útil reflejar costes de oportunidad: mejoras que no podrán incorporarse mientras se mantenga el escenario actual.

No publicaría una promesa universal de ahorro de una alternativa sobre otra. El coste de una extensión AL depende de su función, de los datos que maneja y de las dependencias que arrastra; el coste de una localización depende del país y de los requisitos. Si se comparan dos ofertas, deben tener un alcance equivalente y declarar las exclusiones. La cifra menor no siempre representa el proyecto más barato, especialmente si deja fuera pruebas, integraciones o soporte posterior.

Tampoco decidiría únicamente por una promoción comercial. Los incentivos vigentes de Microsoft pueden mejorar la ecuación de licencias para clientes elegibles, pero su disponibilidad y condiciones deben verificarse en el momento de contratar. Una promoción con fecha de vencimiento no convierte en segura una migración cuya arquitectura o cumplimiento siguen sin resolverse.

Preguntas que se hacen los decisores

Respuestas directas para preparar una migración de NAV con criterio

Estas respuestas condensan las cuestiones que habitualmente debe resolver un comité antes de aprobar una inversión importante. No sustituyen el análisis de versión, país, funcionalidad y contratos de cada empresa.

Documentación y contenidos relacionados

Recursos para profundizar sin perder de vista la decisión

Las siguientes referencias permiten ampliar la decisión con información específica sobre la ruta técnica, el modelo de personalización, el alcance internacional y los productos Microsoft. Las guías de Ayesa Digital profundizan en la metodología de migración, los escenarios económicos y las alternativas de ERP. La documentación oficial debe revisarse cuando se construya una propuesta, porque versiones, disponibilidad y condiciones pueden cambiar.

Esta guía es informativa y no sustituye una validación técnica, contractual y regulatoria para la versión y los países de cada empresa. Las recomendaciones comerciales de Ayesa Digital deben apoyarse en una evaluación documentada del alcance, de los riesgos y de los requisitos reales del negocio.