Migrá de Opsgenie a All Quiet con Terraform

Si tu configuración de Opsgenie ya vive en Terraform, la migración a All Quiet es un ejercicio de traducción de HCL, no una reconfiguración manual desde cero. Atlassian anunció el cierre de Opsgenie para el 5 de abril de 2027, lo que deja a los equipos SRE y DevOps con tiempo suficiente para migrar sin apuro, pero no con tiempo infinito para procrastinar.

All Quiet es una plataforma de incident management enfocada en equipos SRE y DevOps que prioriza la configuración como código. A diferencia de Opsgenie, que se gestiona mayormente desde la UI de Atlassian, All Quiet expone un provider oficial de Terraform que cubre la totalidad de los recursos desde el primer día.

Por qué migrar: el cierre de Opsgenie en 2027

Atlassian confirmó que Opsgenie dejará de funcionar el 5 de abril de 2027. La idea oficial es que todos los usuarios se muevan a Jira Service Management (JSM), que integra alerting dentro de su suite más amplia de ITSM. El problema, como bien señala la guía técnica de All Quiet publicada en mayo de 2026, es que JSM trae una complejidad que muchos equipos de operaciones no necesitan ni quieren.

Si lo que usás es Opsgenie para on-call scheduling, escalation policies y routing de alertas, meterte en el ecosistema completo de JSM es sobredimensionado. Es como cambiar tu navaja suiza por un maletín de herramientas porque la empresa que fabricaba tu navaja cerró.

¿Y cuándo tiene sentido moverse ahora y no en diciembre de 2026? Simple: si tu configuración ya está en Terraform, cuanto antes migrés, más tiempo tenés para validar que todo funciona igual. Una escalation policy mal traducida que no detectás hasta que hay un incidente real en producción es lo peor que te puede pasar.

Ventajas de una migración Terraform-first

Si ya tenés tus recursos de Opsgenie definidos en .tf, sos de los afortunados. La alternativa, migrar desde la UI de Atlassian a la UI de All Quiet, implica abrir dos consolas en paralelo, copiar nombres de equipos, recrear rotaciones manualmente y rezar para no olvidar ninguna regla de escalación.

Con Terraform el proceso es diferente. Tomás tu código existente, hacés la traducción al provider de All Quiet, corrés terraform plan y ves exactamente qué va a cambiar antes de aplicar nada. Hay un estado explícito, hay un diff, hay reversibilidad. Eso sí: la traducción no es automática, hay que hacerla recurso por recurso.

Mapeo de recursos: Opsgenie a All Quiet en HCL

Acá viene el trabajo real. La guía de All Quiet mapea cada tipo de recurso del provider opsgenie al provider allquiet. Veamos los principales:

Usuarios y equipos

En Opsgenie, los usuarios se gestionan con opsgenie_user y los equipos con opsgenie_team. En All Quiet, los usuarios se invitan por email desde el panel (no se crean programáticamente por diseño de seguridad), pero los equipos sí se definen como allquiet_team con sus miembros referenciados por ID.

Horarios on-call y rotaciones

Los opsgenie_schedule con sus rotation blocks se convierten en allquiet_on_call_schedule. La sintaxis cambia pero la lógica es equivalente: definís los participantes, el tipo de rotación (weekly, daily, custom) y las restricciones horarias. La diferencia más importante es que All Quiet maneja las timezones de forma más explícita, lo que es bueno si tenés equipos distribuidos.

Escalation policies

Los opsgenie_escalation mapean a allquiet_escalation_policy. Cada step de escalación define el tiempo de espera antes de notificar al nivel siguiente, con qué schedule o equipo notificar, y si el paso se repite.

Ponele que tenés esto en Opsgenie:

resource "opsgenie_escalation" "webapp_escalation" {
 name = "webapp-on-call"
 rules {
 condition = "if-not-acked"
 notify_type = "default"
 delay = 0
 recipient {
 type = "schedule"
 id = opsgenie_schedule.webapp.id
 }
 }
 rules {
 condition = "if-not-acked"
 notify_type = "default"
 delay = 5
 recipient {
 type = "team"
 id = opsgenie_team.sre.id
 }
 }
}

El equivalente en All Quiet apunta a los mismos conceptos con nombres de atributos distintos. El delay en minutos, las referencias a schedules y teams, la condición de escalación (si no hay ACK, si no se resuelve) tienen traducción directa.

