Migrating from Opsgenie to All Quiet: The Terraform (IaC) Transformation Guide - Part II

TL;DR

Migrating your integrations from Opsgenie to All Quiet allows you to move from a complex, "procedure-based" Terraform (or more precisely HCL) structure to a streamlined, "mapping-based" model. By consolidating Heartbeats, Cron Jobs, and Webhooks into a single resource type and using attribute-based mapping, you can reduce your integration code volume by up to 60% while gaining deeper control over payload data.

Building on our user and team migration guide, we now address the "nerves" of your on-call system: Integrations. While Opsgenie relies on a fragmented system of API integrations and "Integration Actions" to handle alert logic, All Quiet uses a team-centric approach that simplifies your dependency graph.

1. The Logic Shift: From "Responders" to "Team Hubs"

In Opsgenie, the integration is often the "owner" of the alert routing. You define who responds directly within the integration block. This creates a tight coupling where the integration must "know" about users and schedules. In All Quiet, the Team is the central hub. The integration simply feeds the team's unified escalation workflow.

Opsgenie (AWS CloudWatch Integration):

  
resource "opsgenie_api_integration" "cloudwatch" {
  name = "aws-cloudwatch"
  type = "CloudWatch"
  # You must hard-code responders here or in a separate action block
  responders {
    type = "team"
    id   = opsgenie_team.sre.id
  }
}
  

All Quiet (AWS CloudWatch Integration):

  
resource "allquiet_integration" "amazon_cloudwatch" {
  display_name = "AWS Production Alerts"
  team_id      = allquiet_team.sre.id
  type         = "AmazonCloudWatch"
}
  

Note: Because the integration belongs to the team, All Quiet automatically knows which escalation to trigger. No redundant responder blocks required.

2. Unified Integration Logic: Dash0 & Heartbeats

In modern SRE workflows, an observability feed (like Dash0) and a "dead man's switch" (Heartbeat) are two sides of the same coin. Opsgenie forces you to use two different HCL resources with entirely different syntax to manage these. All Quiet consolidates this into a single, predictable resource type: allquiet_integration.

The Observability Feed: Dash0

Dash0 provides high-fidelity OpenTelemetry data. In All Quiet, you simply define the integration type and link it to your team hub.

  
resource "allquiet_integration" "dash0_production" {
  display_name = "Dash0 Production Feed"
  team_id      = allquiet_team.sre.id
  type         = "Dash0" # Standardized integration type
}
  

3. The Heartbeat Showdown: Opsgenie vs. All Quiet

Heartbeat monitoring, ensuring your backup scripts or monitoring agents actually run, is where the technical debt of legacy providers becomes visible.

The Legacy Way: Opsgenie opsgenie_heartbeat

Opsgenie treats heartbeats as a standalone administrative object outside their standard API integration logic. This leads to fragmented HCL where you have to manage specific interval_unit blocks and legacy P3 priority strings that don't always align with your modern severity levels.

Opsgenie Terraform:

  
resource "opsgenie_heartbeat" "backup_check" {
  name           = "database-backup-heartbeat"
  interval_unit  = "minutes"
  interval       = 10
  enabled        = true
  alert_priority = "P3" # Legacy priority mapping
  owner_team_id  = opsgenie_team.sre.id
}
  

The Modern Way: All Quiet HeartbeatMonitor

All Quiet approaches heartbeats as a specialized Integration Type. This means your heartbeat monitor shares the same lifecycle, snoozing settings, and maintenance windows as your Dash0 or AWS CloudWatch feeds.

All Quiet Terraform:

  
resource "allquiet_integration" "heartbeat_monitor" {
  display_name = "Database Backup Heartbeat"
  team_id      = allquiet_team.sre.id
  type         = "HeartbeatMonitor" # Unified resource type
  
  integration_settings = {
    heartbeat_monitor = {
      interval_in_sec     = 600 # 10 minutes defined in seconds
      grace_period_in_sec = 60
      severity            = "Warning" # Maps to modern SRE severity logic
    }
  }
}
  

4. Why This Refactoring Wins for SREs

Consistent State Management: You no longer need to remember different resource names for different "types" of alerts. If it's an incoming signal, it's an allquiet_integration. 60% less code volume while gaining deeper insights into your payload data.

Severity Alignment: You move away from Opsgenie's "P1-P5" legacy system to descriptive, outcome-based severities like Critical or Warning that map directly to your Dash0 observability labels.

Maintenance Parity: Because the Heartbeat is an integration, you can use an allquiet_integration_maintenance_window to mute it during scheduled database maintenance. This process is significantly more manual and policy-driven in Opsgenie.

Summary: Simplifying the "Monitor of Monitors"

By consolidating observability feeds like Dash0 and heartbeat monitors into the same HCL resource structure, All Quiet removes the "special case" logic that plagues Opsgenie migrations. SREs gain a cleaner dependency graph and a predictable way to manage "aliveness" alongside their standard metrics. This shift doesn't just reduce lines of code; it reduces the cognitive load required to maintain a reliable 24/7 on-call system.