Migrate from opsgenie

Migrate from Opsgenie

Import your Opsgenie setup, verify it would page the same people, then switch with a working undo.

Moving your on-call setup between products is nerve-racking: get one rotation wrong and the wrong person — or no person — gets paged. WarnFire’s migration is built around one promise:

Nothing changes until you press Apply. The importer only reads Opsgenie and builds a draft you can inspect, compare, and rehearse. And if you apply and change your mind, there’s a real undo.

The whole flow lives under Integrations → Opsgenie.

Before you begin

Sign in to the existing destination WarnFire workspace with tenant-owner or tenant-administrator access. In Opsgenie, prepare a configuration-read API key for the correct US or EU account. Do not use a team alert-integration key.

Inventory the current paging configuration and identify an owner for every unsupported or ambiguous item before scheduling a cutover.

Step 1 — Connect (read-only)

1. In Opsgenie, create a read-only API key that can read configuration. (Not an alert-only team key — the connect panel reminds you.)
2. In WarnFire, choose your Opsgenie region (United States or European Union), paste the key, and press Validate and connect.

WarnFire checks the key works, then stores it encrypted. Only the last few characters are ever shown again.

Step 2 — Inventory

Press Run first inventory. WarnFire reads your Opsgenie users, teams, schedules, rotations, overrides, escalation policies, and services, and builds a draft of how each would look in WarnFire.

For a team with one imported Opsgenie schedule, WarnFire drafts the team membership, assigns that schedule as the team’s primary on-call schedule, and maps escalation steps that target the team to a WarnFire team target. This is marked Needs review because Opsgenie evaluates team routing rules, while WarnFire uses the selected primary schedule. Confirm that choice before cutover. A referenced team with no owned schedule, multiple possible schedules, or an unresolvable member remains a blocker rather than silently paging a different set of people.

Every item gets an honest grade:

Click any grade to filter the list. Each item shows the sanitized Opsgenie original side by side with the proposed WarnFire draft.

Step 3 — Read the readiness report

The cutover readiness panel gives a plain go/no-go: either “Ready to cut over” or a list of specific blockers that would break paging (like a schedule referring to a person who wasn’t importable). Warnings are shown too, but only blockers stop you.

Step 4 — Rehearse with shadow runs

WarnFire calculates a schedule comparison for every translated schedule. It also attempts the alert comparison when the Opsgenie key has the optional permission needed to read recent alerts:

• Schedule shadow — for the next week, hour by hour: would WarnFire page the same person Opsgenie would? Any hour that differs is listed with when, who each system would page, and why.
• Alert shadow — when alert-read access is available, replays a sample of your recent real Opsgenie alerts against the draft and checks whether the person who actually handled each one would have been paged by WarnFire. You get an agreement percentage and the specific divergences. If the key lacks that optional access, the panel says the alert shadow was unavailable rather than presenting it as a passing comparison.

These panels expose the evidence they actually checked. A green schedule result means the translated schedule matched at every sampled instant in the displayed window. A green alert result means every comparable alert in the displayed sample selected the same responder; it does not speak for alerts marked not comparable or for provider behavior outside that sample.

Step 5 — Apply

Press Apply to live configuration. WarnFire creates the responders, teams, schedules, and escalation policies from your reviewed draft — all at once, so there’s no half-migrated state. Anything that couldn’t be translated is returned as a skipped list for manual follow-up (services always need a fresh WarnFire integration key — your Opsgenie credentials are never reused).

Apply works once per inventory, and only when the readiness report says ready.

Step 6 — If you need to undo

Roll back deletes exactly what Apply created — nothing more — and returns the import to its reviewed state so you can adjust and apply again.

One protective rule: if anything the migration created is already in real use (a policy or team attached to a live service, or a responder who has been paged), rollback refuses and deletes nothing, rather than half-unwinding a setup you’ve started relying on.

After the switch

Create fresh WarnFire service integration keys instead of reusing Opsgenie credentials. Point each monitoring tool at WarnFire (Alertmanager or the Events API ), send a test alert per service, and run both systems side by side for a few days before turning Opsgenie notifications off.

Verify it worked

• The cutover readiness panel reports no blockers.
• Every Needs review, Ambiguous, and Unsupported item has been reviewed outside the importer and has an assigned follow-up owner. The current importer shows these classifications but does not record decisions.
• Schedule and alert shadow runs identify the expected responder, or every remaining difference is understood and accepted.
• Apply finishes without a partial configuration and reports every skipped item.
• Each newly created replacement WarnFire service passes the configuration-readiness and end-to-end test .
• Opsgenie notifications remain enabled until the agreed side-by-side period completes successfully.

Next steps

• Create service integration keys , then rotate them safely .
• Clear readiness findings , then test each service .