⚠️ OpsGenie EOL — April 5, 2027

Migrate off OpsGenie
in 30 minutes.
Without paying 2.4x for JSM.

The complete step-by-step migration playbook. Export your OpsGenie data, map concepts, import, reconfigure alert sources, and cut over — all before your team even wakes up.

Book migration call →
🗓
OpsGenie EOL: April 5, 2027.  New sales ended June 4, 2025. All customer data deleted at shutdown. Don't be the team migrating in March 2027 under Atlassian's gun.

The 5-step migration playbook

Total time: ~30 minutes for a 20-person team. Each step is independent — run them in order, or skip steps if you're starting fresh without existing OpsGenie config to import.

1

Export your OpsGenie data

⏱ ~5 min

Pull schedules, escalation policies, integrations, users, and teams out of OpsGenie via their REST API. You'll need an OpsGenie API key with read permissions (Settings → API Key Management → Create API Key).

export-opsgenie.sh — run once, saves to ./og-export/
#!/bin/bash
# OpsGenie data export script
# Set your API key: export OG_API_KEY="your-key-here"

OG_API_KEY="${OG_API_KEY:?Set OG_API_KEY first}"
BASE="https://api.opsgenie.com/v2"
OUT="./og-export"

mkdir -p $OUT

# Teams
curl -s -H "Authorization: GenieKey $OG_API_KEY" \
  "$BASE/teams" | jq . > $OUT/teams.json

# Users
curl -s -H "Authorization: GenieKey $OG_API_KEY" \
  "$BASE/users?limit=100" | jq . > $OUT/users.json

# Schedules (on-call rotations)
curl -s -H "Authorization: GenieKey $OG_API_KEY" \
  "$BASE/schedules?expand=rotation" | jq . > $OUT/schedules.json

# Escalation policies
curl -s -H "Authorization: GenieKey $OG_API_KEY" \
  "$BASE/escalations" | jq . > $OUT/escalations.json

# Integrations (alert sources)
curl -s -H "Authorization: GenieKey $OG_API_KEY" \
  "$BASE/integrations" | jq . > $OUT/integrations.json

echo "✅ Export complete — files saved to $OUT/"
ls -lh $OUT/

After running the script, verify you have all 5 JSON files in ./og-export/. The escalations.json and schedules.json are the most critical — they define your routing logic.

2

Map OpsGenie → OnCallReady concepts

⏱ ~5 min review

OnCallReady uses slightly different terminology and a different mental model — because it's optimized around resolution, not routing. Here's the 1:1 concept map:

OpsGenie Object OpsGenie Name OnCallReady Equivalent Key difference
👥 Team Team Squad Squads own runbooks, not just routing trees
📅 Schedule On-Call Schedule Rotation Rotations only activate when auto-resolve fails
📋 Escalation Policy Escalation Policy Resolution Playbook Playbooks attempt auto-fix before escalating humans
🔌 Integration Integration (Datadog, etc.) Connector Same webhook URLs, different config location
🔔 Alert Rule Alert Filter / Route Trigger Pattern Regex-based matching against alert titles/tags
📊 Maintenance Window Maintenance Suppression Rule Time-scoped suppression with auto-expiry

The most important shift: in OpsGenie, an escalation policy is a series of "who to page." In OnCallReady, a Resolution Playbook is "what to try first, and who to page only if that fails." Most teams find their escalation policies collapse significantly — because auto-resolution handles the majority of steps.

3

Import via OnCallReady migration tool

⏱ ~5 min

Point the migration CLI at your ./og-export/ directory. It reads your OpsGenie export and auto-creates matching squads, rotations, and baseline runbooks in your OnCallReady workspace.

CLI import — auto-creates squads, rotations, and runbooks
# Install the OnCallReady migration CLI
npm install -g @oncallready/migrate

# Authenticate with your OnCallReady workspace
oncallready auth login

# Dry-run first — shows what will be created without writing
oncallready migrate opsgenie --input ./og-export --dry-run

# Import for real once you're satisfied with the dry-run output
oncallready migrate opsgenie --input ./og-export --workspace your-workspace

# Example output:
# ✅ Created 3 squads (Platform, Backend, Frontend)
# ✅ Created 6 rotations (mapped from 6 OpsGenie schedules)
# ✅ Created 12 baseline runbooks (from escalation policy actions)
# ⚠️  2 integrations require manual reconfiguration (see Step 4)
# Migration complete — open dashboard to review

After import, visit your OnCallReady dashboard and review the created runbooks. The CLI creates "pass-through escalation" runbooks that mirror your OpsGenie routing exactly — you can then enhance them with actual auto-resolution actions over time.

4

Reconfigure alert sources

⏱ ~10 min

Repoint each monitoring tool to OnCallReady's ingest endpoint. Your OnCallReady webhook URL follows the pattern: https://api.oncallready.io/ingest/<workspace-id>/<connector-id>. Find both IDs in Settings → Connectors.

Datadog
# Datadog → Integrations → Webhooks
# Add new webhook:
Name: oncallready
URL:  https://api.oncallready.io/ingest/
      <workspace>/<connector>
