Skip to main content

​
Introduction

Atlassian has given Opsgenie a definite end: new sales stopped on June 4, 2025; existing customers can use it until support ends on April 5, 2027. After that, Opsgenie shuts off and Atlassian deletes any customer data not moved out (see the Atlassian Opsgenie Licensing FAQ).
For teams still running on Opsgenie, the real question is not “should we keep using Opsgenie” — it is where your schedules and escalation policies live next.
This page compares the two main paths:

Stay inside Atlassian

Migrate into Jira Service Management (JSM) or Compass with Atlassian’s official in-app tool — ticketing and alerting from one vendor, with the lowest migration friction

Move to an independent on-call platform

Flashduty as the example: schedules, escalation, and incident collaboration run independently of JSM packaging, licenses are billed per active responder, with native Feishu/DingTalk/WeCom support
The feature and pricing information on this page is current as of September 2026; refer to each vendor’s official website for the latest updates.

​
Sunset timeline and the official migration path

​
Key dates

​
Atlassian’s official migration path

Atlassian steers teams toward Jira Service Management (incident management) or Compass (alerting/on-call) through an in-app migration tool. Key constraints:
  • Migration must be initiated by an Opsgenie Owner (who typically also needs site-admin rights);
  • The migration date must be scheduled at least 7 days in advance;
  • After a completed JSM migration, Opsgenie remains available for a 120-day review period before being permanently shut down;
  • Most configuration syncs automatically, but destination-plan differences and some configuration require manual follow-up. For example, you must review and rebuild alert actions, incident rules, Responder roles, and Stakeholder filters in the destination product.
For organizations already standardized on Jira, Confluence, and JSM, this is the lowest-friction path. Teams that want their on-call practice to run independently should evaluate a dedicated on-call platform.

​
Product feature comparison

​
On-call

On-call solves “getting the alert to the right person”: reduce noise first, then notify according to scheduling and escalation policies.

​
Schedule management

​
Dispatch & escalation

​
Notification channels

​
Alert noise reduction

​
Response

Response solves “closing the loop quickly once the right person is found”: a single timeline, a single war room—handling, collaboration, and post-mortems that never lose context.

​
Status pages

​
AI capabilities

​
Platform & integrations

​
Pricing comparison

​
Billing model difference example

Take a 100-person engineering team where 15 people routinely handle incidents:
Opsgenie’s seat price is modest, but the product is ending. Compare Flashduty’s cost with your migration destination instead. If the destination is JSM, include the JSM plan price, an Atlassian Statuspage subscription, and potential seat expansion in the total cost.

​
Migration path comparison

​
Path one: Migrate into Jira Service Management (stay in Atlassian)

Best for organizations already standardized on the Atlassian suite. The official in-app tool syncs most configuration into the selected JSM plan, but note:
  • Automation configuration such as alert actions and incident rules does not migrate automatically and must be rebuilt with Jira Automation;
  • Fields like Responder roles and Stakeholder filters need post-migration review;
  • Chat integrations must be reconfigured with new authentication.

​
Path two: Cut over to Flashduty (independent On-call)

Best for teams that want their on-call practice to run independently of JSM packaging. Note that there is no one-click importer from Opsgenie to Flashduty. Flashduty specialists help you plan the cutover, and your team rebuilds schedules, escalation policies, services, routing, and integrations. In return, your alerting platform no longer depends on Atlassian packaging or seat-based billing.
1

Audit your existing configuration

Inventory schedules and rotation rules, escalation policies, integration endpoints, alert routing rules, and notification templates
2

Rebuild the core path in the destination

Connect one real alert source first; configure schedules and escalation policies; run SMS, phone, IM, escalation, and closure end to end
3

Run in parallel and verify

Keep the old and new response paths running side by side for a while; test acknowledgement and escalation with real responders
4

Cut over and decommission

Once the workflow is proven, agree on a cutover window; export the data you need to keep before the end-of-support date, when unmigrated data will be deleted
Whichever path you choose, complete the migration and export the data you need before April 5, 2027 — unmigrated data will be deleted after the sunset date.

​
How to choose

Choose Flashduty if

  • You need a durable on-call / incident-response home outside Atlassian’s merge path
  • You want licenses billed only for members who actually handle incidents, with notification recipients at zero cost
  • Your daily collaboration lives in Feishu, DingTalk, or WeCom and needs native support (including on-premises versions)
  • You want built-in status pages, war rooms, AI post-mortems, and AI SRE autonomous troubleshooting
  • You need private deployment

Stay on the Atlassian path if

  • Your organization is already standardized on Jira, Confluence, and Jira Service Management
  • You want Atlassian’s automated in-app migration with the lowest friction
  • You value ticketing and alerting from one vendor more than an independent on-call product
Still comparing other vendors? See the in-depth Flashduty vs PagerDuty comparison.
We recommend a 14-day trial with a real workload: connect one alert source, configure schedules and escalation policies, run the full notify-and-close loop, and then make your decision.