Primero, una aclaración
Cambiar de partner no significa cambiar de Business Central
Business Central online pertenece al tenant del cliente. El partner puede vender suscripciones, prestar soporte, administrar entornos mediante permisos delegados y desarrollar o instalar extensiones, pero el ERP no debería estar “secuestrado” dentro de una infraestructura propiedad del proveedor como ocurría en determinados modelos históricos. Esto reduce mucho el riesgo de transición, siempre que el cliente conozca y controle sus dependencias.
Microsoft separa además la relación comercial de la capacidad administrativa. Una relación de reseller permite al partner comercializar licencias; el acceso administrativo se gestiona mediante relaciones delegadas, hoy especialmente GDAP. El cliente puede retirar privilegios administrativos sin que eso implique necesariamente cancelar de inmediato la relación de suscripción. Esa separación es importante durante una transición porque permite ordenar el cambio por fases.
Por tanto, el cambio no debería planificarse como una migración tecnológica salvo que exista además un proyecto de tenant, versión, localización o arquitectura. Debe planificarse como un handover de responsabilidad: identificar qué controla el partner saliente, transferir lo que corresponda, crear los accesos del entrante, validar soporte y asegurar que ninguna dependencia queda sin propietario.
No cambia automáticamente
Tenant, datos, usuarios, configuración funcional y entorno productivo pueden seguir exactamente donde están.
Sí debe revisarse
Acceso delegado, soporte, contratos, licencias, extensiones, repositorios, integraciones, monitorización, entornos y conocimiento.
Paso 1 · Accesos
GDAP, partner access y permisos: saber quién entra es la primera condición del cambio
Microsoft utiliza Granular Delegated Admin Privileges para conceder a partners permisos administrativos con alcance y duración definidos. En Business Central, el acceso delegado permite que usuarios del partner administren y soporten el entorno según los roles concedidos. Un cambio de partner debe revisar qué relaciones siguen activas y qué nivel de privilegio tiene cada organización.
Además, el centro de administración de Business Central permite gestionar acceso de partners a nivel de entorno. Microsoft documenta que se puede permitir o denegar el acceso de tenants de partner concretos y que esta configuración puede persistir incluso si cambia el acceso a nivel de tenant. Esto significa que retirar una relación sin revisar el entorno no es suficiente como procedimiento de cierre.
La transición debería terminar con una foto clara: partner saliente sin acceso que ya no necesita, partner entrante con el mínimo acceso necesario y cuentas internas del cliente capaces de administrar la relación. El principio es simple: el cliente debe poder explicar en cualquier momento qué organización externa puede entrar en producción y con qué finalidad.
Relación GDAP
Revisar roles delegados, duración, grupos asociados y necesidad real de cada privilegio.
Partner access por entorno
Confirmar quién tiene permitido entrar en producción y sandboxes y limpiar configuraciones heredadas.
Administración interna
Asegurar que el cliente conserva usuarios con permisos suficientes para controlar el cambio sin depender de un tercero.
Cierre de acceso
Retirar permisos del saliente cuando la transición esté validada y conservar evidencia de la fecha y alcance del cierre.
Paso 2 · Soporte
El ERP puede seguir funcionando y, aun así, el cliente quedarse sin saber a quién llamar
Microsoft considera al partner la primera línea de soporte para muchos clientes de Business Central. El centro de administración permite configurar información de contacto de soporte y destinatarios de notificaciones. En un cambio de partner, estos datos deben actualizarse. Parece menor hasta que ocurre un incidente crítico y los avisos siguen llegando a cuentas del proveedor anterior.
También hay que trasladar la operación: incidencias abiertas, errores conocidos, ventanas de mantenimiento, próximos updates, personalizaciones con riesgo, tickets escalados a Microsoft, acuerdos con ISVs y cualquier workaround que el equipo saliente conozca. Una transición sin ese inventario puede parecer limpia durante dos semanas y fallar en el primer cierre, actualización o integración nocturna.
El nuevo partner debería asumir soporte con una fase de conocimiento antes de que termine completamente el anterior. Cuando sea posible, una ventana de solape permite validar accesos, revisar los casos críticos y ejecutar una operación real con acompañamiento. No se trata de pagar dos soportes indefinidamente. Se trata de comprar continuidad durante el punto de máximo riesgo.
Contactos de soporte
Actualizar datos visibles para usuarios, escalados, buzones y responsables del nuevo servicio.
Notificaciones
Revisar destinatarios de alertas administrativas para que updates e incidencias no desaparezcan en cuentas antiguas.
Tickets abiertos
Documentar estado, prioridad, workaround, responsable y cualquier escalado ya iniciado con Microsoft o terceros.
Calendario crítico
Cierres, campañas, updates, auditorías o temporadas donde un fallo tendría mayor impacto deben formar parte del plan de transición.
Paso 3 · Extensiones y propiedad intelectual
“Está instalado en Business Central” no significa que el cliente tenga todo lo necesario para mantenerlo
Business Central online utiliza extensiones. Algunas proceden de AppSource y tienen un proveedor claramente identificado. Otras son extensiones per-tenant desarrolladas específicamente para el cliente. En un cambio de partner es esencial distinguirlas porque la capacidad futura de corregir, actualizar o sustituir una extensión depende de quién controla código fuente, repositorio, pipeline, documentación y derechos de uso.
El inventario debería incluir nombre, publisher, versión, origen, funcionalidad, dependencia con otras extensiones, licencia y responsable de mantenimiento. En extensiones personalizadas, el cliente debe saber dónde está el código fuente y bajo qué condiciones puede entregarse al nuevo partner. Si esa respuesta no está clara, existe una dependencia contractual que debe resolverse antes de una actualización urgente.
También conviene identificar personalizaciones que ya no aportan valor. Un cambio de partner puede ser una oportunidad para revisar deuda técnica: extensiones antiguas que sustituyen funcionalidades estándar actuales, desarrollos que nadie utiliza o integraciones construidas para sistemas que ya no existen. No hay que refactorizar todo durante el handover, pero sí saber qué se hereda.
El nuevo partner no debería comprometer estabilidad diciendo que “lo reescribiremos todo”. Primero debe entender. Después clasificar: mantener, corregir, modernizar, sustituir o retirar. Esa secuencia reduce riesgo y evita utilizar el cambio comercial como excusa para introducir un proyecto técnico innecesario.
| Elemento | Qué confirmar | Riesgo si falta |
|---|---|---|
| AppSource | Proveedor, contrato, licencia y compatibilidad. | Renovación o soporte dependiente de un tercero desconocido. |
| PTE personalizada | Código fuente, derechos, repositorio y pipeline. | Imposibilidad de corregir o adaptar tras una actualización. |
| Dependencias | Qué extensiones dependen de otras. | Fallo en actualización o desinstalación. |
| Documentación | Objetivo funcional, configuración y casos especiales. | El nuevo equipo aprende mediante incidencias en producción. |
Paso 4 · Integraciones
El mayor riesgo suele estar fuera de Business Central
Un ERP puede estar estable y depender de una red de procesos externos: e-commerce, bancos, nómina, CRM, almacenes, EDI, portales, facturación electrónica, Power Platform, Power BI, ficheros SFTP, APIs y aplicaciones sectoriales. Muchas de esas integraciones fueron construidas por el partner y pueden utilizar cuentas técnicas, secretos, certificados o servicios que nadie fuera del equipo original documentó.
La transición debe inventariar cada interfaz y clasificarla por criticidad. ¿Qué ocurre si falla una hora? ¿Y un día? ¿Quién recibe la alerta? ¿Dónde está el código? ¿Qué credencial utiliza? ¿Cuándo caduca el certificado? ¿Cómo se reintenta? ¿Existe sandbox para probarla? Esta información permite que el nuevo partner asuma operación antes de que aparezca un fallo.
Power Platform merece una revisión específica. Flujos, conexiones, gateways, entornos, propietarios y service accounts pueden estar vinculados a usuarios del partner o a cuentas personales. Si el proceso de aprobación de compras depende de un flujo cuyo propietario deja de tener acceso, el problema no es Business Central, pero el negocio percibirá que “el ERP ha dejado de funcionar”.
APIs y web services
Endpoint, autenticación, propietario, límites, errores, reintentos y consumidores.
Power Automate
Entorno, conexión, owner, cuenta de servicio, dependencias y alertas de ejecución.
Terceros
EDI, bancos, fiscalidad, verticales y servicios externos con contratos o credenciales propias.
Observabilidad
Dónde se detecta un fallo y quién recibe la señal antes de que el usuario abra una incidencia.
Paso 5 · Entornos y actualizaciones
Producción es solo una parte del servicio: sandboxes, pruebas y calendario de updates también deben cambiar de manos
Business Central online recibe actualizaciones continuas dentro de su ciclo de servicio. El partner suele participar en la validación de extensiones, pruebas en sandbox, resolución de incompatibilidades y coordinación con usuarios clave. Si el cambio coincide con una ventana de actualización, el riesgo aumenta porque el nuevo equipo todavía no conoce dónde suelen aparecer problemas.
El inventario debe incluir entornos existentes, propósito, versión, frecuencia de refresh, datos sensibles, apps instaladas y cualquier automatización de despliegue. También conviene conocer qué pruebas se ejecutan antes de una actualización: procesos de cierre, compras, ventas, integraciones, impresión, facturación, verticales y casos críticos.
Una transición profesional debería completar al menos un ciclo de validación en sandbox. No es necesario esperar meses, pero sí comprobar que el nuevo partner puede desplegar una extensión, interpretar un fallo, revisar telemetría y coordinar una prueba antes de enfrentarse a producción.
Mapa de entornos
Producción, sandboxes, pruebas, desarrollos y propósito de cada uno para evitar despliegues o copias sobre el entorno equivocado.
Plan de actualización
Fechas, pruebas, responsables, extensiones sensibles y criterios para aprobar el paso a producción.
Paso 6 · Telemetría
El nuevo partner no debería necesitar esperar a que un usuario llame para saber que algo falla
Business Central puede enviar telemetría a Application Insights y el ecosistema puede incluir monitorización adicional de Power Platform, Azure o integraciones. En muchas implantaciones esta capa se configura durante el proyecto y después queda en manos de una única persona o suscripción. Durante el cambio hay que revisar dónde se almacenan los datos, quién tiene acceso y qué alertas existen.
La telemetría sirve para entender rendimiento, errores de extensiones, procesos lentos, fallos de integración y comportamiento de la aplicación. Si el nuevo partner empieza sin acceso, pierde una herramienta esencial para distinguir una incidencia puntual de un patrón. Además, comparar las semanas previas y posteriores al cambio ayuda a demostrar que la transición no ha degradado el servicio.
No hace falta construir un centro de observabilidad enorme para una empresa mediana. Sí conviene acordar qué señales son críticas, quién las revisa, qué umbrales generan intervención y cómo se conserva histórico suficiente para diagnosticar.
Paso 7 · Licencias y terceros
Cambiar soporte no debería provocar una sorpresa en la renovación de licencias
Si el partner saliente es también el proveedor CSP, hay que planificar la relación comercial además de la técnica. El cliente debe confirmar suscripciones, fechas de renovación, compromisos, número de usuarios y cualquier producto adicional. Cambiar de proveedor comercial puede tener tiempos y condiciones diferentes a cambiar el acceso administrativo, por lo que no conviene asumir que ambos movimientos ocurren en el mismo minuto.
Las extensiones de terceros añaden otra capa. Algunas se licencian por usuario, tenant, sociedad o volumen; otras incluyen soporte anual del ISV. Si el contrato se gestionaba a través del partner anterior, el nuevo equipo debe saber quién renueva, qué contactos existen y qué ocurre si la licencia caduca. Una app fiscal, logística o sectorial puede ser mucho más crítica para el negocio que una personalización grande.
La recomendación es separar un inventario de “Microsoft” y otro de “terceros”. Esto ayuda a entender qué depende de Partner Center, qué depende de un ISV, qué paga directamente el cliente y qué estaba incluido dentro de una factura global del partner.
Checklist de handover
Los 20 puntos que revisaría antes de dar por completado el cambio
Primeros 30 días
El cambio no termina cuando se firma el contrato con el nuevo partner
Las primeras semanas deberían utilizarse para estabilizar conocimiento y reducir dependencias. El nuevo equipo necesita observar cierres, jobs, integraciones, soporte, despliegues y comportamiento real de usuarios. Es el momento de validar lo recibido, no de lanzar de inmediato una reimplantación completa.
También es una buena oportunidad para priorizar deuda. Durante el handover aparecen extensiones sin propietario, automatizaciones frágiles, cuentas personales, documentación antigua y procesos manuales. No todo debe resolverse ya. Conviene crear un backlog con impacto, riesgo y esfuerzo, separando lo urgente de lo que puede esperar.
Al final del primer mes, el cliente debería disponer de una visión más transparente del entorno que antes del cambio: arquitectura, riesgos, roadmap, responsables y costes. Si el único resultado es que los tickets ahora se envían a otro correo, se ha desaprovechado gran parte del valor de la transición.
Cuándo merece la pena plantearlo
Siete señales de que el problema ya no es una incidencia puntual con tu partner
Cambiar de partner tiene coste. Hay conocimiento acumulado, relaciones personales, procesos compartidos y tiempo de transición. Por eso no debería utilizarse como respuesta impulsiva a un proyecto complicado o a una incidencia mal gestionada. Un buen partner también puede equivocarse, y una relación sana debe permitir corregir.
La decisión empieza a ser razonable cuando el problema es estructural y se repite. Especialmente cuando la empresa siente que ha perdido control de su propia plataforma o que cualquier evolución depende de una relación que ya no responde al nivel de negocio actual.
01. No existe una hoja de ruta
El servicio se limita a tickets y peticiones. Nadie revisa qué debería simplificarse, modernizarse o aprovecharse del estándar actual.
02. Cada cambio tarda demasiado
La organización evita mejorar procesos porque cualquier ajuste requiere demasiadas horas de análisis, desarrollo o coordinación.
03. El cliente desconoce su propia arquitectura
No sabe qué extensiones tiene, dónde está el código, qué integraciones existen ni qué cuentas técnicas mantienen procesos críticos.
04. El soporte es siempre reactivo
Se resuelven incidencias, pero los problemas reaparecen y no se analiza causa, telemetría, rendimiento o deuda técnica.
05. Las actualizaciones generan miedo
Cada wave o cambio de versión se percibe como una amenaza porque existen extensiones frágiles, pruebas manuales y dependencias mal documentadas.
06. No hay visión del ecosistema Microsoft
Business Central funciona aislado aunque existen necesidades claras de Power Platform, Power BI, Microsoft 365, Azure o Copilot que no se conectan con el roadmap ERP.
07. La dependencia del proveedor es mayor que el conocimiento del cliente
Si cambiar de partner parece imposible porque nadie sabe qué ocurriría con código, accesos o integraciones, esa dificultad es en sí misma una señal de riesgo que conviene corregir.
Lo que no aceptaría en un handover
Cinco respuestas que deberían activar una revisión más profunda antes de cerrar el cambio
Una transición no necesita convertir cada detalle en conflicto contractual, pero sí requiere evidencia suficiente para operar. Algunas respuestas aparentemente normales esconden una dependencia que puede aparecer justo cuando el partner anterior ya no está disponible.
“El código está en nuestro servidor, pero no lo vais a necesitar”
Si existe una extensión específica, el cliente debe conocer sus derechos y asegurar la continuidad de mantenimiento. Que hoy funcione no elimina la necesidad de actualizarla mañana.
“Las integraciones funcionan solas”
Toda integración tiene autenticación, límites, errores y un punto de operación. Si nadie sabe quién la mantiene, existe una deuda oculta.
“No hace falta revisar permisos, con quitar nuestro usuario basta”
GDAP, partner access y cuentas técnicas merecen una revisión explícita. La seguridad no debe basarse en asumir que un único usuario representa todo el acceso externo.
“La documentación está desactualizada, preguntadnos si surge algo”
El objetivo del handover es reducir precisamente esa dependencia. Lo crítico debe documentarse mientras el conocimiento sigue disponible.
“Aprovechemos el cambio y rehagamos todo”
Puede haber mucho que mejorar, pero mezclar transición, rediseño, upgrade y nuevas funcionalidades aumenta el riesgo. Primero control y continuidad; después modernización con prioridades.
El día del cambio
Un cutover de partner también necesita un plan, aunque no haya una migración de datos
La palabra cutover suele reservarse para implantaciones, pero un cambio de responsabilidad también tiene un momento de transición. Hay un punto a partir del cual el nuevo partner recibe tickets, administra entornos, responde a usuarios y ejecuta cambios. Si ese momento no está definido, pueden aparecer dos problemas opuestos: que nadie se considere responsable o que dos equipos actúen a la vez sobre producción.
La fecha debería elegirse evitando cierres, campañas, actualizaciones o procesos especialmente sensibles. En los días anteriores conviene congelar cambios no urgentes, cerrar el inventario de incidencias, validar accesos y confirmar quién atiende cada tipo de solicitud. Durante la ventana de cambio, cualquier modificación de producción debe tener propietario y registro.
No es necesario retirar al partner anterior a primera hora y esperar que todo funcione. Puede definirse una secuencia: el entrante recibe acceso, valida sandboxes y telemetría, asume soporte de primer nivel, ejecuta una prueba controlada y, una vez demostrada continuidad, se retiran privilegios que ya no necesita el saliente. La duración dependerá del contrato y del nivel de cooperación, pero la lógica debería ser explícita.
Después del cutover hay que vigilar señales que normalmente pasan desapercibidas: flujos que dejaron de ejecutarse porque pertenecían a una cuenta, alertas que siguen enviándose al buzón anterior, integraciones que funcionan pero no tienen nuevo propietario, jobs que fallan de madrugada y usuarios que todavía abren tickets por el canal antiguo. La transición se considera completa cuando esos puntos están controlados, no cuando se envía la comunicación interna.
Cerrar inventario
Accesos, incidencias, extensiones, integraciones, terceros, contratos y calendario de negocio.
Validar al entrante
Acceso a entornos, soporte, repositorios, telemetría y ejecución de pruebas en sandbox.
Cambiar responsabilidad
Nuevo canal de soporte, responsables claros y control de cualquier cambio sobre producción.
Cerrar privilegios heredados
Retirar accesos innecesarios y verificar que alertas, jobs, flujos y soporte siguen operando.
Cómo evaluar al nuevo partner
No elijas solo por tarifa de soporte: comprueba si puede hacerse responsable de la arquitectura que realmente tienes
Un partner excelente en Business Central estándar puede no ser la mejor opción si el entorno depende de fabricación compleja, una vertical sectorial, integraciones Azure, Power Platform, múltiples países o un volumen importante de desarrollo. El proceso de selección debería partir del mapa técnico y funcional que acaba de construirse para el handover.
Conviene pedir una lectura del entorno antes de firmar una promesa de mejora. ¿Qué riesgos identifica? ¿Qué mantendría? ¿Qué no tocaría durante los primeros meses? ¿Cómo aborda updates? ¿Qué modelo de soporte propone? ¿Tiene capacidad para AL, integraciones, Power Platform y Azure si forman parte de la solución? ¿Puede escalar a Microsoft y a ISVs? Las respuestas permiten diferenciar una propuesta comercial de una capacidad real de asumir responsabilidad.
También importa el modelo de relación. Si el cliente vuelve a depender de una única persona que conoce todo, la vulnerabilidad reaparecerá aunque esa persona sea excelente. Un servicio sostenible necesita documentación, equipo, gobernanza, mecanismos de escalado y revisión periódica del roadmap.
Por último, el nuevo partner debería ser capaz de decir que no. No toda personalización merece rehacerse, no toda incidencia requiere desarrollo y no toda novedad de Microsoft debe implantarse. La calidad de un partner se ve tanto en lo que recomienda hacer como en lo que evita convertir en proyecto.
Cobertura funcional
Finanzas, compras, ventas, inventario, fabricación, proyectos o verticales que sean realmente críticos para la empresa.
Cobertura técnica
AL, APIs, Power Platform, Azure, telemetría, DevOps e integración en la medida en que formen parte del entorno.
Modelo de servicio
SLA, horarios, escalado, equipo asignado, seguimiento y mecanismos para evitar que el conocimiento vuelva a concentrarse.
Roadmap
Capacidad para diferenciar urgencias, deuda técnica y oportunidades de evolución con una secuencia económicamente razonable.
Preguntas frecuentes
Cambiar de partner de Business Central sin interrumpir el negocio
¿Hay que migrar Business Central para cambiar de partner?
Normalmente no. Si el entorno online sigue en el mismo tenant, el cambio puede centrarse en relaciones comerciales, acceso delegado, soporte, código y operación.
¿Qué es GDAP?
Granular Delegated Admin Privileges es el modelo de Microsoft para conceder a partners permisos administrativos granulares y con duración definida sobre servicios del cliente.
¿Puedo quitar acceso al partner anterior y mantener las licencias?
La relación de acceso administrativo y la relación comercial pueden gestionarse por separado. El escenario concreto debe revisarse según CSP, contratos y suscripciones.
¿Quién es propietario de las extensiones personalizadas?
Depende del contrato. Antes del cambio debe revisarse quién tiene derechos sobre el código, dónde está el repositorio y si el nuevo partner puede mantenerlo.
¿Qué ocurre con las apps de AppSource?
Siguen dependiendo de su ISV y condiciones de licencia. Hay que confirmar quién gestiona renovación y soporte y cómo se escala una incidencia.
¿Cuánto solape conviene entre partners?
Depende de complejidad y criticidad. Lo importante es que exista tiempo suficiente para validar accesos, documentación, integraciones y al menos una parte de la operación real.
¿Qué es lo más crítico del handover?
Acceso, código, integraciones y soporte. Son las cuatro áreas que pueden convertir una transición aparentemente administrativa en una interrupción operativa.
¿Es buen momento para actualizar Business Central?
Puede serlo, pero no debería mezclarse automáticamente. Primero estabilizar el cambio de responsabilidad; después decidir si existe un caso técnico y de negocio para modernizar.
Para seguir profundizando
Business Central, partner y evolución de plataforma
Cambiar de partner Microsoft Dynamics 365
La visión general para cambiar de partner en el ecosistema Dynamics 365.
Dynamics 365 Business Central
ERP cloud Microsoft para finanzas, compras, ventas, inventario, proyectos y operación.
Actualizar Business Central
Cuándo una actualización tiene sentido y cómo revisar extensiones, deuda y compatibilidad.
Integraciones Business Central
APIs, Power Platform y sistemas externos que forman parte de la arquitectura real del ERP.
Ayesa · Microsoft
La tecnología importa. La capacidad de conectar arquitectura, proceso y operación importa más.
Ayesa trabaja sobre el ecosistema Microsoft con capacidades que abarcan Business Applications, Azure, datos, Power Platform, Microsoft 365, seguridad e IA. Ese enfoque permite revisar cada decisión dentro de una arquitectura empresarial completa, evitando optimizar una pieza a costa de crear un nuevo silo.
Designaciones, especializaciones y certificaciones sirven como señal de capacidad, pero el criterio relevante para un proyecto es cómo se convierten en una solución gobernable, mantenible y alineada con los procesos reales del cliente.
Fuentes Microsoft
Documentación oficial para preparar el cambio
Cambio de partner Business Central
¿Quieres cambiar de partner sin convertir el handover en un proyecto de riesgo?
Podemos revisar accesos, extensiones, integraciones, entornos, soporte, telemetría y dependencias para preparar una transición ordenada y dejar Business Central bajo control del cliente desde el primer día.
¿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)