Migrating from Opsgenie to Faultline: the complete guide

TL;DR

• ▸April 5, 2027 is a hard deadline. Alerts stop routing, on-call schedules stop working, and all standalone Opsgenie data is permanently deleted. Atlassian has said not to plan around an extension.
• ▸Atlassian's official path is Jira Service Management (JSM) or Compass, which splits what was one tool into two, with ITSM pricing and a data-retention cliff (JSM Standard caps alert history at 1 year; Opsgenie Enterprise was effectively unlimited).
• ▸Atlassian's automated migration tool skips Opsgenie heartbeats without assigned teams, it considers them outdated. If you use heartbeats to watch cron jobs and background workers, the official path drops your coverage on the floor.
• ▸Faultline replaces Opsgenie's paging and escalation, keeps heartbeat monitoring as a first-class feature, and adds the detection layer Opsgenie never had, plus an MCP server so your AI agent can work incidents directly.
• ▸Teams that have already migrated report 6–16 weeks end to end, with a 2–4 week parallel run. If you're planning to start in Q1 2027, you're already late.

What actually happens on April 5, 2027

This isn't a "support ends but the lights stay on" sunset. Per Atlassian's own documentation:

• ▸You lose all access to Opsgenie. Users can't log in or retrieve data.
• ▸The Opsgenie mobile app is deactivated.
• ▸Remaining Opsgenie-based integrations stop working.
• ▸Opsgenie REST APIs work until April 5, 2027, then they're gone.
• ▸Any data you haven't exported or migrated is permanently deleted.

New sales already ended June 4, 2025. Teams on the JSM-bundled version lost access back in October 2025. If you're reading this, you're on standalone Opsgenie with a countdown running.

Why teams are skipping the JSM path

Atlassian's recommended destination is Jira Service Management (with Compass as the engineering-catalog sibling). Three problems keep coming up from teams that evaluated it:

1. 1One tool becomes two. Opsgenie's strength was unified alerting and on-call. JSM handles incident workflows; Compass handles the software catalog and some alerting. You either pick one and lose capability, or pay for both.
2. 2The retention cliff. Opsgenie Enterprise had effectively unlimited alert history. JSM Standard caps it at one year. If you run compliance reports or dig into historical incident data, check your current retention usage before committing, this bites regulated teams hardest.
3. 3You're buying an ITSM platform to get a pager. JSM is a service-desk product first. Much of what you'd pay for in JSM Premium, service portals, change management, asset management, has nothing to do with getting the right engineer paged at 3am.

The migration is lateral, not forward. JSM still treats every alert as an independent event and still can't see the failures that never hit a public endpoint. Which brings us to the actual gap.

The heartbeat problem nobody's talking about

Opsgenie Heartbeats let your cron jobs, queue workers, and scheduled tasks check in on an interval, if a job goes silent, Opsgenie alerts. For a lot of teams, this is the only monitoring their background infrastructure has.

Atlassian's automated migration tool skips heartbeats that don't have an assigned team, on the grounds that the feature is outdated. Translation: the official migration path can silently drop monitoring for exactly the failure class that's hardest to detect, the job that stops running and doesn't error, doesn't page, doesn't show up on any uptime check.

In Faultline, heartbeats aren't a legacy afterthought, they're the core of the product. faultline-cli pushes check-in events from any background job, queue processor, or scheduled task. Miss a check-in window and Faultline opens an incident automatically, with your escalation policy and runbook attached.

If you use Opsgenie heartbeats, migrate them first, not last. They're the piece with no safety net.

Concept mapping: Opsgenie → Faultline

Step 1: Export everything from Opsgenie now

The REST API works until shutdown day, but exports are your insurance policy regardless of destination. Pull, at minimum:

• ▸Users and teams, GET /v2/users, GET /v2/teams
• ▸On-call schedules and rotations, GET /v2/schedules (+ rotations per schedule)
• ▸Escalation policies, GET /v2/escalations
• ▸Heartbeats, GET /v2/heartbeats (name, interval, owning team, you'll recreate these in Faultline)
• ▸Integrations and routing rules, inventory every tool currently sending alerts into Opsgenie
• ▸Alert history, as far back as retention allows, for compliance and postmortem reference

Store the JSON exports somewhere durable. Once Opsgenie is off, Atlassian does not guarantee data recovery.

Step 2: Stand up Faultline alongside Opsgenie

Don't cut over cold. Every team that's done this migration recommends a parallel run.

1. 1Create your services in Faultline. Map each Opsgenie service/team to a Faultline service. Set thresholds that match how you actually think about failure (2 = DEGRADED, 3 = DOWN is a sane default).
2. 2Recreate escalation levels and on-call schedules from your export. Have each team lead confirm their rotation, schedule mismatches are the most common migration bug reported by teams that have done this.
3. 3Recreate heartbeats. For every Opsgenie heartbeat, add a faultline-cli check-in to the job. This is usually a one-line addition at the end of the cron script or worker loop.
4. 4Attach runbooks. This is where you go past parity: for each service, define what should happen automatically on failure, restart the ECS service, hit a recovery endpoint, post to Slack. In Opsgenie, remediation was a human reading a wiki. In Faultline, it runs before anyone picks up a phone.
5. 5Point Faultline's native monitors at your stack. HTTP endpoints, Docker containers, ECS services, queues. Many of your Opsgenie integrations existed to pipe monitoring data in, Faultline collects much of it directly, so your integration inventory should shrink, not just move.

Step 3: Run in parallel for 2–4 weeks

Dual-page during this window: Opsgenie stays authoritative, Faultline shadows it.

• ▸Confirm every real incident in Opsgenie also appears in Faultline, same service, correct severity, right person paged.
• ▸Watch for false positives and tune per-service thresholds.
• ▸Trigger a deliberate test failure for each critical service (kill a worker, stop a container) and verify the full chain: detection → incident → escalation → runbook → Slack.
• ▸Verify heartbeat coverage by pausing one job and confirming Faultline opens an incident within the check-in window.

Teams with straightforward setups report 6–8 weeks total; complex integration footprints have taken up to 16. Budget engineering time as your real migration cost, not license fees.

Step 4: Cut over

• ▸Flip alert sources and paging to Faultline as the system of record.
• ▸Keep Opsgenie read-only for a defined wind-down (30 days is typical) as a reference, then decommission, don't pay for two systems longer than you must.
• ▸Update your incident response docs and onboarding to reference Faultline dashboards, the CLI, and the Slack bot.
• ▸Archive your Opsgenie exports permanently.

What you get that Opsgenie never had

Opsgenie was an alert router. It waited for other tools to tell it something was wrong, then paged a human. Faultline closes the loop on both ends:

• ▸Detection built in. HTTP, Docker, ECS, cron, and queue monitoring in the same product that pages, no separate monitoring bill, no integration lag.
• ▸Remediation before the page. Runbooks execute on failure. Plenty of incidents resolve with the human reading the timeline in the morning instead of working it at 3am.
• ▸An agent-operable API. Faultline ships an MCP server, CLI, and Slack bot on one agent loop. Point Claude Code or Claude Desktop at Faultline and it can check service health, inspect incident timelines, see who is on call, and, with your approval, run the fix. Opsgenie paged people. Faultline can brief the agent that already lives in your terminal.

Recommended timeline

That's a comfortable quarter. The teams that got burned were the ones who treated April 2027 as a calendar item and started with six months left, some ended up re-migrating after picking the wrong tool under time pressure. One migration, done early, that counts.

FAQ

Ready to start the parallel run? See how Faultline replaces Opsgenie's paging and escalation, or start monitoring free below.