Opsgenie Migration Guide: Move Before April 5, 2027

Organizations depend on incident management platforms to keep critical services available, coordinate responders, and minimize downtime during outages. When the incident management platform itself becomes a source of friction, teams often begin evaluating alternatives that better support modern reliability practices.

For many engineering, SRE, and operations teams, that evaluation leads to a migration from Opsgenie to Rootly — and there is now a deadline on it. Atlassian retired Opsgenie from sale on June 4, 2025, and support ends on April 5, 2027.

As of October 2026, that leaves less than six months to choose a destination, move schedules and escalation policies, and get every on-call engineer comfortable with the new pager. Teams that start in the final quarter tend to rush the parts that matter most: escalation logic, integration coverage, and responder training. If you are still comparing tools, start with Rootly vs Opsgenie and the Rootly On-Call overview.

A successful migration involves much more than moving schedules and integrations. Teams must preserve on-call coverage, maintain escalation paths, train responders, and ensure incidents continue to be managed effectively throughout the transition.

Whether you’re replacing Opsgenie due to changing operational requirements, workflow complexity, or a desire for more modern incident response capabilities, a structured migration process can help reduce risk and ensure a smooth transition. Careful planning, thorough testing, and gradual rollout strategies can help teams maintain reliability while adopting new workflows and tools.

Why teams are moving from Opsgenie to Rootly

The changing incident management landscape

Incident management has evolved significantly over the past decade.

Organizations are increasingly looking for platforms that combine on-call management, incident response, communication, automation, postmortems, and reliability workflows into a unified experience. Instead of managing multiple disconnected tools, teams want a centralized system that supports the entire incident lifecycle.

Common reasons teams leave Opsgenie

Rising operational complexity

As organizations scale, maintaining large numbers of schedules, escalation policies, routing rules, and integrations can become increasingly difficult.

Alert fatigue

Many teams struggle with excessive alert volume. When responders receive too many notifications, important alerts can be overlooked, increasing response times and operational risk.

Fragmented incident workflows

Modern incidents often require coordination across engineering, security, support, product, communications, and leadership teams. Fragmented tooling can make collaboration slower and less efficient.

Growing demand for automation

Organizations increasingly expect automation to assist with incident creation, responder coordination, stakeholder communications, and post-incident reviews.

Why teams choose Rootly

Slack-native Incident Response

Rootly enables teams to coordinate incidents directly within Slack, allowing responders to work where collaboration already happens.

AI-powered automation

AI-assisted workflows help reduce manual effort throughout the incident lifecycle, from incident declaration to postmortem generation.

Integrated incident lifecycle management

Rather than relying on multiple tools, organizations can manage on-call schedules, incidents, communications, status updates, and postmortems from a single platform.

Faster coordination during critical incidents

Automated workflows reduce delays and help ensure the right responders are engaged quickly.

Signs it’s time to migrate from Opsgenie

Your organization may be ready for migration if you experience:

• Slow incident response times
• Alert overload
• Excessive manual coordination
• Limited visibility during incidents
• Difficulty scaling on-call programs
• Fragmented communication workflows
• Challenges conducting post-incident reviews

Opsgenie vs. Rootly: What changes after migration?

Feature comparison

Capability	Opsgenie	Rootly
On-call scheduling	Yes	Yes
Escalation policies	Yes	Yes
Incident response workflows	Basic	Advanced
Slack-native operations	Limited	Native
Automation	Moderate	Extensive
Status pages	Available	Integrated
Postmortems	External workflow	Built-in
AI-powered features	Limited	Extensive

Major workflow differences

Opsgenie’s alert-centric approach

Opsgenie primarily focuses on alerts and notifications. Incidents often require coordination across multiple tools.

Rootly’s incident-centric approach

Rootly organizes workflows around the incident itself, helping teams manage response, collaboration, communication, and resolution from a centralized command center.

What your team will need to relearn

Migration typically requires teams to adapt to:

• Incident declaration workflows
• Slack-based coordination
• Incident ownership models
• Stakeholder communication processes
• Automated response workflows
• Postmortem generation procedures

Planning your Opsgenie migration strategy