Integraciones y canales de notificación

Acá la variación es mayor porque depende de qué integraciones uses. Las integraciones de Prometheus, PagerDuty inbound, Grafana, Datadog y similares tienen soporte nativo en All Quiet. El recurso allquiet_integration requiere el tipo de integración y el team al que pertenece. Cada integración genera una URL de ingest única que tenés que actualizar en el sistema origen (Grafana, tu alertmanager, etc.).

Guía paso a paso con Terraform

El flujo de migración que propone el equipo de All Quiet tiene estas etapas:

• Inventario: Corré terraform state list en tu repo de Opsgenie para tener el mapa completo de recursos activos. Esto es tu checklist de migración.
• Configurar el provider de All Quiet: Agregá el provider allquiet al bloque required_providers con tu API key (generada desde el panel de All Quiet).
• Traducir los recursos: Empezá por equipos y usuarios, después schedules, después escalation policies, y por último routing rules e integraciones. El orden importa porque los recursos se referencian entre sí.
• terraform plan antes de apply: Revisá el output con cuidado. Cualquier error de referencia o atributo incorrecto aparece acá, antes de que afecte nada en producción.
• Importar estado existente: Si ya creaste recursos en All Quiet manualmente durante la evaluación, usá terraform import para que el estado local los reconozca y no duplique.

¿Cuánto tarda? Para una configuración mediana (5-10 equipos, 20-30 usuarios, 4-5 escalation policies), estimá entre medio día y un día de trabajo para la traducción y validación inicial.

Ejecutar ambas herramientas en paralelo

No apagues Opsgenie el día que termines la migración en Terraform. El período de coexistencia es lo que te salva si algo falta o está mal configurado.

La estrategia que funciona: una vez que tenés All Quiet configurado y validado con terraform apply, activá las integraciones en All Quiet pero manteniendo las de Opsgenie activas. Las alertas van a llegar a los dos sistemas en paralelo (sí, van a llegar duplicadas, es el punto). Monitoreá durante al menos una semana completa, cubriendo un ciclo de rotación entero, para confirmar que los horarios on-call son correctos, las escalaciones disparan en los tiempos esperados y los canales de notificación funcionan.

Recién entonces, cuando tenés confianza real, desactivás las integraciones en Opsgenie. Dejás el recurso en Terraform por unos días más (comentado, no borrado) por si necesitás hacer rollback rápido. Después lo eliminás.

Análisis de costos: Opsgenie vs All Quiet vs JSM

Para un equipo SRE de 10 personas, la diferencia entre Opsgenie Standard (USD 210/mes) y All Quiet puede ser de USD 100-150/mes. No es el número que te va a cambiar el presupuesto, pero si ya tenés que migrar de todos modos, ir a la opción más barata con mejor soporte de IaC tiene sentido.

El ROI real no es financiero: es la reducción de tiempo operativo. Cada cambio en rotaciones o escalation policies que antes requería clicks en la UI de Atlassian ahora es un PR en tu repo de Terraform, con code review, con historial, con rollback.

Checklist de migración: antes del cutover definitivo

• Todos los equipos y miembros verificados en All Quiet contra el estado actual de Opsgenie
• Horarios on-call probados con al menos un ciclo completo de rotación
• Escalation policies disparadas en ambiente de testing (con alertas de prueba reales, no solo terraform plan)
• Integraciones con sistemas de monitoreo actualizadas con las nuevas URLs de ingest de All Quiet
• Canales de notificación (email, SMS, Slack, PagerDuty) validados para cada miembro del equipo
• Runbooks y documentación interna actualizados con los nuevos links y procedimientos
• Plan de rollback documentado: cómo reactivar Opsgenie si algo falla en las primeras 48 horas post-cutover

Errores comunes en esta migración

Migrar las integraciones sin actualizar los sistemas origen. Generás las integraciones en All Quiet, obtenés las URLs nuevas, aplicás con Terraform, y te olvidás de actualizar el alertmanager.yml o el webhook de Grafana. Las alertas siguen yendo a Opsgenie. Este error es más común de lo que parece.

Asumir que las timezones se copian igual. Si tenés equipos en distintas zonas horarias, revisá cada schedule en All Quiet después de la traducción. La sintaxis de timezone entre providers tiene sutilezas, especialmente con horarios de restricción (no notificar entre las 23:00 y las 07:00).

