Tu aplicación está en la nube, la factura del alojamiento está pagada y el proveedor informa de que su plataforma funciona correctamente. Sin embargo, los clientes no pueden hacer pedidos. Un despliegue ha cambiado la configuración y nadie tiene claro si debe actuar la empresa de hosting, el proveedor de desarrollo o el equipo interno.
Los servicios cloud pueden eliminar mucho trabajo de infraestructura. Sigue siendo necesario decidir quién responde por el recorrido completo del cliente. La diferencia importa especialmente cuando una empresa conecta web, ERP, identidades y servicios de IA a través de varios proveedores. Cada componente puede tener un responsable mientras el proceso de negocio completo no tiene ninguno.
Compra una forma de operar además de capacidad
Las propuestas cloud suelen empezar por nombres de servicios, almacenamiento y coste mensual estimado. Añade una página que explique cómo se operará la solución. Debe indicar quién aprueba cambios, recibe avisos, recupera información y decide que el negocio vuelve a funcionar después de una incidencia.
Utiliza tareas concretas en lugar de etiquetas generales. “Seguridad gestionada por el proveedor” no explica quién retira el acceso de una persona que deja la empresa o revisa los permisos de una integración. “Copias incluidas” tampoco establece quién restaura, dónde se ejecuta el sistema recuperado o cómo se comprueban los datos.
En un portal de pedidos, identifica las dependencias necesarias para completar una compra: acceso, catálogo, precios, pago cuando corresponda, envío al ERP y confirmación. Repite el ejercicio para un empleado que resuelve un pedido fallido. Este mapa suele mostrar huecos que no aparecen en una lista de recursos de alojamiento.
Entiende qué responsabilidades siguen siendo tuyas
La guía de Microsoft distingue servicios de infraestructura, plataforma y software. El reparto cambia según el modelo, pero el cliente conserva responsabilidades sobre datos, identidades y configuraciones que controla. Es una orientación de arquitectura, no un sustituto del acuerdo contratado. Consulta el modelo de responsabilidad compartida de Microsoft.
Convierte ese principio en un responsable concreto para cada tarea. Una base de datos gestionada puede reducir el mantenimiento del servidor, mientras el equipo de aplicación sigue ocupándose de sus cambios de esquema, consultas y permisos. Un servicio de identidades alojado sigue necesitando que tu empresa decida quién tiene cada rol.
Haz visible esta diferencia para quienes aprueban la inversión. La dirección debería entender qué trabajo desaparece, cuál continúa y qué coordinación nueva hace falta. Si no se explica, resulta fácil exagerar el ahorro esperado y dejar sin presupuesto las responsabilidades que permanecen.
Asigna responsables entre proveedores
Organiza un ensayo breve con el ejemplo del pedido fallido. La web indica que todo ha ido bien, pero el pedido no aparece en el ERP. ¿Quién consulta el registro de la solicitud? ¿Quién puede revisar la integración? ¿Quién informa al cliente y quién está autorizado para repetir la operación?
Documenta un responsable principal y una alternativa en cada paso. Incluye la información que necesita cada proveedor para investigar, como horas y referencias de seguimiento. Acuerda cómo compartirla sin enviar una copia innecesaria de los datos del cliente a todos los participantes.
Alguien debe coordinar la incidencia de negocio aunque el fallo corresponda a otro proveedor. Eso no implica que una empresa asuma responsabilidad ilimitada por cualquier problema. Significa que el cliente recibe una respuesta coherente mientras los equipos técnicos localizan la causa.
Elige servicios pensando en quien los mantendrá
Considera la capacidad y experiencia disponibles cuando termine el proyecto inicial. Un diseño que exige intervención especializada cada semana puede ser inadecuado para una empresa con un equipo pequeño, aunque la estimación de infraestructura parezca atractiva.
Pregunta qué tareas elimina cada servicio gestionado y qué límites introduce. Revisa versiones admitidas, comportamiento durante mantenimiento, límites de capacidad, requisitos de red y opciones de recuperación. Anota por qué se elige para que una persona que asuma el sistema más adelante pueda entender la decisión.
La posibilidad de cambiar de proveedor también merece una conversación concreta. Puede ser razonable aceptar una función específica porque aporta valor. Aun así, identifica cómo exportarías los datos, reproducirías las reglas esenciales y recuperarías el control si cambiase la relación comercial. Una exportación demostrada y una lista de dependencias ayudan más que afirmar que todo puede trasladarse a cualquier sitio.
Define la recuperación alrededor de las operaciones del negocio
Un servidor disponible no demuestra que se hayan contabilizado los pedidos de la última hora. Decide qué pruebas hacen falta antes de reanudar el trabajo normal. En un portal, puede ser necesario comparar las solicitudes aceptadas con los pedidos del ERP e identificar los casos que requieren contactar con el cliente.
Separa recuperación de infraestructura y conciliación. Restaurar una base devuelve registros, pero otros sistemas pueden haber seguido trabajando durante la interrupción. El equipo necesita una forma de encontrar operaciones pendientes sin provocar duplicados.
Habla de los objetivos de recuperación con quienes sufren las consecuencias. El tiempo tolerable para un informe interno puede ser distinto del que admite la expedición de pedidos. Documenta esas diferencias y prueba los recorridos importantes. Comprar la misma solución de continuidad para todas las aplicaciones puede simplificar una propuesta sin resolver las necesidades reales.
Haz que la revisión mensual explique el servicio
Una revisión útil combina gasto, incidencias, cambios y riesgos pendientes. Comprueba si el sistema sigue respondiendo a los motivos que justificaron su contratación. Un incremento de coste puede tener sentido si la empresa completa más trabajo valioso; una factura estable también puede esconder un servicio deficiente.
Observa el trabajo repetido además de las grandes caídas. Correcciones manuales recurrentes, integraciones retrasadas o diagnósticos inaccesibles pueden consumir muchas horas sin producir una incidencia espectacular. Acuerda qué problemas se resolverán mediante mantenimiento y cuáles necesitan una decisión de desarrollo independiente.
Actualiza los responsables cuando cambie personal o proveedores. Incluye renovaciones, formas de acceso y ubicación de la documentación operativa. Un sistema cloud no debería depender de que un antiguo colaborador sea la única persona que sabe qué cuenta lo controla.
Para que esa revisión sirva, cada mejora necesita alguien que la asuma y una comprobación de cierre. “Revisar las copias” es demasiado abierto. “Restaurar un entorno de prueba y validar tres operaciones de ejemplo” permite saber qué se ha hecho y qué evidencia falta. Así el seguimiento mensual produce decisiones y no solamente otro informe archivado.
Una revisión práctica con Worktechlabs
En Worktechlabs podemos revisar alojamiento, integraciones y soporte empezando por los recorridos que importan a tus clientes. Para comenzar ayudan un esquema de la aplicación, incidencias recientes, un resumen de costes y la lista de proveedores actuales.
El primer resultado puede ser un mapa de responsabilidades y mejoras priorizadas: cerrar un hueco de acceso, mejorar el seguimiento de errores, ensayar una restauración o simplificar una conexión. Relaciona ese trabajo con un servicio de soporte acordado y un plan de entrega realista. Resulta más fácil valorar la nube cuando puedes explicar quién mantiene el servicio y qué ocurrirá si algo falla.
Guía oficial revisada el 7 de octubre de 2026. Los ejemplos describen prácticas propuestas; las responsabilidades y compromisos deben acordarse para cada aplicación.