A successful migration starts long before any schedules, integrations, or escalation policies are moved. Organizations that invest time in planning are more likely to avoid service disruptions, maintain responder confidence, and achieve their desired operational improvements.

Before configuring Rootly, teams should determine how the migration will be executed, who will be responsible for key decisions, and how the transition will be communicated across the organization.

Choosing the right migration approach

There is no single migration strategy that works for every organization. The right approach depends on team size, operational complexity, risk tolerance, and the number of critical services involved.

1. Big bang migration

A big bang migration moves all teams, schedules, integrations, and workflows to Rootly at the same time.

This approach can shorten the overall migration timeline and reduce the need to manage two platforms simultaneously. However, it also carries greater risk because any configuration issues, integration failures, or workflow gaps can affect the entire organization immediately.

Big bang migrations are typically better suited for smaller teams with relatively simple incident management environments.

2. Phased migration

A phased migration gradually moves teams and services to Rootly over a defined period.

Many organizations start with a pilot team before expanding adoption to additional engineering groups. This allows teams to validate configurations, gather feedback, refine workflows, and address issues before broader deployment.

For most mid-sized and enterprise organizations, a phased approach provides the safest path to migration.

3. Hybrid migration

A hybrid migration combines elements of both approaches.

Some critical services remain on Opsgenie temporarily while lower-risk services migrate first. This strategy helps organizations reduce risk while maintaining confidence that mission-critical systems remain protected throughout the transition.

Hybrid migrations are often used by organizations with complex environments, strict uptime requirements, or regulatory obligations.

Building a migration team

Migration projects are most successful when ownership is clearly defined from the beginning.

Because incident management affects multiple departments, organizations should involve representatives from all teams that participate in incident response. This helps ensure that operational requirements are captured and that new workflows support both technical and business needs.

Successful migrations typically involve:

• SRE leaders
• Platform engineers
• Incident managers
• Engineering leadership
• Security teams
• Operations stakeholders

Assigning clear responsibilities for planning, implementation, testing, training, and rollout can help prevent confusion and keep the migration on schedule.

Communicating the migration internally

Even well-designed migrations can struggle if responders are not prepared for new workflows.

Clear communication helps teams understand why the migration is happening, what changes to expect, and how incident response processes will evolve after deployment.

Organizations should establish:

• Migration timelines
• Training schedules
• Support channels
• Escalation contacts
• Go-live expectations

Regular updates throughout the project can improve adoption, reduce uncertainty, and ensure responders are comfortable using Rootly before the final cutover occurs.

Pre-migration checklist: What to audit before leaving Opsgenie

Inventory Your Existing Setup

• Teams
• Users
• Schedules
• Escalation Policies
• Integrations
• Alert Routing Rules
• Services
• Notification Settings

You do not have to click through the Opsgenie console to collect this. The Opsgenie REST API returns the same inventory, which is faster on a large tenant and gives you a diffable record of what the configuration looked like before you touched it.

Use the API host that matches where your account lives — api.opsgenie.com for US instances, api.eu.opsgenie.com for EU. Pointing at the wrong one returns an empty or unauthorised response rather than an obvious error, which is a common early stumble.

# Teams — returns the whole list in one response
curl -X GET "https://api.opsgenie.com/v2/teams" \
  -H "Authorization: GenieKey <YOUR_API_KEY>"

# On-call schedules — also returns the whole list
curl -X GET "https://api.opsgenie.com/v2/schedules" \
  -H "Authorization: GenieKey <YOUR_API_KEY>"

# Users — paginated, so one call is not the inventory.
# `username` is the email Rootly matches on.
offset=0
: > opsgenie-users.jsonl
while :; do
  page=$(curl -sS -X GET \
    "https://api.opsgenie.com/v2/users?limit=100&offset=$offset" \
    -H "Authorization: GenieKey <YOUR_API_KEY>")
  echo "$page" | jq -c '.data[]' >> opsgenie-users.jsonl
  echo "$page" | jq -e '.paging.next' > /dev/null 2>&1 || break
  offset=$((offset + 100))
done

# Must match totalCount from the last response, or the inventory is short.
wc -l < opsgenie-users.jsonl

