OpsGenie migration checklist: 14-step plan to switch before April 2027

OpsGenie shuts down in April 2027, and every team still on the platform needs a migration plan. I put together this 14-step checklist covering the full stack: monitoring, alerting, on-call scheduling, and status pages. Whether you are moving to Hyperping or another platform, this guide walks you through each phase so nothing falls through the cracks.

For a full breakdown of why Atlassian is ending OpsGenie and which platforms are worth evaluating, see the OpsGenie shutdown alternatives guide.

Key Takeaways

• OpsGenie reaches end-of-life in April 2027. New sales already stopped in June 2025.
• A full migration typically takes four to eight weeks across four phases: audit, setup, parallel testing, and cutover.
• Running both platforms in parallel for two to four weeks is the safest way to catch configuration gaps before they cause missed alerts.
• Teams that also replace their separate monitoring tool during migration end up with fewer tools, lower costs, and simpler operations.
• Start now. Waiting until early 2027 leaves almost no room for proper testing.

Why you should start migrating now, not in 2027

I analyzed the OpsGenie shutdown timeline, and the window for a comfortable migration is narrower than most teams realize. The table below shows what has already happened and what is coming.

Date	Event
December 2024	Atlassian announces OpsGenie end-of-life
June 2025	New OpsGenie sales stopped
October 2025	JSM-bundled OpsGenie access ends
April 2027	Complete OpsGenie shutdown

Starting your migration in Q1 or Q2 of 2026 gives you a full year of buffer. That is enough time to audit your setup, evaluate alternatives, run a parallel period, and handle unexpected issues without pressure.

Teams that wait until late 2026 or early 2027 face a different reality. Vendor support queues will be packed with last-minute migrations. Your on-call engineers will be learning a new platform while handling production incidents. And if something goes wrong during cutover, you will not have time to roll back and try again.

I noticed in community discussions that many OpsGenie customers also rely on separate monitoring tools alongside OpsGenie for alerting. If that describes your setup, migration is a good opportunity to consolidate. Platforms like Hyperping bundle monitoring, on-call, and status pages together, which means you can replace OpsGenie AND your monitoring tool in one move.

Phase 1: Audit your OpsGenie setup (steps 1-4)

Before you configure anything in a new platform, you need a complete picture of what you are running in OpsGenie today. I recommend spending a full week on this phase. Rushing through the audit is the most common reason migrations hit problems later.

Step 1: Export on-call schedules and rotations

Log into OpsGenie and pull out every on-call schedule. For each rotation, record:

• Team name and members
• Rotation type (daily, weekly, custom)
• Handoff times and timezone settings
• Override rules and restrictions

Save these as JSON exports using the OpsGenie API. The dashboard export works too, but the API gives you structured data that is easier to import into your new platform.

If you have complex rotations with multiple layers (primary, secondary, manager escalation), document each layer separately. I came across several teams who missed secondary rotations during migration and only discovered the gap when an escalation failed in production.

Step 2: Document escalation policies

Escalation policies are where most of the complexity lives. For each policy, capture:

• Number of escalation steps
• Timeout between each step (how long before escalating)
• Who gets notified at each level
• Notification channels per step (SMS, phone, Slack, email)
• Any time-based or conditional routing

Write this down in a spreadsheet or document, not just in your head. You will reference this repeatedly during setup. For guidance on structuring your policies in the new platform, check out these escalation policy templates.

Step 3: Inventory all integrations

This step catches people off guard. OpsGenie often has more integrations than teams remember. Open the integrations page and list every active connection. Common ones include:

• Monitoring tools (Datadog, Prometheus, Grafana, CloudWatch)
• CI/CD pipelines (GitHub Actions, Jenkins, CircleCI)
• Ticketing systems (Jira, ServiceNow, Linear)
• Chat platforms (Slack, Microsoft Teams)
• Custom webhooks and API-based integrations
• Email integrations

For each integration, note the direction of data flow (inbound alerts, outbound notifications, or bidirectional) and save any API keys or webhook URLs. You will need these when reconnecting integrations to your new platform.

Step 4: Map alert routing rules

Alert routing is the logic that decides which alert goes to which team. In OpsGenie, this includes:

• Alert policies and filters
• Priority mappings
• Tag-based routing
• Service-to-team assignments
• Auto-close and auto-acknowledge rules
• Quiet hours and maintenance windows

