How to Migrate Opsgenie Terraform Without Losing Alert Coverage

Separate configuration translation from state migration

A translator can help produce HCL, but matching field names do not prove matching behavior. Rotation start times, escalation stop conditions, timezones, team ownership and maintenance handling may differ between providers. Keep the source configuration, state backup and export in restricted storage; state and saved plans can contain secrets.

Create a destination working directory with its own backend, credentials and pinned provider versions. Confirm its account or organization before planning. Do not rename the source provider and apply against the production state, remove all source resources to “start fresh,” or use state commands as a substitute for understanding the destination object model.

Inventory more than schedules

Reconcile Terraform state with the source API or administrative inventory. An object absent from state may still be actively routing alerts.

Also list heartbeats, outbound webhooks, phone numbers, runbook links, historical exports and objects intentionally being retired. Give every source object one outcome: recreated, mapped to an existing object, replaced by a documented process, or deliberately retired. “Not in the generated file” is not an outcome.

Inspect the installed provider schemas

In each isolated directory, initialize the reviewed provider configuration, then inspect its schema. The schema command (opens in a new tab) describes the installed versions, which is more precise than comparing two latest-version examples.

terraform providers schema -json > provider-schema.json
terraform validate
terraform plan -out=migration.tfplan
terraform show -no-color migration.tfplan

Run these commands only in the intended working directory. Planning reads remote objects and can evaluate configured data sources; review the configuration and use appropriate credentials. Keep migration.tfplan private. It is an executable change plan, not a harmless report to attach to a public issue.

Build a mapping sheet containing source address, source ID, destination address, behavior difference and verification case. If a destination object already exists, use the provider's documented import identifier and inspect the resulting plan. Terraform import (opens in a new tab) associates existing objects with Terraform management; it does not infer the operational equivalence of two providers.

Evaluate migration helpers by their coverage

For a Jira Service Management destination, start with Atlassian's Operations provider migration guide (opens in a new tab). It documents a destination-specific resource and import workflow. Follow the supported mappings for your pinned provider version and review the resulting plan; do not assume its procedure applies unchanged to a different vendor. If an existing destination object is imported, ensure only the intended state manages it going forward.

The official Signals migrator repository (opens in a new tab) documents importing selected objects from Opsgenie and generating destination Terraform. Its existence does not mean arbitrary Opsgenie HCL, maintenance windows and every integration translate automatically. Review the supported-object list, pinned revision, required permissions and generated changes before using any helper.

For custom mapping, start with one team and its complete dependency chain. A schedule without the intended team, integration or escalation is not a useful first migration. Record unsupported fields as unresolved work instead of silently dropping them.

Validate both the plan and runtime

Reject unexpected destruction, duplicate teams, missing members and broadened permissions in the plan. A successful terraform plan is not an apply or a delivery test. With -detailed-exitcode, Terraform documents 0 for no changes, 1 for error and 2 for a valid plan with changes; automation must distinguish these outcomes.

After an authorized apply to the test destination, compare at least four weeks of coverage, including a handoff, leave override, timezone boundary and the fallback when no primary responds. Replay trigger, duplicate and recovery events using a test receiver. Verify maintenance ending restores alerting. Check object counts, but also inspect identities: equal counts can conceal one missing user and one unwanted duplicate.

Cut over one route and preserve rollback

Select a low-risk production route and switch only its sender or routing configuration. Keep exactly one route responsible for real paging while the other receives shadow evidence. Save the old configuration and define the event that triggers rollback, such as an unexplained missing backup notification.

Stop if the destination cannot represent a required behavior. A manual workaround needs an owner and a repeatable check. After acceptance, reconcile drift and revoke obsolete integration credentials through the normal change process. Keep the Opsgenie migration calendar separate from evidence that this particular migration is safe.