The loop matters more than it looks. GET /v2/users defaults to limit=100, offset=0, so a tenant with 250 people answers a single call with 100 of them and no error. Save that as your inventory and the 150 it left out read as missing accounts at matching time, and as data you lost when you run the before-and-after diff. Reconcile the line count against totalCount before trusting it.

Teams and schedules return complete lists, so they need no loop — worth knowing rather than assuming, because the three endpoints do not share a response contract and pagination code copied across all three will look like it works.

Save the output. Two things make it worth keeping: the user list is what determines whether people are matched to existing Rootly accounts or provisioned fresh, and the before-and-after diff is the fastest way to answer “did we lose anything?” once the migration is done.

Review Current Pain Points

• What causes delayed response?
• Which alerts generate noise?
• What workflows require manual effort?
• Where does collaboration break down?

Identify Mission-Critical Processes

• Customer-facing systems
• Revenue-generating services
• Compliance-sensitive systems
• Critical escalation paths

Define Migration Goals

• Faster MTTR
• Better collaboration
• Fewer alerts
• Improved visibility
• Reduced operational overhead
• Better incident communication

What data can and cannot be migrated from Opsgenie?

One of the most important parts of an Opsgenie migration is understanding which data, workflows, and configurations can be moved directly and which ones may need to be rebuilt manually.

Not every Opsgenie setup maps perfectly into a new incident management platform. Some components can be migrated with minimal changes, while others should be reviewed, simplified, or redesigned before being recreated in Rootly.

Users and teams

Rootly imports Opsgenie users and matches them by email: the Opsgenie username is treated as the email address, an existing Rootly user with that email is reused, and anyone without a Rootly account is created with their name and time zone from Opsgenie. Opsgenie teams import as Rootly teams, with their routing rules alongside, so ownership carries over.

Before migration, teams should review user lists to remove inactive accounts, confirm current team ownership, and make sure every service has the right responders assigned. This is also a good time to clean up outdated roles, permissions, and team structures that may no longer reflect how the organization operates.

On-call schedules

Rootly imports schedule definitions, rotations, and overrides, then generates future shifts from the imported rotations. Schedules with overlapping rotations can import as one schedule or as one schedule per rotation, whichever makes the result easier to read.

Teams should confirm rotation frequency, shift start times, time zones, holiday coverage, backup responders, and handoff rules. Even small schedule errors can create coverage gaps, so every schedule should be tested before the final cutover.

Escalation Policies

Escalation policies are covered during migration scoping with the Rootly team, and migration is a good opportunity to simplify unnecessary complexity.

Many Opsgenie environments accumulate outdated rules over time. Before rebuilding escalation policies, teams should confirm who owns each service, when escalations should trigger, and which responders should be notified at each stage.

Historical incidents

Historical incident data may need to remain archived for compliance, reporting, or internal review purposes.

Before decommissioning Opsgenie, organizations should determine whether past incident records need to be exported, stored, or referenced in future postmortems and reliability reviews.

Alert history

Alert history is useful for understanding incident trends, noisy services, recurring failures, and alert fatigue.

Organizations should review retention requirements before migration and decide which alert data should be preserved. This can help teams compare pre-migration and post-migration performance once Rootly is fully adopted.

Runbooks and documentation

Existing runbooks and documentation should be reviewed before they are moved or linked into the new workflow.

Outdated documentation can create confusion during incidents. Teams should update escalation instructions, service ownership details, troubleshooting steps, communication templates, and post-incident review processes before go-live.

What may require manual recreation

Some custom workflows, integrations, routing rules, and notification logic may require manual configuration and validation.

This is especially common for organizations with complex routing logic, custom monitoring integrations, unusual escalation rules, or workflows built around legacy processes. These items should be documented early, rebuilt carefully, and tested through incident simulations before launch.

Notification rules and contact methods

Each Opsgenie notification rule step becomes a Rootly notification rule. The email, sms, and voice contact methods map to Rootly email, SMS, and call targets, and each step’s delay carries over, so responders are paged at the same offsets they are used to. Rootly then adds any missing default rules so no responder is left with a partial setup.

How the Rootly-led Opsgenie import works

