Opsgenie Is Shutting Down: What MSPs Need to Know (Migration Checklist)

Atlassian has announced that Opsgenie is shutting down. By April 2027, every Opsgenie instance will be permanently decommissioned and all data deleted. Every incident management vendor has already published a migration guide. But none of them address what MSPs specifically lose in this transition — and MSPs lose more than most.

If you are running ConnectWise Manage, Autotask PSA, or HaloPSA alongside Opsgenie, you are not just migrating an alerting tool. You are rebuilding your entire on-call-to-PSA workflow: the ticket creation rules, the client-specific escalation policies, the after-hours billing data, and the routing logic that connects monitoring alerts to the right technician for the right client.

This guide covers the Opsgenie shutdown timeline, explains why MSPs face a fundamentally different migration problem than SaaS or DevOps teams, and provides a practical migration checklist you can start working through today.

The timeline — what's already happened and what's coming

Atlassian has laid out a phased shutdown. Some milestones have already passed. Here is the full timeline so you can plan accordingly.

Why MSPs have a different migration problem

Most Opsgenie migration guides are written for SaaS engineering teams and DevOps organizations. They assume you have a single product, a single set of escalation rules, and internal-only stakeholders. MSPs operate in a fundamentally different model, and the migration is harder because of it.

Multi-client escalation policies

MSPs do not have one escalation policy — they have dozens. Each client may have different SLAs, different emergency contacts, different severity definitions, and different expectations for response times. In Opsgenie, you may have built client-specific routing rules and escalation chains that took months to refine. These cannot be exported as a simple config file and imported elsewhere.

PSA ticket workflows

For many MSPs, Opsgenie is not just handling alerts — it is creating and updating tickets in ConnectWise Manage, Autotask PSA, or HaloPSA. These integrations might be built through Opsgenie's native webhook actions, third-party middleware like Tray.io or Zapier, or custom API scripts. When Opsgenie dies, every one of those ticket creation flows breaks.

After-hours billing

If your team tracks on-call time through Opsgenie for after-hours billing purposes, that data disappears with the shutdown. Some MSPs use Opsgenie's on-call schedule data to calculate overtime, after-hours premiums, or client-billable emergency support hours. You need to find a new source of truth for this data before April 2027.

Client-specific routing

In a SaaS company, alerts route to teams based on service ownership. In an MSP, alerts route to specific technicians based on client— not just service. Technician A handles Client X's network issues because they know the environment. Technician B handles Client Y. This client-to-technician mapping is a core part of your service delivery model, and most alerting tools do not natively support it.

Atlassian's official path — JSM — and why MSPs should be cautious

Atlassian's recommended migration path is Jira Service Management (JSM). They provide automated migration tooling and documentation for moving Opsgenie schedules, escalation policies, and integrations into JSM. For some organizations, this is the right choice. For MSPs, it deserves a more careful evaluation.

What JSM does well

• Deep integration with the Jira ecosystem — issues, projects, workflows, dashboards
• Mature ITSM capabilities including request management, change management, and asset tracking
• Familiar Atlassian UI for teams already using Jira or Confluence
• Automated migration tooling from Opsgenie (schedules, policies, and some integrations)

What MSPs lose

• Significant cost increase:JSM Standard tier lacks on-call features entirely. You need JSM Premium at $17.65/agent/month — nearly double Opsgenie's $9.45/user pricing. For a 20-person team, that is an additional $1,968/year.
• Alert creation rules gone:Opsgenie's alert creation rules do not exist in JSM. You must recreate equivalent logic using Jira Automation rules, which have different capabilities and limitations.
• Heartbeat monitoring dropped:Opsgenie's heartbeat monitoring — used by many MSPs to verify that RMM agents and monitoring tools are reporting — has no direct equivalent in JSM.
• Mobile experience degraded: Opsgenie has a purpose-built mobile app for on-call. In JSM, on-call lives inside the broader Jira Cloud mobile app, which is cluttered with project management features your on-call technicians do not need at 3 AM.
• JSM is an ITSM tool, not an incident response platform: JSM excels at ticket management and service requests. It was not designed as a real-time incident response platform with sub-minute alert delivery, phone call escalation, and rapid acknowledgment workflows.

The MSP on-call stack in 2027

