Image Terraform migration from Grafana OSS to All Quiet

Migrating from Grafana OSS to All Quiet: Reducing your IaC maintenance efforts for better long-term health

📉 Learn how migrating from Grafana OSS to All Quiet’s Terraform provider reduces your IaC maintenance overhead by consolidating escalation resources into simpler, hierarchical tiers.

Updated: Tuesday, 17 February 2026

Published: Tuesday, 17 February 2026

For modern SREs, if it isn't in code, it doesn't exist. One of the common frustrations about migrations is the overhead of translation and manually rebuilding your integrations, escalations and schedules from scratch.

Grafana OnCall OSS required a more fragmented approach to Terraform. To get a single alert to a human, you currently need to manage a web of resources: a "shift", a "schedule", an "escalation_chain", and multiple "escalation" steps.

When we built the All Quiet Terraform Provider, we took a different approach. We focused on logical consolidation.

The Problem: Fragmented Resource Management

In the Grafana provider, you’re managing the "position" of every escalation step.

Terraform


# The "Grafana" Way: Managing manual indexes
resource "grafana_oncall_escalation" "step_1" {
  type     = "notify_on_call_from_schedule"
  position = 0 
}
resource "grafana_oncall_escalation" "step_2" {
  type     = "wait"
  duration = 300 
  position = 1 
}

    

This model is solid, but produces an overhead for maintenance. If you want to insert a new step in the middle of a chain, you have to manually re-index every subsequent resource. This increases the risk of state drift and makes PR reviews a headache. Should your admin change, this can result in quite the effort to understand.

The All Quiet Solution: Hierarchical Tiers

All Quiet consolidates rotations and escalations into a single, hierarchical resource: allquiet_team_escalations. By using a Tiers Array, the order of your code blocks is the order of your escalation.

Terraform


# The All Quiet Way: Hierarchical and Consolidated
resource "allquiet_team_escalations" "sre_team_escalations" {
  team_id = allquiet_team.sre.id
  escalation_tiers = [
  {
      schedules = [
        {
          schedule_settings = { selected_days  = ["mon", "tue", "wed", "thu", "fri"] ...
          }
          rotation_settings = { repeats = "weekly" ...
          }
          rotations = [
            {
              members = [
                {
                  team_membership_id = allquiet_team_membership.sre_member_1.id
                },
                {
                  team_membership_id = allquiet_team_membership.sre_member_2.id
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

    

Why This Matters for Your Migration

By migrating to All Quiet, most teams see a massive reduction in their IaC to be maintained.

  • Cleaner State: Fewer resources mean faster terraform plan times and fewer API calls to your provider.
  • Auditability: When a new engineer looks at your repo, they see the escalation flow in a single block of code, not scattered across five files.
  • Reduced Maintenance: You no longer need to manage separate "shifts" and "schedules." The rotation logic is baked directly into the escalation tier.

This migration is your chance to pay down technical debt. You aren't just "moving" your on-call; you're refactoring it for better long-term health.