Rootly runs the import for you over the Opsgenie API, with read-only access. Nothing in your Opsgenie account is modified or deleted, so both systems can run side by side until you cut over. The process is documented in the Opsgenie migration guide on docs.rootly.com:

1. Define scope and success criteria. Decide which Opsgenie teams move first, whether services and routing rules come with them, and what “done” means, for example every responder reachable on at least one channel and correct shifts for the next two to four weeks.
2. Create a read-only Opsgenie API key. In Opsgenie, go to Settings, then App Settings, then API key management, add a key with read permissions for users, teams, schedules, and services, and share it with Rootly over your approved secure channel.
3. Run a dry run. The dry run reports what would import, which users cannot be matched, and which schedules need the split-rotation option, without writing anything into Rootly.
4. Run the migration. The import runs in the background in dependency order: users and services, then teams and routing rules, then schedules, rotations, overrides, and shift generation.
5. Validate in Rootly. Check who is on call now and for upcoming shifts, confirm overrides and time zones, and send real test pages to a sample of responders.
6. Cut over and monitor. Point alert sources at Rootly On-Call and watch the first days of production paging closely.

You can scope the import to specific Opsgenie teams, exclude teams, or limit it to a list of users, which is what makes a team-by-team rollout practical. PagerDuty and Opsgenie migration is included on every Rootly plan. Rootly On-Call is $20 per user per month, and Incident Response is another $20 per user per month; see pricing for plan details.

How to migrate from Opsgenie to Rootly: Step-by-step

Step 01: Map Existing Opsgenie Workflows

Document teams, escalations, rotations, integrations, services, severity levels, and notification rules.

Step 02: Set Up Rootly

Configure workspace settings, teams, permissions, service ownership, Slack, and incident workflows.

Step 03: Rebuild On-Call Schedules

Verify rotations, time zones, shift schedules, backup responders, and handoff procedures.

Step 04: Recreate Escalation Policies

Validate primary responders, secondary responders, management escalation, and ownership assignments.

Step 05: Migrate Integrations

Connect monitoring, communication, and ticketing tools such as Datadog, Slack, Jira, ServiceNow, and Linear.

Step 06: Configure Incident Workflows

Define severity levels, incident declaration, war rooms, stakeholder updates, escalation triggers, and resolution workflows.

Step 07: Test Before Go-Live

Validate notifications, escalations, integrations, runbooks, communication workflows, and automation.

Step 08: Run a Phased Rollout

Start with a pilot team, expand gradually, then complete production cutover once workflows are validated.

Common Opsgenie migration challenges and how to avoid them

Opsgenie migrations can become risky when teams rush the process, skip testing, or copy old workflows without reviewing them first. The most common issues usually involve broken escalations, missed dependencies, poor documentation, and limited team adoption.

Broken Escalation Policies

Incorrect escalation policies can prevent alerts from reaching the right responders. Document each escalation chain before migration, confirm current service owners, and test every path before launch.

Alert routing errors

Routing errors can send incidents to the wrong team or cause alerts to be missed. Test monitoring integrations, alert rules, notification paths, and failover logic before go-live.

On-call schedule conflicts

Schedule issues often involve time zones, holidays, handoffs, or overlapping shifts. Review each schedule carefully to avoid coverage gaps during and after migration.

Missing integrations and dependencies

Overlooked tools can create visibility gaps after migration. Before launch, map monitoring tools, services, escalation rules, communication channels, ticketing systems, and ownership relationships.

Slack workflow adoption issues

Teams may need time to adjust to Slack-native incident response. Train responders on how to declare incidents, acknowledge alerts, escalate issues, and update stakeholders in Rootly.

Documentation gaps

Outdated documentation can slow response during incidents. Update runbooks, severity definitions, escalation instructions, ownership records, and communication workflows before launch.

Moving everything at once

Large-scale migrations increase risk unnecessarily. A phased rollout gives teams time to identify issues, collect feedback, and improve workflows before full adoption.

Team resistance to change

Responders may be hesitant to change familiar workflows. Involve stakeholders early, explain the benefits, communicate timelines clearly, and use a pilot rollout to build confidence.

Best practices for a smooth Opsgenie to Rootly migration