Document the full path an alert takes from source to responder. Draw it out if that helps. I found that teams with more than ten routing rules almost always have at least one rule they forgot about, which leads to missed alerts after migration.

Phase 2: Set up your new platform (steps 5-8)

With your audit complete, you can start building in your new platform. I recommend doing this in the order below because each step builds on the previous one. If you are evaluating platforms, the best on-call scheduling tools comparison is a good starting point.

Step 5: Recreate on-call schedules

Using the data from Step 1, rebuild your on-call schedules. Pay close attention to:

• Timezone handling (this is the most common source of errors)
• Rotation start dates aligning with your current cycle
• Override rules matching your existing setup
• Team member assignments and contact methods

Test each schedule by checking who is on-call at various times of day. Compare the result against OpsGenie's current schedule to confirm they match.

Step 6: Configure monitors for HTTP, SSL, and cron jobs

If your new platform includes built-in monitoring (Hyperping does, for example), set up monitors for every critical service:

• HTTP monitors for API endpoints and web applications
• SSL certificate expiry monitors for all domains
• Cron job heartbeat monitors for scheduled tasks
• TCP/port monitors for database and service health

This is where consolidation pays off. Instead of maintaining a separate monitoring tool that feeds into OpsGenie, you get monitoring and alerting in one place. Fewer moving parts means fewer things to break.

For teams currently using a standalone monitoring platform alongside OpsGenie, this step effectively replaces two tools with one. The OpsGenie integration migration guide covers the technical details of reconnecting your monitoring sources.

Step 7: Set up status pages

If you use OpsGenie status pages (or a separate status page provider), migrate them now:

• Recreate your component list and component groups
• Configure subscriber notification preferences
• Set up custom domain DNS records
• Match your brand styling and logo

Do not leave status page migration for last. DNS propagation and custom domain SSL provisioning can take time. The status page migration guide covers the full process.

Step 8: Connect notification channels

Configure every notification channel your team uses:

• Slack (channel alerts, direct messages, or both)
• Microsoft Teams
• Email (individual and distribution lists)
• SMS and phone calls
• Webhooks to other internal tools

Send a test alert through each channel individually. Confirm that the message format includes the information your team needs: monitor name, status, affected service, and a link to the incident. Broken notification channels are invisible until a real incident hits.

Phase 3: Run both platforms in parallel (steps 9-11)

This phase is where you build confidence. I recommend running both platforms simultaneously for at least two weeks, ideally four. The goal is to confirm that your new setup catches everything OpsGenie catches, with the same speed and reliability.

Step 9: Enable dual monitoring

Configure your alert sources to send notifications to both OpsGenie and your new platform at the same time. There are two common approaches:

• Dual webhook delivery: Point your monitoring tools at both platforms via separate webhook endpoints
• Alert forwarding: Use OpsGenie's integration to forward alerts to your new platform

The second approach is simpler if your new platform supports it. Hyperping's OpsGenie integration works this way, letting you receive OpsGenie alerts in Hyperping during the transition.

Step 10: Validate alert delivery and timing

During the parallel period, compare the two platforms side by side. For each alert, check:

Metric	What to compare
Delivery speed	Time from trigger to notification in each platform
Channel coverage	Did both platforms notify via the correct channels
On-call accuracy	Did both platforms page the right engineer
Escalation behavior	Did escalations trigger at the right timeouts
Alert content	Does the new platform include enough context

Log any discrepancies in a shared spreadsheet. Most gaps come from timezone mismatches, incorrect routing rules, or missing integrations. Fix each issue as you find it rather than batching fixes for later.

Step 11: Compare incident response times

Track your team's response metrics on both platforms:

• Mean time to acknowledge (MTTA)
• Mean time to resolve (MTTR)
• Escalation rate
• False positive rate

Your new platform should match or improve on these numbers. If MTTA is higher on the new platform, investigate whether the issue is configuration (wrong notification channels) or tooling (slower alert delivery). Address the root cause before moving to cutover.

Phase 4: Cutover and cleanup (steps 12-14)

Once you are confident in the parallel results, schedule the cutover. I recommend doing this on a weekday morning when your full team is available, not on a Friday afternoon.

Step 12: Disable OpsGenie alert routing

The cutover itself is straightforward:

1. Disable inbound integrations in OpsGenie (stop new alerts from arriving)
2. Update webhook URLs in your monitoring tools to point only to the new platform
3. Verify that the new platform is receiving all alerts
4. Keep OpsGenie accessible in read-only mode for at least 30 days

Do not delete your OpsGenie account immediately. You will want access to historical alert data and incident records during the transition period.

Step 13: Update runbooks and internal documentation

Search your internal documentation for every reference to OpsGenie and update it:

• Incident response playbooks
• Onboarding guides for new engineers
• Wiki pages and knowledge base articles
• Terraform or infrastructure-as-code configurations
• CI/CD pipeline alert configurations
• External vendor documentation that references your OpsGenie endpoints

This step is tedious but critical. An engineer following an outdated runbook during a 3 AM incident will lose time trying to log into a platform that no longer works.

Step 14: Archive configuration exports and decommission

Save final copies of everything from OpsGenie:

• Schedule and rotation configurations
• Escalation policy exports
• Alert history and incident reports
• Integration configurations
• Audit logs

Store these archives somewhere accessible (cloud storage, internal wiki) so you can reference them if questions come up later. Then cancel your OpsGenie subscription or let it run until the April 2027 deadline.

Common migration mistakes to avoid

I gathered feedback from teams who have already started their OpsGenie migrations, and several patterns keep coming up.

Rushing the cutover without enough parallel testing. Two weeks of parallel monitoring is the minimum. Teams that cut over after just a few days often discover routing gaps during their first real incident on the new platform.

Forgetting about webhooks and API integrations. Dashboard integrations are easy to spot, but custom webhooks buried in scripts and automation pipelines are easy to miss. The integration inventory in Step 3 exists specifically to catch these.

Not testing escalation paths end to end. Setting up escalation policies is one thing. Actually triggering a test alert and watching it escalate through every step, including phone calls and SMS, is another. Test the full path, not just the first notification.

Ignoring status page DNS and custom domains. If you use a custom domain for your status page, the DNS switch needs to happen before cutover. CNAME records and SSL certificates can take hours to propagate. Plan accordingly.

Migrating only alerting and forgetting monitoring. If you are using a separate monitoring tool that feeds into OpsGenie, remember that you are really migrating two systems. This is an opportunity to consolidate. The Hyperping comparison page breaks down how a unified platform handles both.

How Hyperping simplifies the migration

I wanted to call out why Hyperping works well for OpsGenie migrations specifically.

Built-in monitoring means fewer tools to manage. Most OpsGenie customers also pay for a separate uptime monitoring platform. Hyperping combines HTTP, SSL, cron job, and port monitoring with on-call scheduling and alerting. That means your migration replaces two subscriptions with one, starting at $24/mo for 50 monitors with on-call and escalation policies included.

The OpsGenie integration supports gradual transitions. You do not have to rip and replace overnight. Hyperping's OpsGenie integration lets you forward OpsGenie alerts into Hyperping during the parallel phase. Your team can get comfortable with the new interface while OpsGenie still handles routing.

Status pages are included, not a separate add-on. OpsGenie bundles basic status pages, and many teams pair it with a separate status page provider. Hyperping includes customizable status pages with custom domains, subscriber notifications, and component grouping at no extra cost.

On-call scheduling with escalation policies works out of the box. Recreating your OpsGenie schedules in Hyperping is straightforward: define rotations, set escalation timeouts, and connect notification channels. No separate on-call tool needed.

For teams evaluating their full range of options, the OpsGenie shutdown alternatives guide covers how Hyperping compares to PagerDuty, Incident.io, Grafana OnCall, and other alternatives. You can also learn more about how to replace OpsGenie AND your monitoring tool in a single migration.

Migration timeline at a glance

Phase	Steps	Duration	Key deliverable
Phase 1: Audit	Steps 1-4	1 week	Complete configuration export and documentation
Phase 2: Setup	Steps 5-8	1-2 weeks	New platform fully configured and tested
Phase 3: Parallel	Steps 9-11	2-4 weeks	Validated alert delivery with matching response metrics
Phase 4: Cutover	Steps 12-14	2-3 days	OpsGenie decommissioned, documentation updated

Total estimated timeline: 4 to 8 weeks.

Starting in Q1 or Q2 of 2026 gives your team plenty of room to handle surprises. If you are ready to begin, Hyperping offers a free plan with 20 monitors and a status page so you can evaluate the platform before committing to the full migration.