Apagar Opsgenie antes de completar un ciclo de guardia completo. Una rotación semanal requiere que pase una semana para confirmar que todos los cambios de guardia funcionan. Si apagás Opsgenie después de dos días de prueba, estás asumiendo que lo que no probaste funciona. No asumas.

Esto se conecta directamente con Migrating from Opsgenie to All Quiet: A Full Terraform-First, donde profundizamos el tema.

Esto se conecta perfectamente con Migrating from Opsgenie to All Quiet: A Full Terraform-First, donde cubrimos el tema en detalle.

Preguntas Frecuentes

¿Cómo migrar de Opsgenie a All Quiet usando Terraform?

Agregás el provider allquiet a tu configuración de Terraform y traducís los recursos de Opsgenie (equipos, schedules, escalation policies, integraciones) al equivalente en All Quiet usando los mismos conceptos pero con sintaxis diferente. La guía oficial de All Quiet publicada en mayo de 2026 incluye ejemplos HCL side-by-side para cada tipo de recurso. El proceso toma entre medio día y un día para configuraciones de tamaño mediano.

¿Cuándo cierra Opsgenie y cuál es la mejor alternativa?

Atlassian cierra Opsgenie el 5 de abril de 2027. La alternativa oficial es Jira Service Management, pero para equipos SRE/DevOps que usan Terraform, All Quiet es una opción más enfocada y con mejor soporte de IaC desde el primer día. También existen otras alternativas como PagerDuty, pero All Quiet destaca por su pricing y su filosofía de “incident management cerca del código”.

¿Puedo ejecutar Opsgenie y All Quiet en paralelo durante la migración?

Sí, es la estrategia recomendada. Configurás las integraciones en All Quiet mientras mantenés las de Opsgenie activas. Las alertas llegan a los dos sistemas durante el período de validación (mínimo una semana para cubrir un ciclo de rotación completo). Cuando confirmás que todo funciona, desactivás Opsgenie. El período de superposición es lo que te permite hacer rollback sin impacto si algo falla.

¿Qué costo tiene migrar a All Quiet?

All Quiet tiene plan gratuito hasta 5 usuarios sin límite de tiempo. Para equipos más grandes, el costo ronda los USD 5-10 por usuario por mes según el volumen, lo que es menor que los USD 21/usuario/mes del plan Standard de Opsgenie. El costo de la migración en sí depende del tiempo de ingeniería: estimá entre 1 y 3 días hábiles para la traducción, validación y cutover.

¿Cómo automatizar la migración de escalation policies con Terraform?

Traducís los bloques opsgenie_escalation al recurso allquiet_escalation_policy en tu .tf. Cada step de la policy define el tiempo de espera, el target (schedule o team) y la condición de disparo. Si tenés muchas policies, podés usar un módulo de Terraform con variables para evitar repetición. El proyecto terraform-opsgenie-incident-management de CloudPosse puede servir como referencia de estructura si tu configuración actual no usa módulos.

Conclusión

El cierre de Opsgenie en abril de 2027 es un hecho confirmado por Atlassian. Para equipos SRE que ya gestionan su infraestructura como código, la migración de Opsgenie a All Quiet con Terraform es el camino más ordenado: tomás lo que ya tenés en HCL, lo traducís recurso por recurso y lo validás con el mismo flujo de trabajo que usás para cualquier cambio de infraestructura.

Correr ambas herramientas en paralelo durante una semana antes del cutover no es opcionalidad, es disciplina operativa básica. Una escalation policy que no dispara cuando tiene que disparar a las 3 de la mañana es el tipo de error que preferís descubrir en el período de superposición y no en el primer incidente post-migración.

Si tu equipo usa servidores propios o VPS para correr sistemas de monitoreo y alerting, un hosting con buen soporte DevOps como donweb.com puede ser un complemento natural para este tipo de infraestructura en Argentina.

El tiempo de hacerlo es ahora, no en diciembre de 2026.

Fuentes

• All Quiet – Guía técnica completa de migración Terraform-first (mayo 2026)
• All Quiet Blog – Migrating from Opsgenie to All Quiet
• All Quiet – All Quiet como alternativa a Opsgenie
• GitHub CloudPosse – Módulo Terraform para Opsgenie incident management
• BetterStack – Comparativa de alternativas a Opsgenie