A smooth migration depends on careful planning, testing, and team preparation. The goal is to reduce risk while making sure responders are ready to use the new workflows confidently. That’s why Rootly works hand-in-hand with you every step of the way.

Avoid big-bang migrations

Moving everything at once can increase the risk of missed alerts, broken escalations, and team confusion. A gradual migration gives teams more time to test workflows and fix issues before full rollout.

Start with a pilot team

Begin with one team or service before expanding across the organization. A pilot helps identify configuration issues, training gaps, and workflow improvements early.

Document existing workflows first

Before rebuilding anything, document schedules, escalation policies, integrations, routing rules, and service ownership. Strong documentation helps prevent missed configurations.

Train teams before launch

Responders should know how to declare incidents, acknowledge alerts, escalate issues, and communicate updates in Rootly before go-live.

Run parallel systems temporarily

Keeping Opsgenie and Rootly active for a short period can reduce risk during transition. This gives teams time to confirm that alerts and escalations work correctly.

Test every escalation path

Do not assume configurations are correct. Test each escalation path, notification rule, and integration before fully switching over.

Keep stakeholders updated

Regular updates help reduce uncertainty and improve adoption. Communicate timelines, training plans, go-live dates, and support channels throughout the migration.

Migration timeline: How long does an Opsgenie migration take?

Small teams (1–25 engineers)

Typically one week.

Mid-market organizations

Typically two to four weeks.

Enterprise organizations

Often six to twelve weeks or longer depending on complexity.

Working back from April 5, 2027

Opsgenie support ends on April 5, 2027, so plan the calendar backwards from that date rather than forwards from today:

• Now: inventory teams, users, schedules, escalation policies, integrations, and routing rules, and decide whether historical alert and incident data needs exporting.
• Next four to six weeks: run the dry run, fix unmatched users and schedule edge cases, and import into Rootly.
• Following month: run one pilot team in parallel, with alerts firing into both systems, for at least a full rotation.
• Remaining time: move the other teams in waves, keep Opsgenie live until the last wave is verified, and export anything you need to keep before access ends.

Factors that affect timeline

• Number of integrations
• Team size
• Workflow complexity
• Compliance requirements
• Number of services
• Documentation maturity

How to measure migration success

MTTR improvements

Measure whether mean time to resolution decreases after migration.

Alert reduction

Track whether noise and unnecessary notifications decrease.

Incident participation

Evaluate responder engagement and collaboration.

Escalation effectiveness

Monitor whether incidents reach the correct owners more quickly.

Team satisfaction

Collect feedback from responders and stakeholders.

Reliability metrics

Monitor:

• MTTR
• MTTA
• Incident volume
• Escalation success rates
• Service availability

Opsgenie to Rootly migration checklist

Before migration

• Audit existing configurations
• Inventory integrations
• Review schedules
• Document escalation policies
• Define migration goals

During migration

• Configure Rootly environment
• Rebuild schedules
• Migrate integrations
• Configure incident workflows
• Conduct testing

After migration

• Complete incident simulations
• Train teams
• Validate reporting
• Review performance metrics
• Decommission Opsgenie

Real-world example: What a good Opsgenie migration looks like

Example migration scenario

A growing engineering organization struggled with alert fatigue, fragmented incident communication, and increasing operational complexity.

The migration project began with a comprehensive audit of schedules, integrations, and escalation paths.

A pilot engineering team migrated first, allowing the organization to refine workflows before broader adoption.

After full rollout, the organization achieved faster incident coordination, improved collaboration, and reduced operational overhead.

Lessons learned from successful migrations

Common lessons include:

• Document everything before migration
• Test more than expected
• Train teams early
• Avoid rushing the rollout
• Keep stakeholders informed

How Rootly improves incident response after Opsgenie

1. Faster Incident Coordination: Automated workflows help teams mobilize responders faster and reduce delays during critical incidents.
2. Slack-Native Management: Collaborate directly in Slack without constantly switching between multiple platforms.
3. Better Visibility: Give stakeholders clearer insight into incident ownership, status, and progress.
4. Automated Postmortems: Generate timelines and documentation automatically for more consistent reviews.
5. AI-Powered Workflows: Reduce repetitive tasks and administrative overhead throughout the incident lifecycle.
6. Reduced MTTR: Improve response efficiency and help teams resolve incidents more quickly.

