How to export your Opsgenie data before April 2027

By Andrew McCarron · March 15, 2026 · 8 min read

On April 5, 2027, Atlassian will permanently shut down Opsgenie and delete all data. That includes your incident history, escalation policies, on-call schedules, and alert routing rules — gone, with no recovery path.

This guide covers every data type Opsgenie stores, how to export each one via the Opsgenie API and UI, what you can and cannot migrate automatically, and the pitfalls engineering teams hit when they wait too long.

1. What data Opsgenie stores (and what gets deleted)

Before you start exporting, understand what you're working with. Opsgenie stores six categories of data:

2. Export method 1: Opsgenie REST API

The Opsgenie REST API is the most comprehensive export method. It gives you full control over what you export and how far back you go. You need an API key with read access — go to Settings → API key management in Opsgenie to generate one.

Export incident history

The alerts endpoint returns up to 100 alerts per page. Use the createdAt query parameter to paginate through your full history:

curl -X GET \
  "https://api.opsgenie.com/v2/alerts?limit=100&offset=0&order=desc" \
  -H "Authorization: GenieKey YOUR_API_KEY" \
  -o alerts_page_1.json

# Page through all results until empty
# Each response includes: alertId, message, status, teams,
# responders, createdAt, updatedAt, count, source

Opsgenie keeps 6 months of alert data in the UI but the API may return more depending on your plan. Run a test query first to confirm how far back your data goes.

Export on-call schedules

# List all schedules
curl -X GET "https://api.opsgenie.com/v2/schedules" \
  -H "Authorization: GenieKey YOUR_API_KEY" \
  -o schedules.json

# Get rotation details for each schedule
curl -X GET "https://api.opsgenie.com/v2/schedules/{scheduleId}/rotations" \
  -H "Authorization: GenieKey YOUR_API_KEY" \
  -o rotations_{scheduleId}.json

# Get the current on-call for a schedule
curl -X GET "https://api.opsgenie.com/v2/schedules/{scheduleId}/on-calls" \
  -H "Authorization: GenieKey YOUR_API_KEY"

Export escalation policies

curl -X GET "https://api.opsgenie.com/v2/escalations" \
  -H "Authorization: GenieKey YOUR_API_KEY" \
  -o escalations.json

# Each escalation includes: name, description, teams, rules[]
# rules[].delay (minutes), rules[].notify.type, rules[].notify.recipients

Export notification rules

# Export per-user notification rules
curl -X GET "https://api.opsgenie.com/v2/users/{username}/notificationrules" \
  -H "Authorization: GenieKey YOUR_API_KEY" \
  -o notification_rules_{username}.json

3. Export method 2: Opsgenie UI exports

For teams that don't want to script the API calls, Opsgenie provides CSV exports for some data types directly from the UI:

• Alert/incident history (CSV): Reports → Alert Report → Export as CSV. Covers the visible date range. Use filters to export by team or service.
• Team membership: Settings → Teams → select team → Members tab → there's no direct export, but you can view the list and copy manually. For automated export, use the /v2/teams API.
• Schedule overrides: Calendar view → select the override → no bulk export. Use the /v2/schedules/{id}/overrides API for automated export.

4. What you cannot export automatically

Even with full API access, several things require manual work:

• Integration credentials

  Opsgenie can export the list of integrations but not the API keys or webhook secrets. You must regenerate credentials in your new platform and update every connected monitoring tool. Budget 30–60 minutes per integration.

• Historical acknowledgment timeline

  The detailed timeline of who acknowledged what and when is available per-alert via the API but requires fetching each alert individually. For large incident volumes (10,000+ alerts), this is hours of API calls.

• Custom Marid (middleware) configurations

  If you used Opsgenie Marid for custom integrations, those configurations are proprietary to Opsgenie's middleware stack. You'll need to rebuild equivalent integrations in your new platform.

• Maintenance window history

  Past maintenance windows can be exported via API but future recurring maintenance schedules must be recreated manually in your new platform.

5. How to preserve your MTTR + DORA metrics

This is the part most teams don't think about until it's too late. Your MTTR trend line — the D in DORA — is calculated from your incident history. If you switch incident platforms without archiving that history, you lose continuity in your DORA metrics.

The problem is compounded because most new incident management platforms start your MTTR counter from zero when you connect them. Your historical Opsgenie incidents aren't automatically imported — only future incidents in the new system count.

If you're not using Koalr, you can manually preserve MTTR continuity by exporting your Opsgenie incident history as JSON and loading it into a data warehouse (BigQuery, Redshift, or even a spreadsheet). Then you can manually compute historical MTTR alongside your new platform's native metrics.

6. The migration timeline you need to know

Teams that start their migration in Q3 or Q4 2026 will be under pressure. Based on incident management migrations we've studied, here's a realistic timeline:

7. Using Koalr to automate the full export

If scripting the Opsgenie API yourself sounds tedious, Koalr's migration wizard handles the entire export in one step. Connect your Opsgenie account and Koalr will:

• Archive your full incident history (24 months) immediately
• Export all on-call schedules, rotations, and overrides
• Export all escalation policies with responder chains
• Export alert routing rules and conditions
• Generate a migration manifest for incident.io or PagerDuty import
• Maintain MTTR and DORA metric continuity through the transition

The migration wizard is included free on all Koalr plans — including the free tier. No credit card required.