Moving off Opsgenie? We’ll help you migrate to Moneat.
Opsgenie support ends on April 5, 2027. Moving away means checking more than an export file: schedules, overrides, escalation policies, notification channels, and alert integrations all need to behave correctly in the new system.
We’ll help you assess a move to Moneat and work through those checks before production paging changes. You can keep your existing monitoring tools while you move the on-call workflow.
The short version
| Question | What to plan for |
|---|---|
| Deadline | 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. Export required data before the site shutdown date. |
| Configuration | Inventory responders, teams, schedules, rotations, overrides, escalation policies, priorities, and notification rules. |
| History | The Moneat migration package does not recreate historical alerts or incidents. Export them separately if you need them. |
| Alert sources | Systems that send alerts to Opsgenie must be connected and tested separately in Moneat. |
| Cutover | Change production paging only after every route, handoff, acknowledgement, and escalation has been exercised. |
Atlassian offers a largely automated move to Jira Service Management, with some manual steps depending on the account. That may be the most direct route for a team already committed to the Atlassian stack.
incident.io is another strong option. Its Basic plan includes single-team on-call at no charge, while standalone on-call is currently listed at $20 per user per month. Check the provider’s current plan details against the number of teams and responders you actually need.
Moneat is worth evaluating when you want on-call and incident response connected to the errors, logs, traces, metrics, and monitors that produced the alert. Use the current pricing page for Moneat plan and responder terms rather than relying on a static figure in this article.
What the migration package records
Moneat accepts a normalized migration package for users, teams, schedules, rotations, overrides, escalation policies, notification rules, priorities, and schedule coverage. A raw Opsgenie export must be mapped into that package format before it can be reviewed.
Keep stable external IDs while converting the export. They let a later review distinguish an update from a new record and make it possible to compare coverage between versions.
The current migration surface records the normalized package, its coverage plan, and the migration phase. Treat that record as a review and coordination aid. A stored Cutover state is not, by itself, evidence that operational schedules were created, alert integrations were reconfigured, or pages reached the intended responders.
That distinction matters. The safe acceptance test is an actual page, not a green status label.
What requires separate work
Historical alerts and incidents are not recreated from the migration package. Preserve any history you need before the Opsgenie deadline.
Alert-source integrations also need to be reconnected. For each production source:
- Create the corresponding Moneat alert source and route.
- Preserve a stable deduplication key across trigger and recovery events.
- Send a low-risk test event and inspect the normalized alert.
- Confirm the expected responder receives the page through every required channel.
- Acknowledge, resolve, reassign, and manually escalate the test.
- Verify that retries group into one alert instead of creating duplicate pages.
Do this for every route. One successful Slack notification does not verify SMS, voice, push, or the fallback responder.
A practical migration sequence
Start by preserving the original Opsgenie export and documenting who is on call now and at the next handoff. Then map the configuration into Moneat’s normalized package and review missing values, unsupported records, destructive changes, and coverage gaps.
Next, create the real schedules, policies, contact methods, alert sources, and routes required for the new workflow. Run both paths during an agreed test window if duplicate notifications are safe and responders know which page to acknowledge.
Before changing production paging, verify:
- the current responder and next handoff for every schedule;
- escalation order, delays, and fallback behavior;
- SMS, push, voice, email, and Slack delivery that your team depends on;
- acknowledgement, resolution, reassignment, and manual escalation;
- grouping and deduplication for repeated events; and
- the procedure for returning each alert source to Opsgenie.
Move one alert source first. Watch real delivery before moving the rest.
We’ll help you verify the move
I don’t want a team to discover a bad schedule mapping at 3 AM. If you are evaluating Moneat, we’ll help review the export mapping, identify the manual work, and build a validation checklist around your actual paging paths.
You do not need to replace the rest of your monitoring stack at the same time. Start with the deadline in front of you, prove the response path, and expand only when the first workflow is trusted.
Talk to us about your Opsgenie migration before changing production paging.
Keep reading
Migrate from Sentry to Moneat: what changes and what doesn’t
A staged guide to moving supported Sentry SDK telemetry to Moneat, including validation, source maps, alerts, historical data, and rollback.
Use Moneat with your existing Sentry SDKs and Datadog Agents
Keep existing instrumentation for supported signals, point it at Moneat, and verify the configuration and workflow differences before switching.