Soporte Business Central después del go-live: qué debería exigir una empresa a su partner

El SaaS elimina parte del mantenimiento técnico, pero no elimina la necesidad de soporte, conocimiento, pruebas, evolución ni gobierno.

Después del arranque empieza una etapa distinta: estabilizar, resolver incidencias, preparar actualizaciones, controlar extensiones, revisar integraciones, acompañar usuarios y decidir qué mejorar. Un buen soporte Business Central no se limita a cerrar tickets; protege la continuidad y convierte el ERP en una plataforma que sigue evolucionando con el negocio.

El go-live no cierra el proyecto: cambia el tipo de trabajo que necesita Business Central

Durante una implantación, casi toda la atención está puesta en llegar al arranque: datos, configuración, integraciones, formación, pruebas y cutover. Después del go-live aparece otro conjunto de problemas. Los usuarios descubren excepciones que no salieron en las pruebas, determinados procesos necesitan ajustes, una integración presenta errores intermitentes, un cierre mensual revela fricciones y las primeras actualizaciones empiezan a poner a prueba extensiones y desarrollos.

Business Central online reduce una parte importante del mantenimiento de infraestructura porque Microsoft gestiona la plataforma y el servicio. Sin embargo, eso no significa que la empresa pueda olvidarse del ERP. Microsoft mantiene un modelo de actualización continua con dos grandes ciclos anuales y actualizaciones menores en otros meses. Esas actualizaciones incorporan funcionalidades, mejoras, correcciones y cambios regulatorios. El cliente necesita saber qué impacto tienen sobre su solución concreta, especialmente cuando existen extensiones, integraciones o procesos críticos.

Por eso el soporte después del go-live debería cubrir dos dimensiones. La primera es operativa: resolver incidencias, dudas, errores y bloqueos. La segunda es evolutiva: preparar actualizaciones, revisar novedades, mantener integraciones, formar usuarios, reducir deuda técnica y decidir qué mejoras aportan valor. Si el partner solo atiende la primera dimensión, Business Central corre el riesgo de quedarse funcionalmente congelado aunque Microsoft siga evolucionando la plataforma.

Qué debería incluir realmente un servicio Business Central después del go-live

Un servicio útil necesita más que un buzón de incidencias. Debe existir un punto único de entrada, clasificación por prioridad, escalado funcional y técnico, responsables claros y visibilidad sobre estado y tiempos. El usuario debe saber dónde acudir y la empresa debe poder distinguir una consulta funcional de una incidencia técnica, una petición evolutiva o un problema que requiere intervención del fabricante.

El soporte funcional es especialmente importante en los primeros meses. Muchas incidencias no son fallos del producto sino dudas sobre cómo ejecutar un proceso, interpretar un asiento, corregir un dato o utilizar una función. Un equipo que conozca configuración, finanzas, compras, ventas, inventario, proyectos o fabricación puede resolver el problema sin convertir cada consulta en desarrollo.

El soporte técnico entra cuando hay extensiones, integraciones, APIs, errores, rendimiento o comportamiento anómalo. El partner necesita capacidad de analizar código, revisar dependencias y escalar a Microsoft cuando corresponda. Si funcional y técnico trabajan separados, el cliente termina actuando como coordinador entre varios equipos.

Por último, el servicio necesita una capa evolutiva. Business Central cambia, el negocio cambia y las integraciones cambian. Un modelo de soporte maduro ayuda a convertir incidencias repetidas en mejoras, a priorizar backlog y a preparar un roadmap para que el ERP siga acompañando al negocio.

Dos grandes ciclos al año y actualizaciones menores: qué debe hacer el partner

Microsoft documenta dos ciclos principales de actualización de Business Central cada año, con versiones mayores en abril y octubre. En los meses intermedios se publican actualizaciones menores que pueden incorporar mejoras, correcciones críticas y cambios regulatorios. En Business Central online, Microsoft mantiene la aplicación y la plataforma y el administrador puede gestionar ventanas y fechas de actualización desde el centro de administración.

