Checklist de go-live MSP: del onboarding a soporte

El agente ya aparece en verde.

Los endpoints reportan.

El cliente quiere empezar hoy.

Pero operaciones todavía no está lista.

Descarga el checklist de go-live para clientes MSP en XLSX. Incluye 34 criterios, decisión automática, evidencias, bloqueos, excepciones y pestañas en español, inglés y portugués.

El go-live no debería ocurrir cuando alguien dice “ya quedó”. Debe ocurrir cuando el MSP y el cliente pueden demostrar que el servicio está listo para pasar del proyecto de onboarding a la operación diaria.

1) Define qué significa “listo” antes de llegar al go-live

Instalar el agente es un hito. No es el criterio completo de salida.

Un cliente está listo para soporte cuando el alcance, las personas, los accesos, la flota, los controles técnicos y la forma de operar coinciden con lo acordado. Si esa definición aparece hasta la reunión final, cada área llegará con una idea distinta.

NIST recomienda documentar el nivel de servicio, las responsabilidades y las expectativas cuando una empresa contrata servicios administrados. También recuerda que externalizar trabajo no transfiere la responsabilidad que el cliente conserva sobre sus sistemas y datos.

Convierte esa recomendación en criterios observables:

• el alcance firmado coincide con lo que se va a operar;
• los contactos autorizados y suplentes están identificados;
• los endpoints esperados están conciliados;
• los accesos y controles esenciales fueron verificados;
• los pendientes tienen responsable, fecha y tratamiento;
• MSP y cliente aprobaron el traspaso.

Conecta estos criterios con tu matriz de responsabilidades MSP–cliente y con el SLA. El checklist no reemplaza ninguno: confirma que ambos ya pueden ejecutarse.

2) Separa los bloqueos reales de los pendientes que pueden continuar

Un go-live con cero pendientes casi nunca existe.

La pregunta útil no es “¿todo está perfecto?”, sino “¿queda algo que impida prestar el servicio con seguridad y dentro del alcance?”.

Clasifica cada control como bloqueante o no bloqueante:

No uses “pendiente” como escondite. Un bloqueo necesita corrección. Una excepción necesita autoridad, impacto comprendido y fecha de revisión. Un elemento no aplicable necesita una razón.

La plantilla calcula la decisión LISTO sólo cuando todos los controles marcados como bloqueantes están listos, no aplican o tienen una excepción aprobada.

3) Concilia la flota: esperado, descubierto y realmente administrado

El contrato dice 60 endpoints.

La hoja del cliente enumera 57.

El RMM muestra 54 agentes, y cuatro llevan días offline.

Eso no es un detalle para “ver después”. Es una diferencia de alcance que afectará monitoreo, soporte, parches y facturación.

Parte del checklist de onboarding de endpoints y concilia:

1. endpoints esperados por sede o área;
2. dispositivos descubiertos;
3. agentes instalados y reportando;
4. equipos offline o inaccesibles;
5. exclusiones confirmadas;
6. propietario y uso de cada activo dudoso.

Después verifica que los equipos estén agrupados, etiquetados y asociados al cliente correcto. Una consola llena de agentes sin clasificación todavía no es una operación ordenada.

En Lunixar RMM puedes usar inventario, último estado reportado, alertas y resultados de parches como parte de la evidencia. La conciliación y la aceptación del alcance siguen siendo decisiones del proceso MSP–cliente.

4) Verifica accesos, seguridad y recuperación con resultados

Una casilla marcada no prueba que el control funciona.

Antes del go-live, verifica al menos:

• accesos administrativos autorizados y protegidos con MFA donde exista soporte;
• cuentas temporales o del proveedor anterior con responsable y fecha límite;
• alcance del acceso remoto y acciones que requieren aprobación;
• estado conocido del antivirus o protección de endpoints;
• línea base de parches y ventanas de mantenimiento;
• alertas críticas atendidas o aceptadas como excepción;
• respaldos, retención y una restauración representativa;
• contactos para incidentes y continuidad.

La guía conjunta de CISA y otras autoridades para proteger a los MSPs y sus clientes destaca la coordinación de controles como MFA, registros, respaldos, acceso remoto y respuesta a incidentes. El valor está en que ambas partes sepan qué existe, quién actúa y cómo se comprueba.

No guardes contraseñas, secretos o códigos de recuperación dentro del checklist. Enlaza la evidencia y registra dónde vive el secreto, no el secreto mismo.

5) Convierte los riesgos heredados en decisiones visibles

El nuevo MSP hereda cosas incómodas.

Un servidor sin soporte. Una aplicación que no se puede reiniciar. Una cuenta compartida. Un respaldo que nunca fue restaurado.

