On this page
If you run on-call in Opsgenie, you have a fixed date on the calendar and one decision to make before it.
The guidance below is vendor-neutral and covers four topics:
- what leaves with the product
- what to inventory
- the order that keeps you covered while you move
- how to size the effort
Perstat appears at the end, under the consolidation question, not as the premise.
Two dates set your timeline
Atlassian ended new sales on 4 June 2025 and will end support on 5 April 2027. Existing customers can add seats until 5 April 2027 and renew only if the term ends before that date, according to the licensing page.
The qualifier that governs your planning is unmigrated. The same licensing page says customer data not moved to Jira Service Management is deleted by that date. Atlassian’s turn-off documentation adds that Opsgenie shuts down automatically 120 days after a migration if you do not turn it off manually. Before that date, export whatever you want to keep outside the offered migration paths.
This is Atlassian’s product decision, stated plainly. It says nothing about the tools around it and only sets your timeline.
For regulated teams, retained incident history can contribute to internal records and reporting. DORA has applied since 17 January 2025. Neither an exported history nor the replacement tool determines whether DORA applies or establishes compliance for an organization.
Start with an inventory before any tool search
Spend an hour in the Opsgenie console and write down what you use. The inventory may be shorter than you feared, and it may surface forgotten dependencies. Five buckets cover it.
Record schedules and rotations
Write down who is on call, when, and across which teams and time zones. Note the overrides and holiday patterns too. Those are the details that break quietly after a move.
Capture escalation policies
Write down each chain: who gets paged, after how long, and what happens when nobody acknowledges. Capture the timing, not only the order.
List integrations and alert sources
List every system that opens an alert:
- monitoring tools
- cloud provider alarms
- error trackers
- webhooks
- email pipelines
Integrations can require substantial work. Each source has to be re-pointed and tested in the new system.
Document routing and teams
Note how alerts map to teams, tags, and priorities. Routing rules encode institutional knowledge, and a rushed cutover can lose it.
Export history and reports
This bucket holds past alerts, incident timelines, and on-call reports. Decide what you need to keep. Export it early, in whatever format Opsgenie gives you, before Opsgenie access ends.
Move in an order that keeps you covered
Do not switch everything at once. Run both systems in parallel and move alert sources one at a time.
- Export history and reports now, before anything else changes.
- Finish the inventory above. Then decide between a point replacement and consolidation, as the next section describes.
- Rebuild schedules and escalation policies in the new tool. Keep them identical at first and improve them later.
- Re-point integrations one source at a time. Confirm that each one pages a human before you move to the next.
- Run both systems in parallel for one full on-call rotation. Use controlled tests to exercise every intended alert route before cutover.
- Cut over, then decommission Opsgenie once you have exported everything you need.
Choose between a point replacement and consolidation
This is the real decision. Give it 30 minutes before you shortlist anything.
Opsgenie does on-call and alert routing. You can replace it with another dedicated on-call tool and leave the rest of your stack alone. That is the low-surprise path, and for some teams it is the right one.
Consider a stack where on-call sits beside separate uptime monitoring, a status page, and an incident process from different vendors. If those vendors do not share data, migration is a chance to evaluate consolidation while you rebuild schedules and re-point integrations.
Neither answer is automatically correct. If your alert sources are deep in one ecosystem, a like-for-like on-call tool may preserve the workflow. The same applies if you lean on tight Jira Service Management integration and ticketing.
If tool sprawl is the problem, the migration is a practical point to evaluate consolidation.
Size the effort from your own inventory
Do not borrow a generic duration. Count these items, then assign an owner and a test to each one:
- schedules and escalation policies
- alert sources and integrations
- reports
- teams
- training paths
Lead time includes approvals and a parallel run. The hands-on work comes from the inventory.
Define the exit criteria before you set a date:
- Every alert source reaches the intended route.
- Every schedule has an owner.
- Acknowledgments stop escalation.
- A controlled incident recovers.
- The old path stays available until those checks pass.
These criteria make the estimate reviewable without pretending that one timetable fits every organization.
Keep a short checklist
- Export alert history, incident records, and on-call reports first.
- Inventory the five buckets above, then choose a point replacement or consolidation.
- Rebuild schedules and escalations identically in the new tool.
- Re-point integrations one at a time and test each one.
- Run both systems in parallel for one full rotation.
- Cut over, confirm your exports, then decommission.
Perstat is one option for consolidation
If consolidation is on your list, Perstat is one option to weigh. It puts uptime monitoring, status pages, incident response, and on-call in one product. Its EU control plane is operated by the German Datargo GmbH.
The Opsgenie concepts have familiar counterparts:
- On-call schedules and rotations start with Sentinel.
- Native push comes through the Apple apps.
- Personal SMS starts with Pulse.
- Sentinel adds on-call escalation from push to SMS and phone call.
- Acknowledgment remains explicit.
The monitoring that pages you sits in the same product. Eleven regional check types, including HTTP, TCP, and DNS, use up to six plan-dependent regions and a configurable regional policy with a default quorum of 2. Agent and heartbeat monitors use neither regions nor quorum.
A linked status-page component can use the same monitor and incident record. Publication remains an explicit action.
Perstat keeps a curated availability record. The public sample SLA report is an editorial example, not a generated customer report. Each monitor view offers a PDF report for 7, 14, 30, or 90 days, not signed and not certified, and a CSV plus manifest is available manually on request.
Perstat does not replace Jira Service Management, ticketing, APM, or log management. If those are load-bearing for you, a dedicated on-call tool is the better fit. That is a fine result of this exercise.
The Opsgenie comparison page has the concept-by-concept mapping. Prices are listed on the pricing page, net of VAT, and you can start free.
Start monitoring free or take the product tour. You can take the tour without signing up and see the prices without a sales call.