Case study: How Motive moved from Opsgenie to Rootly

Motive powers the physical economy by offering a full range of products to support fleets ranging from a couple of vans to tens of thousands of light and heavy vehicles.

Even before Atlassian’s sunset notice, Motive had already moved from Opsgenie to Rootly  because the features were simply better. On-call scheduling in Slack used to mean custom bots and manual hacks. Now, it’s seamless. The team handles shifts, escalations, and incidents right inside Slack, no duct tape required.

▶

Frequently asked questions

Can you migrate from Opsgenie to Rootly?

Yes. Organizations commonly migrate schedules, escalation policies, integrations, incident workflows, and operational processes from Opsgenie to Rootly.

Why are companies moving away from Opsgenie?

Common reasons include operational complexity, alert fatigue, fragmented tooling, and the desire for more integrated incident management workflows.

How long does an Opsgenie migration take?

Timelines vary from a few weeks for smaller teams to several months for large enterprise environments.

Does Rootly replace Opsgenie?

For many organizations, Rootly serves as a comprehensive replacement for on-call management and incident response workflows.

Can Rootly handle on-call scheduling?

Yes. Rootly supports on-call schedules, rotations, escalation paths, and responder management.

What data can we take with us from Opsgenie?

The Rootly-led import covers users, teams and their routing rules, schedules with rotations and overrides, services, and notification rules. Historical incident and alert data is the part teams most often lose, so decide early whether you need it exported for compliance or reporting, and export it before access ends on April 5, 2027.

Should we run Rootly and Opsgenie in parallel?

Many organizations temporarily run both platforms during migration to reduce risk.

What integrations should be migrated first?

Critical monitoring, communication, and ticketing integrations should typically be prioritized.

How do you test a migration before launch?

Organizations should conduct paging tests, escalation simulations, workflow validation, and incident exercises before cutover.

What should we migrate to before Opsgenie end of life in April 2027?

Atlassian points Opsgenie customers to Jira Service Management, an IT service desk product, so many engineering teams also evaluate dedicated incident platforms such as Rootly and PagerDuty. Compare three things: whether the tool keeps the concepts your engineers already use (schedules, rotations, overrides, escalation policies), whether there is an import for that configuration rather than manual re-entry, and whether it covers the full incident lifecycle or only paging.

Opsgenie is being discontinued: what are our options?

There are three. Move to Jira Service Management, which keeps you in the Atlassian suite but moves you to a ticket-centric ITSM model. Move to another paging tool, which meets the deadline but leaves incident response, communication, and retrospectives in separate tools. Or use the migration to adopt a platform that covers on-call, incident response, status pages, and retrospectives together. The migration work is similar in all three cases.

How do we plan an Opsgenie migration without downtime?

Run the two systems in parallel instead of cutting over in one step. Inventory schedules, escalation policies, integrations, and routing rules first. Import what the Rootly-led import covers, set up escalation policies and integrations with the Rootly team, and validate everything with real test pages. Run one team’s on-call in both systems for a full rotation so you can compare behavior. Move the remaining teams in waves, keep Opsgenie live until the last wave is verified, and decommission it only after a full rotation has completed on Rootly.

What is the biggest migration mistake to avoid?

Skipping documentation and testing are among the most common causes of migration problems.

Making the move from Opsgenie to Rootly successfully

Most migration failures are not caused by technology. They happen because teams rush implementation, skip testing, overlook documentation, or fail to prepare responders for new workflows.

A successful Opsgenie migration requires careful planning, clear ownership, comprehensive testing, and gradual adoption. Organizations that take a structured approach can minimize disruption while improving incident response capabilities.

As incident management continues to evolve, many teams are looking for platforms that bring together on-call operations, incident response, automation, collaboration, postmortems, and reliability workflows into a unified experience.

At Rootly, we help teams modernize incident management with faster coordination, automated workflows, and a more connected approach to reliability operations. Book a demo to see how Rootly can help your team make the move from Opsgenie with confidence.