Migrating from Opsgenie to AlertKick step by step

Opsgenie stopped selling to new customers on 4 June 2025. Access ends and unmigrated data is deleted on 5 April 2027. AlertKick includes on-call schedules, escalation policies, and every notification channel on every plan, including Free.

The importer lives at Admin -> Import in the AlertKick app. It is also reachable from the Migrate tiles on the Add Integration page. The tool does not guess. It shows you exactly what it will create and what it refuses to map.

Before you start: invite users and get the API key

First, invite your on-call people into AlertKick. Use the same email addresses they use in Opsgenie. Matching happens by email only. The importer does not create users automatically. If an email does not match an existing AlertKick account, the import skips that person. You must invite them first.

Next, create an Opsgenie API key. Go to Settings -> App settings -> API key management -> Add new API key. Tick both Read and Configuration Access. You need Configuration Access for the schedules endpoint. Without it, the endpoint returns 403. The preview fails with a message that says so.

Finally, know your region. US accounts use api.opsgenie.com. EU accounts use api.eu.opsgenie.com. The Import page has a region selector. Pick the one that matches your Opsgenie account.

If you skip inviting users, the preview lists unmatched emails. Invite them and re-run. If you skip Configuration Access, the preview fails immediately. Fix these two things before you press Preview.

Step 1: Preview the mapping

Paste the API key into the Import page. Select your region (US or EU) and press Preview. AlertKick calls three Opsgenie endpoints: GET /v2/users, GET /v2/schedules?expand=rotation, and GET /v2/escalations. These are read-only requests. The key is used for that request and never stored.

The preview shows three tables: users, rosters, and escalation policies. Every item that cannot map one-to-one has a note next to it. Nothing is written to your AlertKick account at this stage.

Read every note before going further. The next section lists exactly how each Opsgenie object lands.

What maps to what

The importer maps Opsgenie data to AlertKick objects using strict one-to-one rules. It does not guess. Ambiguous or impossible mappings appear in the preview with a note.

Users Matching is by email address only, case-insensitive. If an Opsgenie user email exists in AlertKick, they match. If not, they appear in the preview as unmatched so you can invite them. Blocked Opsgenie users still match but receive a note. The importer never creates users automatically.

Schedules to Rosters Opsgenie schedules become AlertKick rosters. The importer extracts the name, timezone, hand-off day, and hand-off time from the rotation’s startDate in the schedule’s own timezone. Daily and weekly rotations import. The Opsgenie rotation length becomes the roster’s hand-off length; a weekly rotation with length 2 becomes a roster that hands off every two weeks. Hourly rotations are skipped with a note.

Schedules with multiple rotation layers import only the first layer, noting how many layers were skipped. Time restrictions like business hours or weekdays-only are noted and dropped. Rotations with an end date in the past are skipped. Disabled schedules import with a note. Team participants in a rotation are dropped because only people can be on a roster. If no member of a schedule matches an AlertKick user, the schedule is skipped.

Escalation Policies Each Opsgenie escalation rule becomes a level in an AlertKick escalation policy. A user recipient becomes “notify user”. A schedule recipient becomes “notify the roster” (whoever is on call in the imported roster). Team recipients are skipped with a note because AlertKick levels target a person or a roster, not a team.

Delays and Repeat Logic Opsgenie delays are absolute from alert creation; AlertKick timeouts are the wait between one level and the next. A chain of 0, 10, 25 minutes becomes level timeouts of 1, 10, 15 minutes. The minimum timeout is 1 minute. Opsgenie repeat.count carries over, capped at 10. waitInterval (a pause before repeating) and closeAlertAfterAll have no equivalent and are noted.

The rule condition if-not-closed is noted; AlertKick escalates while an alert is unacknowledged. notifyType values like next, previous, all, admins, or random are noted; AlertKick notifies whoever is currently on call.

New policies are seeded so the first target is notified on trigger and on resolve, not only after the first timeout. If a roster or policy name already exists in AlertKick, it is skipped. It is never overwritten. Re-running the import after inviting missing people is the intended flow.

Step 2: Run the import