Rather than looking for a single monolithic replacement for Opsgenie, MSPs should think about their on-call stack in layers. Each layer serves a distinct purpose, and trying to force one tool to cover all three leads to compromises.

Layer 1: Alerting

This is the tool that wakes people up. It handles pages, SMS, phone calls, mobile push notifications, and escalation when alerts are not acknowledged. Strong options include PagerDuty, Better Stack, Squadcast, and ilert. Choose based on your integration requirements, budget, and whether you need built-in monitoring or just alert routing.

Layer 2: Handovers

This is the tool that ensures context transfers cleanly between shifts. When one technician's on-call shift ends and another begins, there needs to be a structured handover: what happened during the shift, what is still in progress, what the incoming engineer needs to know. Without this, the incoming technician starts blind — and clients feel it. Shiftctl handles this layer with enforced sign-offs, structured incoming briefs, and automatic notifications.

Layer 3: PSA

ConnectWise Manage, Autotask PSA, or HaloPSA remains your source of truth for tickets, billing, client records, and SLA tracking. Nothing changes here — but the connections into your PSA from your on-call stack need to be rebuilt.

The key insight is that Layer 2 bridges Layer 1 and Layer 3. Alerting tools are excellent at waking people up, but they do not write to your PSA. They do not sync shift notes to ConnectWise tickets. They do not track what happened during the handover between technicians. Shiftctl connects to your PSA directly, so handover context, shift notes, and ticket updates flow automatically into your existing workflow.

Other tools worth evaluating for MSP-specific needs: OnPage (ConnectWise-focused alerting with secure messaging), ilert (multi-PSA integration support), and AlertOps (workflow automation with ConnectWise and Autotask connectors).

MSP migration checklist

This checklist is organized by phase. Timelines assume a mid-complexity MSP setup with 10-30 integrations and multiple client-specific escalation policies. Simpler setups can compress phases; more complex environments should add buffer.

Phase 1: Audit (weeks 1-2)

• Export all Opsgenie schedules, routing rules, and integration configurations — Opsgenie allows JSON export of most config objects via the API
• Document every client-specific escalation policy, including SLA thresholds, emergency contacts, and severity definitions
• List all integrations connected to Opsgenie — RMM tools (Datto, ConnectWise Automate, NinjaOne), PSA platforms, monitoring tools (PRTG, Zabbix, Datadog), and any custom webhook integrations
• Identify which ticket creation and update workflows depend on Opsgenie — map every Opsgenie action that writes to your PSA
• Audit after-hours billing data sources — if on-call time or incident response time is tracked through Opsgenie, document how that data flows to billing

Phase 2: Choose your stack (weeks 2-4)

• Select your alerting tool — evaluate PSA integration depth, mobile app quality, and pricing at your team size (see our alternatives comparison for detailed breakdowns)
• Select a handover tool if shift context transfer is a problem — lost context between shifts directly impacts client experience and creates unbillable rework time
• Map every existing Opsgenie workflow to equivalent capabilities in your new tools — identify gaps early, not during migration
• Plan your parallel-run period — you will want to run both the old and new systems simultaneously before cutting over

Phase 3: Migrate (weeks 4-8)

• Recreate on-call schedules in your new alerting tool — most tools support iCal import from Opsgenie as a starting point
• Rebuild escalation policies with client-specific routing — this is typically the most time-consuming step for MSPs
• Connect PSA integrations and test ticket creation end-to-end — verify that alerts create tickets in the correct board, with the correct priority, assigned to the correct technician
• Train your team on the new workflow — schedule a walkthrough, create a quick-reference guide, and ensure everyone has the mobile app installed and configured
• Run parallel for 2-4 weeks with Opsgenie still active — both systems receive alerts, but only the new system is "official" for response

Phase 4: Cut over (weeks 8-10)

• Disable Opsgenie integrations one by one — start with lower-priority clients, then move to critical accounts once you are confident
• Export and archive all Opsgenie data before the April 2027 deletion deadline — incident history, alert logs, and schedule records may be needed for compliance or billing disputes
• Update all runbooks, documentation, and internal wikis that reference Opsgenie workflows
• Confirm PSA ticket flows are working correctly under production load — spot-check tickets created during the first week post-cutover

Frequently asked questions