En esta página
Si gestionas las guardias en Opsgenie, tienes una fecha fija en el calendario y una decisión que tomar antes de que llegue.
Las pautas siguientes son neutrales respecto a proveedores y cubren cuatro temas:
- qué desaparece con el producto
- qué inventariar
- el orden que mantiene la cobertura durante la migración
- cómo dimensionar el esfuerzo
Perstat aparece al final, en la pregunta de la consolidación, no como premisa.
Dos fechas marcan tu calendario
Atlassian puso fin a las nuevas ventas el 4 de junio de 2025 y finalizará el soporte el 5 de abril de 2027. Los clientes actuales pueden añadir plazas hasta el 5 de abril de 2027 y renovar solo si el contrato vence antes de esa fecha, según la página de licencias.
El matiz que gobierna tu planificación es no migrados. La misma página de licencias dice que los datos de clientes no trasladados a Jira Service Management se borran en esa fecha. La documentación de apagado de Atlassian añade que Opsgenie se apaga automáticamente 120 días después de una migración si no lo apagas a mano. Antes de esa fecha, exporta todo lo que quieras conservar fuera de las rutas de migración ofrecidas.
Es una decisión de producto de Atlassian, dicha sin rodeos. No dice nada sobre las herramientas de alrededor y solo fija tu calendario.
Para equipos regulados, conservar el historial de incidentes puede contribuir a la documentación interna y a las notificaciones. DORA se aplica desde el 17 de enero de 2025. Ni un historial exportado ni la herramienta sustituta determinan si DORA se aplica, ni establecen que una organización cumpla la norma.
Haz inventario antes de buscar herramienta
Dedica una hora a la consola de Opsgenie y apunta lo que usas. El inventario puede ser más corto de lo que temías y sacar a la luz dependencias olvidadas. Con cinco categorías basta.
Anota cuadrantes y rotaciones
Apunta quién está de guardia, cuándo y en qué equipos y zonas horarias. Anota también las sustituciones y los patrones de festivos. Son los detalles que se rompen sin hacer ruido después de una migración.
Recoge las políticas de escalado
Apunta cada cadena: a quién se avisa, al cabo de cuánto tiempo y qué pasa cuando nadie confirma. Anota los tiempos, no solo el orden.
Enumera integraciones y fuentes de alerta
Anota cada sistema que abre una alerta:
- herramientas de monitorización
- alarmas del proveedor de cloud
- error trackers
- webhooks
- flujos de correo
Las integraciones pueden exigir bastante trabajo. Hay que redirigir y probar cada fuente en el sistema nuevo.
Documenta el enrutamiento y los equipos
Anota cómo se reparten las alertas entre equipos, etiquetas y prioridades. Las reglas de routing codifican conocimiento de la casa, y un cambio precipitado puede perderlo.
Exporta historial e informes
Esta categoría recoge alertas pasadas, cronologías de incidentes e informes de guardias. Decide qué necesitas conservar. Expórtalo pronto, en el formato que te dé Opsgenie, antes de que termine el acceso a Opsgenie.
Migra en un orden que mantenga la cobertura
No lo cambies todo de golpe. Mantén los dos sistemas en paralelo y mueve las fuentes de alerta de una en una.
- Exporta el historial y los informes ahora, antes de que cambie nada más.
- Completa el inventario de arriba. Después decide entre una sustitución puntual y la consolidación, como describe la sección siguiente.
- Reconstruye los cuadrantes y las políticas de escalado en la herramienta nueva. Al principio, mantenlos idénticos y mejóralos más adelante.
- Redirige las integraciones fuente a fuente. Comprueba que cada una avisa a una persona antes de pasar a la siguiente.
- Mantén los dos sistemas en paralelo durante una rotación completa de guardia. Recorre con pruebas controladas cada ruta de alerta prevista antes del cambio.
- Haz el cambio y retira Opsgenie cuando hayas exportado todo lo que necesitas.
Elige entre sustitución puntual y consolidación
Esta es la decisión de verdad. Dedícale 30 minutos antes de preseleccionar nada.
Opsgenie hace guardias y routing de alertas. Puedes sustituirlo por otra herramienta dedicada a las guardias y dejar el resto del stack como está. Es el camino con menos sorpresas, y para algunos equipos es el correcto.
Piensa en un stack donde las guardias conviven con una monitorización de uptime, una página de estado y un proceso de incidentes separados, de proveedores distintos. Si esos proveedores no comparten datos, la migración es una ocasión para evaluar la consolidación mientras reconstruyes los cuadrantes y rediriges las integraciones.
Ninguna de las dos respuestas es correcta por defecto. Si tus fuentes de alerta están muy metidas en un ecosistema, una herramienta de guardias equivalente puede conservar el flujo de trabajo. Lo mismo vale si dependes de una integración estrecha con Jira Service Management y su ticketing.
Si el problema es la proliferación de herramientas, la migración es un momento práctico para evaluar la consolidación.
Dimensiona el esfuerzo con tu propio inventario
No adoptes una duración genérica. Cuenta estos elementos y asigna a cada uno una persona responsable y una prueba:
- cuadrantes y políticas de escalado
- fuentes de alerta e integraciones
- informes
- equipos
- rutas de formación
El plazo incluye aprobaciones y una fase en paralelo. El trabajo práctico sale del inventario.
Define los criterios de salida antes de fijar una fecha:
- Cada fuente de alerta llega a la ruta prevista.
- Cada cuadrante tiene una persona responsable.
- La confirmación detiene el escalado.
- Un incidente controlado se recupera.
- La ruta anterior sigue disponible hasta superar esas pruebas.
Estos criterios hacen revisable la estimación sin fingir que un único calendario sirve para todas las organizaciones.
Ten a mano una checklist corta
- Exporta primero el historial de alertas, los registros de incidentes y los informes de guardias.
- Inventaría las cinco categorías de arriba y elige entre sustitución puntual y consolidación.
- Reconstruye cuadrantes y escalados idénticos en la herramienta nueva.
- Redirige las integraciones de una en una y prueba cada una.
- Mantén los dos sistemas en paralelo durante una rotación completa.
- Haz el cambio, comprueba tus exportaciones y retira Opsgenie.
Perstat es una opción para consolidar
Si la consolidación está en tu lista, Perstat es una opción que sopesar. Reúne monitorización de uptime, páginas de estado, respuesta a incidentes y guardias en un solo producto. Su control plane en la UE lo opera la empresa alemana Datargo GmbH.
Los conceptos de Opsgenie tienen equivalentes reconocibles:
- Los cuadrantes y las rotaciones de guardia empiezan con Sentinel.
- El push nativo llega mediante las apps de Apple.
- Los SMS personales empiezan con Pulse.
- Sentinel añade el escalado de guardia de push a SMS y llamada.
- La confirmación sigue siendo explícita.
La monitorización que te avisa está en el mismo producto. Once tipos de check regionales, entre ellos HTTP, TCP y DNS, usan hasta seis regiones según el plan y una política regional configurable con un quórum predeterminado de 2. Los monitores agent y heartbeat no usan regiones ni quórum.
Un componente vinculado de la página de estado puede usar el mismo registro del monitor y del incidente. La publicación sigue siendo una acción explícita.
Perstat mantiene un registro de disponibilidad curado. El informe SLA de ejemplo público es un ejemplo editorial, no un informe generado para un cliente. Cada vista de monitor ofrece un informe PDF de 7, 14, 30 o 90 días, sin firmar y sin certificar, y un CSV con manifiesto se facilita manualmente previa solicitud.
Perstat no sustituye a Jira Service Management, al ticketing, al APM ni a la gestión de logs. Si tu operación se apoya en esas piezas, una herramienta dedicada a las guardias encaja mejor. Ese también es un buen resultado de este ejercicio.
La página de comparación con Opsgenie recoge la correspondencia concepto a concepto. Los precios están en la página de precios, sin IVA, y puedes empezar gratis.
Empieza a monitorizar gratis o haz el tour del producto. Puedes hacer el tour sin registrarte y ver los precios sin una llamada comercial.