Esto cambia el significado tradicional de mantenimiento. En un ERP on-premises antiguo era posible retrasar versiones durante años. En Business Central SaaS, el modelo es continuo. La pregunta ya no es si actualizar, sino cómo preparar la actualización con suficiente antelación para evitar que una extensión, integración o proceso crítico falle cuando cambia la versión.

El partner debería revisar el calendario, analizar novedades, validar compatibilidad de extensiones, mantener sandbox y pruebas, revisar integraciones y acordar una ventana que minimice riesgo. En una empresa con cierres, campañas, picos logísticos o procesos estacionales, la fecha importa. Microsoft ofrece flexibilidad dentro del periodo de actualización, pero alguien debe gobernar esa decisión.

También conviene diferenciar entre probar todo y probar lo crítico. No todas las funciones necesitan la misma profundidad de test. Un modelo de regresión debería cubrir cierres, facturación, compras, integración bancaria, logística, fabricación, interfaces, verticales y cualquier proceso cuyo fallo tenga impacto material.

Los primeros 90 días después del go-live deberían tener un modelo distinto al soporte ordinario

Los meses posteriores al arranque concentran una mezcla de incidencias, aprendizaje y decisiones pendientes. El equipo todavía está interiorizando procesos, determinados casos reales aparecen por primera vez y algunas configuraciones necesitan ajustes. Tratar este periodo como soporte ordinario puede diluir problemas estructurales entre tickets individuales.

Una estabilización seria debería identificar incidencias recurrentes, diferenciar errores de formación, detectar procesos que generan demasiada fricción y revisar integraciones con mayor frecuencia. El objetivo es reducir progresivamente el volumen de casos y no acostumbrarse a convivir con workarounds. Si una misma incidencia aparece cada semana, el servicio debe buscar la causa y no limitarse a resolverla una y otra vez.

También conviene revisar el cierre mensual, los primeros ciclos de compras, ventas, inventario o producción y cualquier proceso que no tuviera suficiente volumen durante el piloto. Los usuarios clave deben participar porque muchas mejoras surgen cuando el ERP se enfrenta a la operación real. Un buen partner convierte esas observaciones en acciones priorizadas.

Al terminar la estabilización, debería quedar una base clara: documentación, backlog ordenado, responsables, integraciones monitorizadas, conocimiento compartido y un modelo de soporte ordinario dimensionado según la criticidad real del entorno.

El mayor riesgo del soporte suele estar en lo que diferencia tu Business Central del estándar

Dos entornos Business Central pueden compartir versión y tener niveles de complejidad completamente distintos. Extensiones propias, verticales, apps de AppSource, integraciones, automatizaciones y desarrollos heredados pueden convertir el soporte en una tarea sencilla o en una investigación permanente. Por eso el partner necesita conocer el mapa real de personalizaciones.

Cada extensión debería tener propietario, código o repositorio accesible cuando corresponda, documentación suficiente y una estrategia de compatibilidad con nuevas versiones. Si un desarrollo crítico depende de una persona concreta o de un proveedor que ya no participa, la empresa tiene un riesgo operativo que debe hacerse visible.

También conviene revisar si una personalización sigue siendo necesaria. Business Central incorpora continuamente nuevas capacidades. Una función que hace tres años requería desarrollo puede ahora resolverse con estándar, configuración, Power Platform o una app mantenida. El soporte evolutivo debería identificar estas oportunidades para reducir deuda técnica.

El objetivo no es eliminar todas las extensiones. Es asegurar que cada una aporta valor suficiente para justificar su mantenimiento y que no bloquea actualizaciones ni obliga a conservar procesos obsoletos.

Cuando Business Central depende de otros sistemas, el soporte debe mirar más allá del ERP

En muchas empresas Business Central está conectado con bancos, e-commerce, CRM, almacenes, producción, nómina, portales, EDI, sistemas fiscales, Power BI, Power Platform o aplicaciones sectoriales. Una incidencia puede manifestarse dentro del ERP y tener su origen en otra plataforma. El servicio necesita capacidad para seguir la transacción de extremo a extremo.