Press Import. AlertKick fetches the same data it used for the preview, builds the exact same plan, and creates the resources. It creates rosters first, then escalation policies. This order matters because policy levels need to point at the rosters that were just created.

The result page lists what was created with links, what was skipped and why, and any warnings. If the process fails partway through, the next run skips items already created by name. This idempotency prevents duplicates and lets you resume without manual cleanup.

If a roster or policy name already exists in AlertKick, it is skipped and never overwritten. To replace one, delete or rename it in AlertKick and run the import again. Invite missing people, fix the notes from the preview, and re-run until the skipped list is empty or contains only things you meant to leave behind.

Once the import completes, you have a working copy of your on-call structure in AlertKick. Do not switch off anything in Opsgenie yet.

Step 3: Prove it pages

Open each imported policy in AlertKick and press Send Test Alert. This synthetic alert runs the full chain: on-trigger notifications, each escalation level with its configured timeout, and any repeat logic. Watch the right phone buzz before switching anything off in Opsgenie.

If a level targets a roster, the person currently on call receives the notification. If it targets a specific user, that user gets paged. Channels are Slack, Telegram, WhatsApp, SMS, email, and mobile push.

The preview shows what would be created. The test shows what is created. If a policy has several levels, check that the timeouts match what you expect: a chain of 0, 10, 25 minutes in Opsgenie becomes level timeouts of 1, 10, 15 minutes here.

If a test fails, check the following:

• The user or roster is correctly assigned to the policy level.
• The notification channel is active and configured.
• The user has accepted the AlertKick invite.
• The roster has an active on-call member.

Re-run the test as often as needed. Once every policy pages the right person, you are ready to repoint alert sources.

Step 4: Repoint alert sources

AlertKick accepts alerts from 28 inbound integrations, including Prometheus Alertmanager, Grafana, Datadog, CloudWatch, and Sentry. It also supports email ingestion for tools that lack a webhook. Each integration receives a unique service key and a default severity level. The catalogue is at /integrations/.

To find which alert sources still point at Opsgenie, list its integrations:

curl -s 'https://api.opsgenie.com/v2/integrations' \
  -H 'Authorization: GenieKey YOUR_KEY'

Enabled entries are the ones sending alerts. For each one, change the webhook in the source tool to the AlertKick integration’s service key. Tools without a webhook go through email ingestion instead.

Do not repoint everything at once. Start with a low-stakes source, confirm the alert arrives and pages the right roster, then move the next. Keep the Opsgenie integration enabled until the new path has fired for real, then disable it in Opsgenie. Work through the list one at a time.

What the importer does not do

The importer copies structure, not state, and it refuses to guess.

• It does not create users, so nobody gets paged from an account they never accepted.
• It does not merge rotation layers. Only the first layer of each schedule comes across; build extra layers by hand if you need them.
• It does not apply time restrictions. Business-hours or weekday-only rules are noted in the preview and dropped.
• It does not import team participants. Only people can be on a roster.
• It does not import alert history, overrides, or notification rules. Re-apply current overrides after the import.
• It does not import Opsgenie heartbeats. Replace them with AlertKick heartbeat monitors and update the jobs that ping them.

Every one of these shows up as a note in the preview before anything is created.

Suggested run order

Do not cut over everything in one weekend. The importer handles the structure, but you own the validation. Use this sequence to keep production stable while you verify the new paths.

Day 1: Prepare and import

1. Invite your on-call people into AlertKick with the email addresses they use in Opsgenie.
2. Run the preview. Read the notes. Invite anyone listed as unmatched and preview again.
3. Press Import.

Day 2: Validate every policy

1. Open each imported escalation policy.
2. Press Send Test Alert and watch every level land on the right phone.

Week 1: Repoint low-stakes sources

1. List enabled Opsgenie integrations and pick the lowest-stakes one.
2. Repoint it to AlertKick and confirm an alert arrives and pages.
3. Run both systems in parallel for a couple of weeks.

Cutover

1. Repoint the remaining sources one at a time.
2. Disable each Opsgenie integration once its AlertKick path has fired for real.
3. Decommission the Opsgenie account well before 5 April 2027.

The feature page is at /migrate/, the reference docs at inbound integrations, and how rosters work at the on-call roster guide.