El go-live no borra esos riesgos. Sólo cambia quién los ve y quién debe actuar.

Para cada riesgo abierto registra:

• descripción e impacto;
• activo o servicio afectado;
• tratamiento propuesto;
• responsable del seguimiento;
• fecha límite;
• control compensatorio, si existe;
• persona que acepta la excepción;
• fecha de vencimiento de la aceptación.

No confundas “el cliente ya sabía” con aceptación. La aceptación necesita quedar asociada a una persona autorizada y a un alcance concreto.

6) Haz un traspaso real al equipo que atenderá tickets

El proyecto de onboarding conoce todos los detalles.

La mesa de ayuda recibe el primer ticket el lunes… y nadie le contó nada.

Antes del traspaso, el equipo operativo debe poder encontrar:

• contactos, sedes, horarios y canales autorizados;
• alcance contratado y exclusiones;
• prioridades y objetivos del SLA;
• sistemas críticos y dependencias;
• accesos y procedimientos de emergencia;
• proveedores externos y responsables;
• pendientes, excepciones y cambios programados;
• runbooks para los casos más probables.

Prueba el flujo con un ticket de ejemplo. ¿Llega al equipo correcto? ¿Se identifica al cliente? ¿Existe el contexto para clasificarlo? ¿El escalamiento fuera de horario funciona?

El go-live termina cuando operaciones puede prestar el servicio, no cuando el equipo de proyecto termina su lista.

7) Obtén aprobación y programa las revisiones de 7 y 30 días

La aprobación debe resumir la verdad, no decorar el cierre.

Incluye:

• controles completados;
• bloqueos resueltos;
• excepciones aprobadas;
• pendientes no bloqueantes;
• fecha y hora efectiva del servicio;
• responsable de operaciones del MSP;
• responsable autorizado del cliente.

Después programa dos revisiones:

1. A los 7 días: valida tickets, alertas, accesos, endpoints offline y problemas de comunicación.
2. A los 30 días: revisa tendencias, pendientes, riesgos, alcance y próximos proyectos con evidencia de los reportes RMM.

Si el alcance cambia durante ese periodo, actualiza el acta y la matriz de responsabilidades. La aprobación inicial no debe congelar una realidad que ya cambió.

8) Descarga el checklist y úsalo como acta de salida

La plantilla contiene 34 controles agrupados en siete fases:

• gobierno y alcance;
• identidad y acceso;
• flota y RMM;
• seguridad y parches;
• respaldo y continuidad;
• operación del servicio;
• traspaso y aprobación.

Incluye listas desplegables, controles bloqueantes, fechas, evidencia, aceptación del cliente y una decisión automática de preparación. Las pestañas ES, EN y PT permiten usar un solo archivo con equipos regionales.

Descargar checklist de go-live para clientes MSP (.xlsx)

Duplica el archivo por cliente. Adapta los controles al contrato, la industria y el nivel de riesgo. Cuando llegue el final de la relación, usa el checklist de offboarding para cerrar accesos, agentes y datos con el mismo nivel de control.

Preguntas frecuentes

¿El go-live significa que no puede quedar ningún pendiente?

No. Puede haber pendientes no bloqueantes con responsable y fecha. Lo que no debe quedar oculto es un bloqueo que impida prestar el servicio o un riesgo que nadie haya aceptado.

¿Quién debe aprobar el go-live?

Como mínimo, el responsable operativo del MSP y un representante autorizado del cliente. En entornos críticos puede ser necesaria la aprobación de seguridad, continuidad, cumplimiento u otras áreas.

¿Una excepción aprobada permite continuar?

Sí, si la persona correcta comprende el impacto, acepta el riesgo dentro de su autoridad y define seguimiento y vencimiento. La plantilla no sustituye el proceso contractual o regulatorio aplicable.

¿Debo incluir contraseñas en la hoja?

No. Guarda secretos en una plataforma adecuada. En el checklist registra que el acceso fue verificado y enlaza la ubicación autorizada de la evidencia sin exponer credenciales.

¿La plantilla reemplaza el onboarding técnico?

No. Es el control de salida. El trabajo técnico ocurre antes; el checklist confirma que sus resultados son suficientes para pasar a soporte.

No declares “listo”. Demuéstralo.

Un buen go-live no necesita una ceremonia enorme.

Necesita criterios claros, evidencia localizable y personas que sepan qué ocurrirá cuando llegue el primer ticket.

Lunixar RMM puede aportar visibilidad de inventario, estado de endpoints, alertas, parches y reportes. El checklist conecta esa evidencia con el alcance, los responsables y las decisiones del cliente.

Conoce Lunixar RMM para MSPs y prueba hasta 5 dispositivos durante 14 días, sin tarjeta.