Las integraciones requieren monitorización, ownership y procedimientos de recuperación. No basta con saber que existe una API. Hay que entender qué ocurre si una llamada falla, si se duplica un mensaje, si cambia una credencial, si un certificado caduca o si un tercero modifica su interfaz. Los casos críticos deberían tener alertas y un proceso de actuación.

También es importante documentar cuentas técnicas, secretos, endpoints, frecuencias, dependencias y responsables. En un cambio de partner, la falta de este inventario es una de las principales fuentes de riesgo. Un entorno puede parecer estable hasta que una integración nocturna falla y nadie sabe quién tiene acceso a la configuración.

El soporte Business Central maduro trata las integraciones como parte de la operación, no como un proyecto antiguo que terminó el día del go-live.

Un Business Central que no evoluciona termina acumulando otra forma de deuda

El hecho de estar en SaaS no garantiza que el ERP siga siendo adecuado. La empresa puede conservar procesos manuales, integraciones frágiles, reporting paralelo o extensiones antiguas durante años. Microsoft actualiza la plataforma, pero el cliente necesita decidir qué capacidades adoptar y qué procesos revisar.

Un modelo de mejora continua debería revisar el backlog de forma periódica. Incidencias repetidas, tareas manuales, cuellos de botella y peticiones de usuario pueden agruparse y evaluarse por impacto. Algunas se resolverán con configuración, otras con formación, otras con Power Automate, Power Apps o Power BI y otras requerirán desarrollo.

Las nuevas capacidades de Copilot y agentes también necesitan criterio. No todo proceso debe automatizarse con IA. El partner debería ayudar a identificar casos donde el dato esté gobernado, la tarea sea repetitiva y el riesgo pueda controlarse. La evolución tecnológica tiene que estar conectada al roadmap del negocio.

Un servicio que incorpora revisiones trimestrales o semestrales permite salir del ciclo de ticket. El cliente puede revisar uso, incidencias, backlog, deuda técnica, novedades, próximos updates y prioridades para decidir dónde invertir.

Un SLA útil no es una tabla bonita: tiene que reflejar el impacto real en negocio

Las prioridades deberían basarse en criticidad y alcance. Una incidencia que bloquea facturación de toda la compañía no puede tratarse igual que una consulta de usuario. Del mismo modo, un error que afecta a un único proceso alternativo no tiene la misma urgencia que una caída general del entorno o una integración que impide cerrar.

El SLA debe definir tiempos de respuesta, escalado y comunicación, pero también qué se considera incidencia, petición y evolutivo. Si todo entra como urgente, el modelo pierde capacidad de priorizar. Si todo se clasifica como proyecto, el cliente percibe que el soporte nunca resuelve nada.

La visibilidad también importa. El cliente necesita saber estado, responsable, próxima acción y si el caso depende de Microsoft, un ISV o un tercero. En incidencias críticas, la frecuencia de comunicación es casi tan importante como la resolución técnica.

El servicio debería medir tendencias: número de casos, recurrencia, tiempos, procesos afectados y volumen de escalados. Estas métricas permiten saber si el entorno se está estabilizando o si el soporte simplemente está absorbiendo problemas sin corregir la causa.

Si el soporte actual no funciona, cambiar de partner no significa cambiar de Business Central

Business Central online pertenece al tenant del cliente. Cambiar de partner no implica migrar automáticamente el ERP ni mover los datos a otra plataforma. Sin embargo, la transición debe revisarse con cuidado porque existen accesos delegados, extensiones, repositorios, integraciones, cuentas técnicas, tickets abiertos, contactos de notificación y conocimiento operativo.

Un cambio ordenado debería empezar con un inventario del entorno. El nuevo partner necesita entender versiones, personalizaciones, apps, integraciones, incidencias recurrentes, próximos updates, contratos con terceros y procesos críticos. La prioridad es que el primer día de servicio no coincida con la primera sorpresa.

También conviene revisar propiedad y acceso a código, credenciales y documentación. Si el proveedor anterior controlaba elementos esenciales sin transferencia clara, la empresa debe recuperar gobierno antes de cerrar la transición. Cuando sea posible, una ventana de solape reduce riesgo.