Payload (JSON):
{
  "title":    "$EVENT_TITLE",
  "severity": "$ALERT_PRIORITY",
  "source":   "datadog",
  "tags":     "$TAGS",
  "link":     "$LINK"
}
Prometheus Alertmanager
# alertmanager.yml
receivers:
  - name: oncallready
    webhook_configs:
      - url: >
          https://api.oncallready.io
          /ingest/<workspace>/<connector>
        send_resolved: true
        http_config:
          bearer_token: <api-token>

route:
  receiver: oncallready
AWS CloudWatch
# SNS → Subscriptions → Create
Protocol: HTTPS
Endpoint:
  https://api.oncallready.io/ingest/
  <workspace>/cloudwatch/<connector>

# Alarm action → Add notification
SNS Topic: oncallready-ingest
State:     ALARM (+ OK for auto-resolve)
Grafana
# Alerting → Contact points → New
Type: Webhook
URL:  https://api.oncallready.io/ingest/
      <workspace>/<connector>
Method: POST
HTTP headers:
  Authorization: Bearer <api-token>

# Notification policy: set Default
contact point: oncallready
PagerDuty (parallel migration)
# If routing from PagerDuty to OC0
# Add webhook in PD: Extensions → Add
Name: OnCallReady shadow
URL:  https://api.oncallready.io/ingest/
      <workspace>/pd/<connector>
Type: Generic V2 Webhook

# Events: incident.triggered,
#         incident.acknowledged,
#         incident.resolved
Custom webhook / any source
# Generic ingest — POST JSON body
POST https://api.oncallready.io/ingest/
     <workspace>/generic/<connector>
Authorization: Bearer <api-token>
Content-Type: application/json

{
  "title":    "Alert title string",
  "severity": "critical|high|medium|low",
  "source":   "your-system-name",
  "details":  { "any": "metadata" }
}
OpsGenie webhook (parallel mode)
# In OpsGenie: Settings → Integrations
# → Add Webhook integration
Name: OnCallReady shadow
URL:  https://api.oncallready.io/ingest/
      <workspace>/opsgenie/<connector>

# Trigger on: Create Alert
# This routes a copy of every OpsGenie
# alert to OnCallReady during parallel run
5

Parallel-run + cutover

⏱ 48h parallel, then flip

Run both systems for at least 48 hours. Every alert fires in both OpsGenie and OnCallReady simultaneously — OpsGenie pages your engineers as usual, OnCallReady runs in shadow mode resolving what it can. Once you're satisfied with the match rate, flip the primary routing.

During parallel run (48h+)

  • All alerts fire in both systems simultaneously
  • OpsGenie remains primary — pages go out as normal
  • OnCallReady auto-resolves what it can in background
  • Monitor OnCallReady dashboard for auto-resolution rate
  • Tune runbooks for any missed or mis-classified alerts
  • Validate notifications reach correct squads/rotations

Cutover checklist

  • Auto-resolution rate ≥ 70% of expected incidents
  • All critical alert sources confirmed in OnCallReady logs
  • At least 3 runbooks validated end-to-end with real alerts
  • On-call rotation verified for next 2 weeks
  • Update alert source configs to point to OC0 only
  • Disable OpsGenie webhook / integrations one by one
cutover.sh — flip primary routing, disable OpsGenie webhook
# 1. Verify OnCallReady is ingesting correctly
oncallready status --workspace your-workspace

# 2. Flip each alert source to OnCallReady-only
#    (update URLs in each tool — see Step 4 configs)

# 3. Disable the OpsGenie shadow webhook you added in Step 4
curl -s -X DELETE \
  -H "Authorization: GenieKey $OG_API_KEY" \
  "https://api.opsgenie.com/v2/integrations/<shadow-webhook-id>"

# 4. Confirm OpsGenie is no longer receiving alerts
# 5. Keep OpsGenie account active (read-only) for 30 days
#    in case you need historical incident data

echo "✅ Cutover complete. You're off OpsGenie."

The cost comparison — at 30 engineers

OpsGenie customers have exactly two paths: Jira Service Management at 2.4x the cost, or OnCallReady at less than half the price with a product that actually resolves incidents.

OpsGenie Standard
$599/mo
$7,188/year at 30 users
$19.95/user/month · Annual billing
No new sales since June 2025
Full shutdown April 5, 2027
Shutting down
JSM Premium (official path)
$1,435/mo
$17,226/year at 30 users
$47.82/user/month · 2.4× OpsGenie
New UX widely described as bad
Still routes every alert to a human
2.4× price increase
OnCallReady Pro
$299/mo
$3,588/year — any team size
Flat pricing · Unlimited users
94% incidents auto-resolved
Actively shipping features
Half the price of OpsGenie

Pricing as of June 2026. OpsGenie Standard $19.95/user/month annual. JSM Premium $47.82/user/month. OnCallReady Pro $299/month flat. See /pricing and /vs/opsgenie for full breakdown.

🤝

Free white-glove migration for teams of 50+

If your team is 50 engineers or larger, we'll handle the migration for you. We export your OpsGenie config, map it to OnCallReady, configure your top 10 runbooks, and run the parallel period with you. No weekend emergencies, no surprises.

Done-for-you export Runbook authoring Alert source reconfiguration Parallel-run monitoring 48h cutover support Post-migration review call
Book migration call →
Security & compliance docs · Real incident case studies · 15+ integrations · OpsGenie full comparison