Migrate from Opsgenie

Atlassian says Opsgenie support ends and its REST APIs remain available until April 5, 2027. A migrated site shuts down automatically 120 days after migration, or an administrator can shut it down sooner, so export required data before that site-specific shutdown date. See Atlassian's migration guidance for the current deadline and Atlassian-managed destinations.

This guide explains how to move the on-call configuration that Moneat can preserve, validate the result, and hand paging over without making an untested overnight switch.

What a migration package can represent

The Moneat on-call migration package can carry these Opsgenie concepts:

What the Opsgenie importer reads

The built-in Opsgenie importer reads:

• Users and teams.
• Schedules and their layers or rotations.
• Overrides.
• Escalation policies and priorities.
• On-call coverage for the next two weeks.

Personal notification rules and contact methods are not imported. Each responder must recreate them under Paging in Moneat.

In a hand-built migration package, schedule coverage is supplied separately so you can compare who is on call now with who would be on call after the import. Historical alert and incident records are not recreated by either path; export those records separately if you need them for audit or reference.

Before you export

Make an inventory of the things that can wake someone up or change the handover:

• People, teams, schedules, rotations, and overrides.
• Escalation policies and priorities.
• Personal notification rules and contact methods that responders must recreate in Moneat.
• Alert integrations and the systems that currently send events to Opsgenie.
• The current responder for each schedule, including upcoming handoffs.
• Any contact details or credentials that will need to be configured again.

Keep the raw Opsgenie export unchanged. Do not use it as the only copy of your migration data while you are transforming records.

Let Moneat read your Opsgenie account

You do not need to build anything by hand. On Settings → On-call Migration, choose Opsgenie, paste an API key from Settings → API key management with Read and Configuration Access (Create, Update and Delete are not needed), pick your region (US or EU), and select Load from Opsgenie. Moneat reads users, teams, schedules and their rotations, overrides, escalation policies, and the next two weeks of on-call, and shapes them into the migration package itself.

The read runs in the background. You can leave the page; Moneat emails you when the package is ready to review, or if something is needed from you. If Opsgenie rate-limits the read, Moneat waits and tries again on its own. If the read stops for a reason on Moneat's side, the import is kept and Moneat's team is notified; you are not asked to start over.

To finish a read that was interrupted, Moneat holds your API key encrypted for up to 7 days. It is removed as soon as the package is ready to review, when you cancel the import, or when you select Remove key on the import. Removing Moneat's copy does not revoke the key in Opsgenie; do that in Opsgenie once the migration is done.

Anything Moneat cannot carry is listed under the result. Personal notification rules and contact methods are not copied: each responder chooses how Moneat contacts them under Paging.

Build a migration package yourself

The Migration package option is for tooling of your own, or for a provider Moneat cannot read. It accepts a normalized JSON package. Each record needs a stable externalId; keeping those IDs stable makes re-imports deterministic and lets the review show creates, updates, and removals instead of treating every run as new data.

The smallest useful package looks like this:

{
  "schemaVersion": 1,
  "provider": "OPSGENIE",
  "providerMigrationKey": "opsgenie-site-or-team",
  "entities": [
    {
      "type": "USER",
      "externalId": "ops-user-123",
      "name": "On-call engineer",
      "attributes": {}
    },
    {
      "type": "SCHEDULE",
      "externalId": "ops-schedule-456",
      "name": "Production",
      "attributes": {"timezone": "America/New_York"}
    },
    {
      "type": "ESCALATION_POLICY",
      "externalId": "ops-policy-789",
      "name": "Production escalation",
      "attributes": {}
    }
  ],
  "coverage": [
    {
      "scheduleExternalId": "ops-schedule-456",
      "responderExternalId": "ops-user-123",
      "startsAt": "2026-09-12T00:00:00Z",
      "endsAt": "2026-09-13T00:00:00Z",
      "timezone": "America/New_York"
    }
  ]
}

Use these rules while mapping:

• Set provider to OPSGENIE and keep schemaVersion at 1.
• Use a stable providerMigrationKey for the Opsgenie site or migration scope. Reusing it lets Moneat compare a later package with the imported state.
• Use an IANA time zone such as America/New_York on schedule attributes and every coverage window.
• Use ISO-8601 timestamps for startsAt and endsAt. A coverage window must end after it starts.
• Keep secrets out of the package. If a record needs one, use a secret:// reference and configure the value through the approved secret path after import.
• Do not invent a Moneat equivalent for a record you cannot map. Unsupported types are surfaced in the review instead of being silently approximated.

Review the import

Open Settings → On-call Migration. Only organization owners and admins can import or switch on-call paging.

1. Load from Opsgenie with an API key, or choose Migration package and upload the JSON.
2. Confirm that the result reads as Opsgenie and that the record counts look right.
3. Current coverage is read from Opsgenie with the rest. With a package, add it under Compare with your current on-call coverage to have the review show handoffs, newly covered windows, and gaps where nobody would be paged.
4. Select Review import. Reviewing is read-only; your current provider continues paging.
5. Read the proposed creates, updates, removals, unsupported records, missing secrets, and coverage changes before applying anything.

Resolve blocking issues in the package and review again. Do not acknowledge a coverage gap just to make the button available; a page raised during an uncovered window reaches nobody.

Import without paging, then mirror

When the review is correct, import the package without changing who pages. Moneat stores the versioned migration state, but your existing provider remains active.

If you want a side-by-side check, enable mirroring during import. Both systems may page during this stage, so agree on the test window and make sure responders know how to identify the first accepted page. Compare:

• The current responder and next handoff for every production schedule.
• Escalation order, wait times, and fallback behavior.
• SMS, push, voice, email, and Slack delivery.
• Acknowledgement, resolve, reassign, and manual escalation actions.
• Alert grouping and deduplication so one event does not become multiple pages.

The migration status stays visible at Settings → On-call Migration. It shows whether the import is ready, mirroring, paging from Moneat, or handed back to Opsgenie.

Reconnect alert sources

Moving schedules and escalation policies does not automatically move every system that sends alerts. For each Opsgenie integration:

1. Create the corresponding Moneat alert source, using a native adapter where one exists or Generic HTTP for a JSON webhook.
2. Map a stable alert title and deduplication key. Keep the key stable across trigger and recovery events so retries fold into one alert.
3. Point a non-production or low-risk integration at the new ingress endpoint first.
4. Verify the source event, matched Alert Route, grouping result, paging attempt, and incident result.
5. Move the remaining integrations after the first path is understood.

See Alerts & Alert Sources for the ingress contract, source health states, replay behavior, and adapter-specific setup.

Cut over when the result is trusted

Before cutover, send a test alert for each production route and confirm the responder who would be paged first. Then:

1. Open the migration status page.
2. Confirm the phase is Imported, not paging or Mirroring and that the version is current.
3. Select Start Moneat paging and confirm the schedules and responders in the dialog.
4. Keep the Opsgenie export and the Moneat review record with your change record.
5. Watch the first real alerts and verify acknowledgement stops escalation.

If the result is not acceptable, use Return paging to provider. Rollback stops Moneat paging and hands it back to Opsgenie while leaving the imported schedules and policies available for another review.

Migration checklist

• Exported Opsgenie configuration and retained the raw export.
• Read the account into Moneat with a read-only API key, or built and uploaded a package.
• Read the list of what was not carried over and covered each item in Moneat.
• Reviewed the Moneat dry-run and resolved every blocking issue.
• Verified alert sources, routes, grouping, delivery, and responder actions.
• Imported without paging or mirrored during a planned test window.
• Confirmed the first responder for every production schedule.
• Cut over to Moneat and recorded the result.
• Kept the export and review artifacts for audit and recovery.

Need a second pair of eyes on the package or the cutover plan? Talk to us before you move production paging.