El cambio de partner puede ser una oportunidad para redefinir el modelo: pasar de un soporte reactivo a Customer Care con seguimiento, backlog, mejora continua y conocimiento compartido. Pero el cambio no debería convertirse en una excusa para modificar de golpe el ERP. Primero continuidad; después evolución.

El soporte es una decisión de continuidad, coste y capacidad de evolución

Para un CFO, el problema de un mal soporte no es únicamente el coste del contrato. Hay impacto cuando una incidencia retrasa cierre, facturación o cobros; cuando una integración obliga a reintroducir datos; cuando un desarrollo necesita reprogramarse en cada versión o cuando el negocio mantiene Excel paralelos porque el ERP no evoluciona.

Para un CIO, el riesgo suele aparecer en dependencia de personas, falta de documentación, accesos opacos, extensiones sin owner y ausencia de observabilidad. Un servicio maduro debería reducir estas dependencias y construir conocimiento compartido para que la organización no quede atrapada en un proveedor o consultor concreto.

Ambos perfiles deberían exigir visibilidad sobre backlog, prioridades, deuda técnica, próximos updates y hoja de ruta. El objetivo es poder anticipar inversión y riesgo, no descubrir cada necesidad cuando ya se ha convertido en urgencia.

Un buen modelo de Customer Care permite transformar el soporte en una capa de gobierno. No elimina incidencias, pero ayuda a reducir recurrencia, ordenar evolución y mantener el ERP preparado para nuevos procesos, automatización y analítica.

Cómo organizar un servicio que no dependa de heroicidades

El soporte necesita un punto único de entrada y un proceso claro de clasificación. El usuario no debería tener que decidir qué consultor funcional o programador necesita. El servicio debe recibir el caso, entender impacto, asignar responsable y escalar cuando corresponda.

El conocimiento tiene que compartirse. Manuales, decisiones, incidencias, soluciones, desarrollos y particularidades deben quedar documentados de forma que el siguiente consultor no empiece desde cero. Esta disciplina reduce tiempos y evita dependencia de personas concretas.

También conviene establecer revisiones periódicas con el cliente. No hace falta convertirlas en reuniones largas. Un resumen de incidencias, tendencias, backlog, próximos updates, riesgos y mejoras proporciona suficiente contexto para tomar decisiones y alinear expectativas.

El modelo puede incluir niveles diferentes según criticidad. Una empresa con producción 24×7, múltiples integraciones y cierres complejos necesita una cobertura distinta a una organización con procesos más simples. El soporte debe dimensionarse sobre el entorno real, no sobre un paquete genérico.

Doce preguntas para saber si tu soporte Business Central está funcionando de verdad

Una empresa puede tener contrato de mantenimiento y seguir sintiendo abandono. La diferencia se detecta con preguntas muy concretas. ¿Sabes quién responde una incidencia crítica? ¿Hay documentación de extensiones e integraciones? ¿Se prueban las actualizaciones? ¿Las incidencias recurrentes generan acciones de mejora? ¿Existe un backlog priorizado? ¿El partner te informa de novedades relevantes o solo aparece cuando abres un ticket?

También conviene revisar ownership. ¿Quién recibe las notificaciones de actualización? ¿Quién controla accesos administrativos? ¿Dónde está el código? ¿Qué ocurre si falla una integración fuera de horario? ¿Quién mantiene las apps de terceros? ¿Cómo se escala a Microsoft? Estas preguntas separan un servicio profesional de una relación basada en conocimiento informal.

Por último, hay que mirar evolución. Si hace dos años que el ERP funciona exactamente igual mientras el negocio ha cambiado, el problema puede no ser técnico, pero sí estratégico. Business Central es una plataforma viva. El soporte debería ayudarte a decidir qué adoptar, qué simplificar y qué dejar de mantener.

Qué debería ocurrir durante un año de soporte bien gestionado

