Comparison by the IncidentRelay team. Documentation reviewed on ; IncidentRelay scope: v2.3.1. This is a documentation-based evaluation, not a performance benchmark or a promise of feature parity.
Quick decision · Capabilities · Migration limits · Pilot checklist
Start with the shutdown date
Opsgenie stopped new sales on June 4, 2025. Atlassian says it will shut down on April 5, 2027, with unmigrated customer data deleted. This is not just the end of new features. Existing users need a destination and a data-retention plan. See the official Opsgenie migration announcement.
Evaluate Jira Service Management if your team wants to stay in Atlassian Cloud and retain connected service-management workflows. Evaluate IncidentRelay if you deliberately want to operate an open-source on-call system in your own infrastructure and can own its availability, upgrades and backups.
Self-hosting is not a shortcut around migration work. It changes who owns the destination. Compare hosting and engineering effort with the actual destination plan, user roles and notification requirements, not an assumed one-for-one license replacement.
What you are actually moving
| Decision | IncidentRelay v2.3.1 | Atlassian migration path |
|---|---|---|
| Operating model | Self-hosted, open-source application. Your team operates the deployment. | The migration tool targets Atlassian Cloud, not Jira Service Management Data Center. |
| Schedules and escalation | Rebuild rotations, layers, overrides and escalation rules; validate them with On-call Health. | Atlassian provides automated migration of supported configuration; review the resulting schedules and policies. |
| Event routing | Global and service orchestration, normalized labels, simulation, replay and shadow mode. | Review integration changes and deprecated features; moving a tenant does not guarantee identical behavior. |
| Notifications | Chat, email and voice channels, plus profile-level browser/PWA push. Configure the providers and contacts yourself. | Review mobile-app changes and notification setup before the old Opsgenie service is turned off. |
| Incident model | AlertGroups handle technical paging; separate Incidents coordinate the operational workflow. | Incident response moves into Jira Service Management. Check feature changes against your current process. |
For the Atlassian path, read the migration scheduling and Cloud/Data Center guidance and the feature-change checklist. This page compares that path with IR; it does not treat Opsgenie and Jira Service Management as the same product.
Moving to IR is a rebuild, not a tenant import
IR v2.3.1 does not ship an Opsgenie importer. The release migration tools cover PagerDuty and Grafana OnCall OSS. Do not apply their import guarantees to an Opsgenie export.
- People and schedules: recreate teams, memberships, rotations, time restrictions and overrides. Compare the actual assigned responder across a complete cycle, including weekends and daylight-saving changes.
- Integrations and deduplication: inventory each sender, its authentication and its alert identity. Use a supported IR integration or map events to the generic webhook contract. An Opsgenie API key or payload is not automatically valid in IR.
- Policies and delivery: rebuild routing and escalation intentionally. Configure new secrets, user contact details and notification channels; do not assume a copied schedule can notify anyone.
- History and automation: preserve required records separately and inventory scripts, API clients, ticket links and response actions. Configuration recreation does not import incident history or provide Opsgenie API compatibility.
IR 2.3 separates technical AlertGroups from operational Incidents. One Incident can link multiple AlertGroups without merging their technical history. Acknowledgement and escalation remain AlertGroup concerns; responders and stakeholders are still AlertGroup-scoped in this release. Read the Incident Management boundary before mapping your existing response process.
A pilot with an explicit rollback point
- Record your Opsgenie deadline, migration owner and required historical exports. If you also schedule an Atlassian migration, account for its parallel-access window; do not assume the old tenant will remain available until the final product shutdown.
- Build one representative team in a test IR deployment. Compare a full rotation cycle, an override, escalation delays and behavior when the first responder does not acknowledge.
- Replay sanitized firing, duplicate and recovery events. Verify the selected team, grouping key, service and notification channel. Decide which system owns acknowledgement during the pilot.
- Test delivery on real responder devices, including after-hours conditions. Use On-call Health, but also confirm that messages and calls actually arrive.
- Switch one low-risk sender. Keep its previous configuration available while Opsgenie remains active, and avoid duplicate production notifications. Expand only after observing an on-call cycle.
Do not make rollback depend on a deleted tenant
Atlassian says turning Opsgenie off is irreversible; it also shuts down automatically 120 days after an Atlassian migration if not turned off earlier. That window is not a promise of indefinite fallback. Finish validation and preserve required records before shutdown. See what happens when Opsgenie is turned off.
Start with a test deployment. If a required workflow cannot be reproduced or nobody can operate the destination, resolve that gap before changing production senders.
Opsgenie and Jira Service Management are Atlassian products. IncidentRelay is not affiliated with Atlassian.