Microsoft sube el BREP en octubre de 2026: qué cambia y cuándo replantear tu ERP
El Enhancement Plan pasa del 20% al 21% del Protected List Price. Parece un punto. En coste de mantenimiento anual, el salto real del ejemplo es del 5%.
Microsoft ha comunicado a sus partners una nueva actualización de los planes de servicio de Dynamics on-premises con efecto desde el 6 de octubre de 2026. Para una empresa que todavía opera con Dynamics AX, NAV u otra solución Dynamics local, la cuestión ya no es solo cuánto sube el mantenimiento. La cuestión útil es si la renovación sigue siendo coherente con el coste, el riesgo y la capacidad de evolución del ERP.
→
21%
En un mantenimiento que era 20.000 €, pasa a 21.000 €. Son 1.000 € más: un incremento del 5% sobre el coste anterior.
La cifra que conviene entender bien
Un punto porcentual no es un 1% más de factura
El anuncio puede llevar a una interpretación demasiado rápida: “Microsoft sube un punto”. Matemáticamente, el cambio del Enhancement Plan anual es de un punto porcentual sobre el Protected List Price, pero el incremento que siente el presupuesto de mantenimiento es mayor.
Si el PLP de las licencias es de 100.000 €, un Enhancement Plan al 20% supone 20.000 € anuales. Al 21%, supone 21.000 €. La diferencia es de 1.000 €. Si calculamos esos 1.000 € frente a los 20.000 € que se pagaban, el aumento del mantenimiento es del 5%.
Ejemplo utilizado para visualizar el impacto.
Enhancement Plan anual al 20% del PLP.
Enhancement Plan anual al 21% del PLP.
1.000 € adicionales sobre los 20.000 € anteriores.
Qué ha comunicado Microsoft
Los cambios previstos desde el 6 de octubre de 2026
La comunicación distribuida a partners dentro de Dynamics Price List indica que la actualización afecta a Enhancement Plan y Advantage Plan para productos Dynamics on-premises adquiridos mediante DPL. También delimita exclusiones y explica el tratamiento de los planes plurianuales. Antes de cerrar una renovación o una oferta, conviene verificar siempre el PLP y las condiciones concretas del contrato.
Aplicable a renovaciones y nuevas ventas desde la fecha efectiva comunicada.
El cambio sigue la misma lógica: incremento de un punto sobre el PLP.
Los planes de pago plurianual existentes mantienen su porcentaje durante el plazo contratado y no pueden terminarse anticipadamente según la comunicación.
Importante: el anuncio excluye Advantage Plus Plans, planes de soporte de SQL embedded y Software Assurance adquirido mediante Enterprise Agreement. La tarifa final debe confirmarse para cada cliente, producto y contrato.
La decisión que importa
La subida no obliga a migrar. Sí obliga a volver a hacer números.
Sería poco serio afirmar que una subida del mantenimiento convierte automáticamente cualquier proyecto cloud en rentable. Hay empresas con Dynamics on-premises que tienen un sistema estable, procesos controlados y una razón válida para mantenerlo durante un tiempo. También hay organizaciones que llevan años pagando mantenimiento, infraestructura, soporte, personalizaciones y trabajo manual porque el ERP “todavía funciona”, aunque cada cambio sea más difícil.
La actualización de octubre introduce un dato nuevo en esa ecuación. No debería analizarse de forma aislada. Debe sumarse al coste de infraestructura, bases de datos, administración, actualizaciones, soporte de terceros, personalizaciones heredadas, interfaces antiguas, dependencia de perfiles escasos y horas internas que se consumen manteniendo operativo un modelo tecnológico que quizá ya no acompaña al negocio.
Por eso, la renovación de BREP puede ser un buen momento para hacer algo que muchas compañías posponen: calcular el coste total de seguir igual durante tres o cinco años y compararlo con una modernización realista. No hace falta empezar por una decisión de producto. Hay que empezar por entender qué coste genera hoy el ERP, qué riesgos acumula y qué capacidades se están dejando fuera.
01. Coste visible
BREP o plan de servicio, infraestructura, SQL, hosting, soporte, mantenimiento de desarrollos y servicios del partner.
02. Coste operativo
Procesos manuales, reconciliaciones, exportaciones a Excel, duplicidad de datos, cierres lentos, interfaces y tareas que dependen de personas concretas.
03. Coste de oportunidad
Automatización que no llega, analítica que requiere reconstruir datos, movilidad limitada, dificultad para integrar CRM, Copilot, agentes o nuevos modelos operativos.
04. Riesgo acumulado
Tecnología fuera de soporte, conocimiento concentrado, personalizaciones difíciles de actualizar, dependencias antiguas y ventanas de cambio cada vez más delicadas.
Una renovación puede ser una señal
No preguntes solo cuánto cuesta mantener Dynamics on-premises. Pregunta qué obtienes a cambio de seguir manteniéndolo.
Si el sistema actual sigue aportando estabilidad y encaja con el negocio, mantenerlo puede ser una decisión racional. Si la empresa paga cada año para conservar una plataforma que limita automatización, integración, reporting o evolución, la comparación cambia por completo.
BREP y soporte: conviene separarlos
Estar al corriente del Enhancement Plan no significa que cualquier versión antigua siga soportada
Microsoft explica en su documentación de ciclo de vida que la inscripción en Enhancement Plan o Software Assurance es necesaria para recibir determinados derechos sobre actualizaciones no relacionadas con seguridad, versiones fiscales y regulatorias y service packs cuando resultan aplicables al producto.
Eso no debe confundirse con el ciclo de soporte de una versión concreta. Un producto puede seguir teniendo licencias perpetuas y un plan de servicio asociado, mientras una versión determinada ya ha alcanzado el final de soporte de Microsoft.
La diferencia es crítica cuando se evalúa el riesgo real: no basta con preguntar si se paga mantenimiento. Hay que identificar versión, ciclo de vida, infraestructura, componentes, soporte disponible, personalizaciones y dependencia operativa.
Microsoft recomienda a los clientes de AX evolucionar hacia las aplicaciones actuales de finanzas y operaciones de Dynamics 365.
Antes de renovar automáticamente
Siete preguntas que Dirección, Finanzas e IT deberían responder juntas
No todas las respuestas conducirán a una migración inmediata. El objetivo es dejar de tratar la renovación como una partida automática y convertirla en una decisión informada.
01. ¿Qué versión tenemos y cuál es su situación real de soporte?
No es lo mismo operar sobre una plataforma actual mantenida que sobre una versión cuyo soporte terminó hace años. Este dato cambia el nivel de riesgo y las alternativas disponibles.
02. ¿Cuánto pagamos realmente por mantener el escenario actual?
Hay que sumar plan de servicio, infraestructura, licencias asociadas, soporte, administración, upgrades, integraciones, desarrollo, backup, seguridad y dedicación interna.
03. ¿Qué personalizaciones siguen siendo necesarias?
Un desarrollo que hace diez años era imprescindible puede haber quedado cubierto por estándar, una extensión moderna, Power Platform o un proceso diferente. Migrarlo sin revisarlo perpetúa deuda.
04. ¿Qué procesos viven ya fuera del ERP?
Si compras, aprobaciones, previsiones, reporting, proyectos o controles dependen de Excel, correo y aplicaciones satélite, el coste de mantener el ERP no refleja todo el coste operativo.
05. ¿Qué crecimiento esperamos en tres años?
Más sociedades, países, usuarios, transacciones, adquisiciones o nuevos canales pueden convertir un sistema hoy estable en un cuello de botella mañana.
06. ¿Qué queremos hacer con datos, automatización e IA?
Copilot, agentes o analítica avanzada aportan poco si los procesos críticos siguen desconectados, los permisos no están gobernados o el dato requiere reconstrucción manual.
07. ¿Qué riesgo tendría no hacer nada hasta la siguiente renovación?
Poner fecha al escenario ayuda. El análisis cambia cuando se proyectan tres renovaciones, varios años de infraestructura y las mejoras que seguirían aplazándose.
Escenarios frecuentes
AX, NAV o Business Central on-premises: la conversación no es exactamente la misma
La subida del plan puede afectar a distintos clientes Dynamics on-premises, pero la decisión tecnológica depende del punto de partida. No conviene meter todos los casos en el mismo saco.
Dynamics AX
En AX 2009 y AX 2012 la cuestión de ciclo de vida pesa mucho. Para organizaciones con complejidad financiera, multisociedad, operaciones avanzadas o gran volumen, la evolución suele evaluarse hacia Dynamics 365 Finance, Supply Chain Management y aplicaciones relacionadas.
Dynamics NAV / Navision
En NAV el análisis debe revisar versión, C/AL, personalizaciones, verticales, datos e integraciones. Microsoft documenta rutas de migración a Business Central online y, según el escenario, puede ser preferible reimplantar parte de la solución en lugar de trasladar toda la herencia.
Business Central on-premises
Aquí la discusión puede centrarse en la conveniencia de seguir operando localmente o aprovechar la ruta hacia Business Central online. Microsoft mantiene herramientas específicas de cloud migration y recomienda evaluar versión, datos, extensiones, infraestructura y gobierno antes de ejecutar el paso.
Si la conclusión es estudiar una migración
No copies tu ERP antiguo en la nube
Uno de los errores más caros de una modernización es asumir que el objetivo consiste en reproducir el sistema anterior con una tecnología nueva. Si la organización arrastra quince años de campos, excepciones, informes, objetos modificados y procesos creados para resolver limitaciones históricas, migrarlos todos sin análisis puede producir un ERP moderno con la misma deuda de antes.
Microsoft, en su documentación actual de migración de NAV y Business Central, insiste precisamente en evaluar el estado de la solución, decidir qué datos deben migrarse, preparar entornos, limpiar información y planificar gobierno y ejecución. Para determinados escenarios de Business Central 14 incluso contempla una vía de reimplantación que traslada datos esenciales sin arrastrar personalizaciones e histórico completo.
Conservar
Procesos que funcionan, diferenciación sectorial real, datos que aportan continuidad y controles que siguen siendo necesarios.
Rediseñar
Circuitos manuales, aprobaciones por correo, reporting reconstruido, integraciones frágiles y personalizaciones que el estándar actual ya resuelve.
Eliminar
Históricos sin valor operativo, duplicidades, campos que nadie usa, automatismos heredados y excepciones que existen porque “siempre se hizo así”.
Añadir
Automatización, analítica, movilidad, integración, gobierno del dato y capacidades de IA cuando tengan un caso de negocio claro.
La comparación correcta no es “BREP frente a licencia cloud”. Debe confrontar el coste total y el riesgo del escenario actual con el coste, el esfuerzo y el valor de una arquitectura objetivo durante un periodo suficiente para tomar una decisión empresarial.
Una comparación útil
Qué mirar en un análisis a tres años
| Variable | Mantener escenario actual | Modernizar |
|---|---|---|
| Plan de servicio | Proyectar la nueva tarifa y futuras renovaciones. | Revisar modelo de suscripción y servicios asociados. |
| Infraestructura | Servidores, SQL, backup, alta disponibilidad, administración y renovación. | Diferenciar SaaS, servicios cloud adicionales e integraciones necesarias. |
| Personalizaciones | Mantener código y conocimiento heredado. | Racionalizar, pasar a extensiones y reducir desarrollos evitables. |
| Integración y datos | Conservar interfaces existentes y asumir su mantenimiento. | Diseñar integración moderna, gobierno de datos y analítica conectada. |
| Riesgo | Valorar ciclo de soporte, dependencia, seguridad y capacidad de cambio. | Valorar riesgo de proyecto, migración de datos, adopción y cutover. |
| Capacidad futura | Medir qué automatizaciones, nuevos procesos o integraciones seguirían limitados. | Cuantificar mejoras realistas, no promesas genéricas de transformación. |
El factor que suele faltar
La deuda técnica no aparece en la factura de Microsoft, pero también se paga
Un ERP legacy puede tener un coste directo razonable y, sin embargo, salir caro. Ocurre cuando el conocimiento está concentrado en dos personas; cuando cada integración requiere un desarrollo específico; cuando actualizar implica meses de pruebas porque nadie sabe qué puede romperse; cuando el reporting depende de extracciones; o cuando la organización evita cambiar un proceso porque tocar el ERP parece demasiado arriesgado.
Esa deuda técnica tiene una característica incómoda: crece sin necesidad de que ocurra ninguna avería. Cada año aparecen nuevas necesidades de seguridad, interoperabilidad, regulación, datos y automatización. Si el sistema no puede absorberlas con facilidad, el negocio construye soluciones paralelas. A corto plazo funcionan. A largo plazo multiplican interfaces, datos duplicados y dependencia.
Por eso la subida de BREP es relevante aunque el importe adicional sea asumible. Funciona como un recordatorio económico de una pregunta que debe responderse con datos: ¿seguimos pagando por una plataforma que queremos conservar o estamos pagando para posponer una modernización que sabemos que tendremos que abordar?
Una regla práctica
Si la organización puede explicar con claridad por qué mantener on-premises aporta más valor que cambiar, existe una decisión. Si la única respuesta es “migrar es complicado” o “todavía funciona”, probablemente existe una deuda que merece medirse.
No existe una única ruta
Business Central o Dynamics 365 Finance: elegir por complejidad, no por inercia
Una empresa que decide abandonar su ERP legacy no debería saltar automáticamente al producto que “parece equivalente”. Business Central y Dynamics 365 Finance cubren necesidades distintas. La elección debe partir de procesos, estructura societaria, internacionalización, volumen, modelo operativo, integraciones, requisitos sectoriales y capacidad de gobierno.
Cuando agilidad y cobertura empresarial pesan más que la complejidad extrema
Finanzas, compras, ventas, inventario, proyectos, fabricación y servicio sobre un ERP cloud integrado con Microsoft 365, Power Platform, Power BI y otras capacidades del ecosistema. Suele encajar bien en compañías medianas y grupos que quieren reducir complejidad heredada sin sobredimensionar el core.
Cuando el gobierno financiero y operativo exige escala enterprise
Más adecuado para organizaciones con múltiples entidades, operación internacional, estructuras financieras complejas, alto volumen transaccional, supply chain avanzada y necesidades corporativas de gobierno, control y estandarización.
Cómo preparar la decisión
Un diagnóstico útil debería acabar con números, riesgos y una hoja de ruta
La revisión no debería convertirse en una auditoría interminable. En pocas semanas debería ser posible obtener una imagen suficientemente fiable para decidir si conviene mantener, actualizar, migrar o planificar una transición por fases.
Inventario técnico y funcional
Versión, módulos, objetos modificados, verticales, integraciones, infraestructura, datos, usuarios, informes, interfaces y dependencias.
Coste total actual
No solo licencias. Incluir mantenimiento, soporte, infraestructura, terceros, horas internas, actualizaciones y costes de procesos manuales relevantes.
Mapa de riesgos
Ciclo de soporte, seguridad, conocimiento crítico, continuidad, datos, integraciones frágiles y dificultad para incorporar cambios regulatorios o de negocio.
Arquitectura objetivo
Business Central, Finance, Power Platform, Microsoft 365, Azure, datos, integración y extensiones solo donde exista una necesidad justificada.
Caso económico
Comparación plurianual entre seguir igual y modernizar, incluyendo inversión, costes recurrentes, ahorro, capacidad ganada y riesgos evitados.
Plan de transición
Fases, datos, pruebas, integraciones, formación, cutover, continuidad, recursos internos y decisiones que deben tomarse antes de comprometer fechas.
El impacto cambia con el tamaño del contrato
Cuánto supone la subida del Enhancement Plan según el PLP
El porcentaje es el mismo, pero el efecto presupuestario no lo es. Una compañía con un PLP relativamente contenido puede asumir la diferencia sin que cambie ninguna decisión. En una base de licencias elevada, el incremento anual empieza a ser una cifra que merece ponerse junto al resto de costes del entorno.
Los siguientes ejemplos son puramente ilustrativos. No sustituyen una cotización ni tienen en cuenta particularidades contractuales, monedas, productos, descuentos o condiciones específicas. Sirven para visualizar la mecánica del cambio del 20% al 21%.
| PLP de referencia | 20% actual | 21% desde octubre | Diferencia anual |
|---|---|---|---|
| 50.000 € | 10.000 € | 10.500 € | +500 € |
| 100.000 € | 20.000 € | 21.000 € | +1.000 € |
| 250.000 € | 50.000 € | 52.500 € | +2.500 € |
| 500.000 € | 100.000 € | 105.000 € | +5.000 € |
El dato más útil no es el incremento de un único año. Una empresa que prevé mantener el escenario durante varios ejercicios debería proyectar mantenimiento, infraestructura y soporte durante ese mismo horizonte. Solo entonces la comparación con una modernización empieza a ser homogénea.
No todo cliente debe correr a la nube
Cuándo no tomaría una decisión de migración solo por la subida del BREP
La peor respuesta a un cambio de precios es convertirlo en una campaña de miedo. Un ERP es demasiado crítico como para decidir su futuro por una diferencia porcentual aislada. Hay escenarios en los que mantener on-premises durante un periodo adicional puede ser perfectamente razonable, siempre que la empresa sepa por qué lo hace y conozca sus riesgos.
El sistema es estable y el horizonte es corto
Si existe un cambio societario, una adquisición, una venta de unidad de negocio o cualquier transformación cercana que vaya a modificar el alcance del ERP, precipitar una migración puede hacer que el proyecto nazca con una foto que estará obsoleta en pocos meses.
La organización no está preparada para absorber el cambio
Un proyecto ERP necesita responsables de negocio, capacidad para validar procesos, limpiar datos, tomar decisiones y formar usuarios. Si esos recursos no existen, empezar por urgencia comercial puede aumentar el riesgo más de lo que reduce el coste.
La arquitectura actual sigue teniendo una justificación concreta
Determinados requisitos de planta, integración, latencia, regulación o dependencia de aplicaciones pueden requerir un diseño específico. “Cloud primero” no significa “cloud sin análisis”. La arquitectura debe responder al negocio.
El caso económico todavía no está construido
Si solo conocemos la nueva tarifa de mantenimiento y una estimación genérica de licencias cloud, todavía no hay caso de negocio. Faltan implantación, transición, integraciones, soporte, infraestructura evitada, eficiencias y coste de oportunidad.
La posición sensata: no usar la subida para forzar una migración, pero tampoco utilizar la complejidad de una migración como excusa para renovar automáticamente otros tres años sin revisar el escenario.
Antes de comprometer presupuesto
Qué debería pedir una empresa antes de renovar su mantenimiento Dynamics
La renovación anual suele llegar al presupuesto como una partida conocida. Precisamente por eso es fácil aprobarla sin revisar los supuestos. Con una modificación de tarifa por delante, merece la pena exigir una foto más completa. No para abrir un proyecto si no hace falta, sino para saber exactamente qué se está comprando y qué alternativas existen.
Confirmación del PLP y de la tarifa aplicable
No presupuestar por aproximación si la renovación es relevante. La base de cálculo y la modalidad del plan deben quedar claras, igual que cualquier excepción contractual.
Situación de ciclo de vida de la versión utilizada
Una organización debería saber si su versión está en soporte, qué actualizaciones son posibles y qué componentes asociados pueden introducir riesgos adicionales.
Inventario de personalizaciones y dependencias críticas
No hace falta documentar todo el ERP desde cero, pero sí conocer qué desarrollos, interfaces y verticales condicionan una actualización o una futura migración.
Proyección de coste durante tres años
Incluir mantenimiento, infraestructura y servicios necesarios para conservar el modelo actual. Una renovación anual puede parecer pequeña si nunca se acumula en el horizonte real de permanencia.
Alternativa de modernización con un alcance realista
No una demo ni una cifra de licencia aislada. Una primera evaluación debe identificar plataforma objetivo, procesos, datos, integraciones, esfuerzo, riesgos y una secuencia de transición creíble.
De agosto a octubre
Qué haría antes del 6 de octubre de 2026 si mi empresa renueva BREP
El margen previo a la entrada en vigor permite actuar con bastante más criterio que esperar a recibir la siguiente renovación. No hace falta lanzar un proyecto ERP en pocas semanas. Sí merece la pena utilizar este periodo para separar las decisiones que son puramente contractuales de las que afectan al futuro de la plataforma.
La secuencia más sensata es sencilla: primero confirmar datos; después calcular; por último decidir si merece la pena abrir un análisis más profundo. Saltarse el primer paso suele provocar comparaciones incorrectas entre cifras que no representan el mismo alcance.
Ahora: confirmar
Identificar plan, fecha de renovación, PLP, versión Dynamics, sociedades cubiertas y condiciones contractuales. Si existe un acuerdo plurianual, revisar su vigencia antes de asumir que la nueva tarifa se aplicará inmediatamente.
Después: proyectar
Calcular el mantenimiento con la nueva tarifa y proyectarlo durante el periodo durante el que realmente se prevé conservar el sistema. Añadir infraestructura, soporte y otros costes relevantes evita comparar una anualidad con un proyecto plurianual.
Antes de renovar: decidir
Si la plataforma está estable y el caso de permanencia es sólido, renovar con conocimiento. Si aparecen riesgos de soporte, deuda técnica o costes crecientes, abrir un diagnóstico de modernización antes de comprometer varios años más.
El objetivo no es llegar a octubre con una migración decidida. Es llegar con suficiente información para que una renovación no sea una decisión automática y para que, si hay que modernizar, el proyecto nazca de un caso de negocio y no de una reacción apresurada al cambio de precio.
Preguntas frecuentes
BREP, Enhancement Plan y migración Dynamics en 2026
¿Cuándo entra en vigor la nueva tarifa comunicada?
La comunicación de Microsoft fija el 6 de octubre de 2026 como fecha efectiva para el aumento de las tarifas anuales de Enhancement Plan y Advantage Plan en renovaciones y nuevas ventas dentro del alcance indicado.
¿Por qué pasar del 20% al 21% equivale a un 5% más de mantenimiento?
Porque la comparación se hace contra lo que se pagaba. Si el mantenimiento era 20 sobre un PLP de 100, pasa a 21. La diferencia es 1. Ese 1 representa el 5% de 20.
¿Todos los contratos Dynamics on-premises están afectados?
No. Microsoft delimita el alcance y excluye, entre otros, Advantage Plus Plans, determinados planes de SQL embedded y Software Assurance adquirido mediante Enterprise Agreement. La situación concreta debe revisarse por contrato.
¿Mantener Enhancement Plan significa que mi versión antigua sigue soportada?
No necesariamente. El plan de servicio y el ciclo de vida de la versión son conceptos distintos. Microsoft publica fechas de soporte para cada producto y versión; deben revisarse de forma independiente.
¿La subida de BREP significa que debemos migrar a la nube?
No. La decisión debe justificarse por coste total, riesgo, procesos, soporte, evolución y caso de negocio. La subida es un motivo razonable para actualizar los números, no una prueba automática de que la migración sea la mejor opción.
¿Qué ocurre con los planes plurianuales ya contratados?
La comunicación indica que los planes de pago plurianual mantienen el porcentaje original durante todo el plazo, aunque no pueden terminarse anticipadamente. Conviene confirmar la situación contractual concreta antes de tomar decisiones.
¿Qué alternativas tiene una empresa con NAV?
Depende de la versión y de la personalización. Microsoft mantiene rutas para evolucionar desde NAV hacia Business Central online. El análisis debe decidir si conviene una migración completa, una reimplantación más limpia o una transición por fases.
¿Y si utilizamos AX 2012?
El ciclo de soporte debe formar parte central del análisis. Para AX 2012 R3, Microsoft finalizó el soporte extendido el 10 de enero de 2023 y recomienda evolucionar hacia las aplicaciones actuales de finanzas y operaciones.
¿Qué datos debemos tener antes de pedir una estimación de migración?
Versión, usuarios, módulos, sociedades, base de datos, volumen, personalizaciones, integraciones, localizaciones, informes, verticales, infraestructura y procesos críticos. Sin ese inventario, cualquier cifra inicial será demasiado aproximada.
Para seguir profundizando
Rutas relacionadas para tomar una decisión con más contexto
Referencias para ampliar
Documentación Microsoft sobre planes, soporte y migración
Las condiciones comerciales deben confirmarse siempre para cada cliente. Para la parte de ciclo de vida y rutas tecnológicas, estas referencias oficiales permiten profundizar en los criterios descritos.
Microsoft Learn · Preguntas frecuentes del ciclo de vida de Dynamics
Microsoft Learn · Ciclo de vida de Dynamics AX 2012 R3
Microsoft Learn · Preparar una migración de Business Central on-premises a cloud
Microsoft Learn · Migrar Dynamics NAV a Business Central online
Siguiente decisión
¿Renovar, mantener o empezar a preparar la migración?
Si tu organización trabaja con Dynamics AX, NAV, Business Central on-premises u otro ERP legacy, podemos revisar el coste actual, la situación de soporte, dependencias, personalizaciones y alternativas. El objetivo es determinar si conviene seguir como estás, preparar una evolución o definir una transición por fases con cifras y riesgos claros.
¿Conectamos?
La tecnología bien aplicada suele facilitar las cosas. Si sospechas que también puede ser de ayuda para ti, concédenos la oportunidad de conocerte y demostrarte hasta qué punto es así.
Suscríbete a nuestra enews mensual, y no te pierdas los mejores contenidos sobre Microsoft Dymanics 365
Información respecto al tratamiento de los datos solicitados, de acuerdo con el RGPD 2016/679 y la LOPDGDD 3/2018: el responsable es Ibermática SA; la finalidad es la recogida y tratamiento de los datos personales que solicitamos para atender tu consulta, enviarte nuestras publicaciones, newsletters, promociones de productos y/o servicios, y recursos exclusivos; la legitimación se establece mediante el consentimiento expreso; no se cederán datos a terceros, salvo obligación legal; en cualquier momento puedes ejercer tus derechos de acceso, rectificación, supresión, portabilidad, limitación u oposición al tratamiento de tus datos, así como retirar el consentimiento prestado o formular reclamaciones ante la Autoridad de Control, enviando la solicitud por correo electrónico a: arco@ibermatica.com; puedes consultar la información adicional y detallada sobre Privacidad y Protección de Datos de Carácter Personal en la Política de Privacidad de Ibermática S.A.
¿Por qué Ayesa?
Somos uno de los principales implantadores de Microsoft, con casi 2000 clientes que han depositado su confianza en nosotros para la implantación de Dynamics 365, Business Central (NAV / Navision) y Dynamics 365 Finance & Operations (AX / Axapta). Además, destacamos en el despliegue de proyectos sobre AZURE y Microsoft 365. Nuestra experiencia en el campo de la inteligencia artificial y el uso de Copilot nos sitúa a la vanguardia de la innovación tecnológica.
Con una plantilla de más de 12.000 profesionales y una sólida presencia en 23 países, estamos comprometidos en ayudar a nuestros clientes a definir y aprovechar oportunidades en el nuevo contexto digital. Desde la tecnología hasta las personas, ofrecemos un enfoque integral que garantiza el éxito en cada proyecto.
- ÚLTIMAS ENTRADAS DEL BLOG -
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)