Un servicio maduro tiene ritmos distintos. Diariamente atiende incidencias y consultas. Mensualmente revisa tendencias, integraciones y casos abiertos relevantes. Antes de cada actualización importante prepara sandbox y pruebas. Trimestralmente revisa backlog, deuda técnica y oportunidades de mejora. Y al menos una vez al año conviene revisar arquitectura, extensiones, seguridad operativa y roadmap.

Esta cadencia evita que toda la relación se base en urgencias. Si la única conversación con el partner ocurre cuando algo falla, nadie está mirando de forma sistemática la salud del entorno. Las actualizaciones llegan, las apps evolucionan y el negocio cambia sin una visión consolidada.

También ayuda a presupuestar mejor. La empresa puede separar un coste recurrente de soporte de una bolsa de evolutivos o proyectos mayores y decidir con antelación qué iniciativas tienen prioridad. Esto reduce compras reactivas y facilita justificar inversión ante dirección.

El resultado esperado no es ausencia total de incidencias. Es un entorno más predecible, con menos recurrencia, mejor documentación, actualizaciones controladas y una hoja de ruta que convierte la plataforma en un activo que mejora con el tiempo.

Soporte, cambio de partner, actualización y evolución de Business Central

El soporte está conectado con gobierno, continuidad, actualización y roadmap. Estas páginas permiten profundizar sin mezclar todas las intenciones en una única URL.

Business Central online exige preparar un modelo continuo de actualización

Microsoft indica que Business Central online sigue un calendario de actualizaciones con dos grandes ciclos al año, normalmente en abril y octubre, y actualizaciones menores en los demás meses. La plataforma y la aplicación están mantenidas por Microsoft, mientras administradores y partners pueden gestionar ventanas, fechas y notificaciones desde el centro de administración.

Microsoft también ofrece periodos de preview para preparar las versiones mayores y recomienda probar nuevas funcionalidades y compatibilidad de extensiones antes de la actualización. Esto refuerza una idea importante: la infraestructura SaaS reduce mantenimiento, pero no elimina la necesidad de pruebas ni de gobierno del cambio.

En septiembre de 2026, Business Central 2026 release wave 1 se encuentra en la serie 28.x y Microsoft continúa publicando actualizaciones menores. Por eso un servicio Customer Care debe estar preparado para un producto que evoluciona de forma continua, no para una versión estática.

El soporte correcto debe hacer que Business Central sea cada año más predecible, no más dependiente

La mejor señal de madurez no es tener muchos tickets cerrados, sino reducir recurrencia, documentar mejor el entorno, preparar las actualizaciones con menos tensión y convertir las necesidades del negocio en un backlog ordenado. Cuando el servicio funciona, la empresa entiende mejor su plataforma, depende menos de conocimiento individual y puede decidir con anticipación qué mantener, qué mejorar y qué retirar.

Soporte funcional, técnico y evolutivo para mantener Business Central operativo y preparado para crecer

El enfoque de Customer Care de Ayesa combina punto único de entrada, soporte funcional, escalado técnico, seguimiento, documentación, evolutivos y revisión de novedades. El objetivo es proteger continuidad y reducir dependencia de conocimiento disperso.

Empezar con una revisión del entorno

Antes de dimensionar el servicio conviene revisar versión, extensiones, integraciones, incidencias, expectativas de negocio y nivel de cobertura necesario.

Conocer Customer Care

Si tu soporte solo aparece cuando abres un ticket, probablemente estás aprovechando poco la plataforma

Podemos revisar tu entorno, nivel de servicio, incidencias, extensiones, integraciones, actualizaciones y backlog para proponer un modelo de soporte ajustado a la criticidad real de Business Central.

Revisar nuestro soporte Business Central

Qué conviene revisar

Versión, número de usuarios, extensiones, integraciones, procesos críticos, cierres, incidencias recurrentes, próximos updates, soporte actual, SLA esperado y necesidades evolutivas.

¿Tu modelo de soporte acompaña de verdad la operación y la evolución del ERP?

Cuéntanos cómo funciona hoy el servicio, qué incidencias se repiten, qué extensiones e integraciones existen y qué nivel de cobertura necesitas. Podemos ayudarte a valorar un modelo de Customer Care más sólido y predecible.