Set up operations and complete your move to Jira Service Management

Once the Jira admin starts the move from Opsgenie to Jira Service Management, almost all your data and settings will have synced to Jira. You’ll need to manually move only some of it as they will need your involvement.

Select Moving from Opsgenie button in Jira Service Management to resume your moving journey. If you don’t see the button, you can select Help > Moving from Opsgenie

Users and roles

All users and roles from Opsgenie get synced with Jira Service Management and are now managed by Atlassian Administration.

It may happen that a few Opsgenie admins or users don’t have the same role in Jira Service Management. Therefore, you might not be able to manage notification settings for all users.

Opsgenie admins who don’t have the product admin role

When the transition begins, any user or team member who is an Admin in Opsgenie but not a Product admin in Jira Service Management will be assigned the Operations global admin role in Jira Service Management. During the transition, these users will continue to have access to all operations functions. Read more about the Operations global admin.

Opsgenie users who no longer have custom roles

This happens if they have a custom role in Opsgenie that isn’t supported by Jira Service Management, so they currently have a User role in Jira.

To fix this: You can give them the product admin role in Jira Service Management so they can continue to have access to configure operations. Read how to make someone a product admin.

Teams

Once you move to Jira Service Management, your current Opsgenie teams will become Atlassian teams and you will gain access to operations. You’ll be able to view the team members, existing on-call schedules, and other team details unless they are considered legacy and have been left behind.

Once your team is moved to Atlassian, it will be visible across all available sites in your organization. However, if you don’t have organization admin permissions, you may not be able to see how many sites are associated with your Atlassian account.

To fix this: Before moving your Opsgenie, contact your organization admin and inform them of this change. If you don't want your teams to be visible across all sites in your Atlassian account, you can contact the support team to restrict the visibility of your teams to the site where you operate.

Team and members' data

In Jira Service Management, you have the flexibility to select the hosting location for your data, if it falls under the category of in-scope data. The data related to teams and team members is not classified as in-scope data. Hence, this particular data can be hosted in any of Atlassian's data center locations. Understand data residency.

Data residency

If your data residency regions for Opsgenie and Jira Service Management are different, raise a support ticket and we’ll help you move your Opsgenie data residency to the one supported by your Jira Service Management instance.

Read more about data residency.

Integrations

Once the Jira admin starts the move from Opsgenie to Jira Service Management, the integrations you’ve configured in Opsgenie get synced with Jira Service Management, without any changes. You’ll now find your integrations in Settings > Products > Integrations.

Things you need to know:

• Incoming call routing integrations do get synced with Jira Service Management, but they’re no longer considered integrations. They’re now a separate, native functionality called Incoming call routing. To manage incoming call routing, go to Settings > Products > Incoming call routing.

• Your chat integrations don’t get automatically moved to Jira Service Management, because your chat tools are connected with Opsgenie. You’ll need to connect and configure your chat integrations in Jira Service Management. Read how to move your chat integrations.

• Your Opsgenie’s integrations with Jira Software and Jira Service Management are now available as Sync in Settings > Products > Syncs. You can set up more syncs with your service and software projects on the same site, or a different site. Read more about sync.

Outdated integrations unavailable to configure in Jira Service Management

Outdated versions of about 24 integrations will not be available for new configurations in JSM. While existing integrations in Opsgenie using these versions will still be moved, you can't create new integrations for these versions in Jira Service Management. However, you can view and edit these configured integrations in Jira Service Management.

Here are the unavailable integrations:

• Campfire(Chat)

• XMPP/Jabber

• CA Flowdock (Chat)

• Compose

• Logentries

• Outlyer

• Small Business Customer Service Software

• Soasta

• Dynatrace AppMon

• Crashlytics

• Loom

• Monitis

• Pingdom Server Monitor

• Pingometer

• Rigor

• Runscope

• SaltStack

• Statusy

• Threat Stack

• Thundra

• Trace by RisingStack

• UptimeProject

• Stackdriver

• OEC

Outdated integration versions that won’t move to Jira Service Management

Certain outdated versions of Opsgenie integrations with some products won't be moved to Jira Service Management. However, they'll remain functional in Opsgenie until Opsgenie is turned off. If your Opsgenie has any outdated integrations configured, we’ll show you those before you start your move into Jira Service Management.

You may still find some of these integrations available for configuration in Jira Service Management. These are newer versions of those integrations, and you'll need to configure them from scratch in Jira Service Management.

In the table below, we've outlined the availability of integrations in Opsgenie and Jira Service Management.

• Yes: You can use a newer version of the integration in Jira Service Management and set up instances from scratch.

• No: The integration isn't available for addition in Jira Service Management. You can use the outdated version of the integration in Opsgenie, but its existing instances, if any, will not move to Jira Service Management.Integrations unavailable in Jira Service Management

End-of-support integrations: Opsgenie will no longer support the following integrations. They'll remain functional in Opsgenie until Opsgenie is turned off, but you won’t be able to create new instances of these integrations.

• CA Flowdock (Inbox)

• Hp Service Manager

• Snyk

• Jira Server (Beta)

Chat tools for alerting

Your chat integrations aren't automatically moved to Jira Service Management because your chat tools are connected with Opsgenie.

What you need to do:

1. Connect your chat tools with Jira Service Management

2. Then, simply copy your chat integrations from Opsgenie to Jira.

This will let your on-call teams work on alerts from their existing chat channels.

Connect your chat tools with Jira Service Management

From the list of Slack workspaces and Microsoft tenants, select Connect for the ones you wish to use with Jira Service Management. Make sure you’re a member of the Slack workspace or Microsoft tenant you’re trying to connect to.

Once you complete the authorization prompted by Slack or Microsoft Teams, you should see the status in Jira as Connected.

Copy your Opsgenie chat integrations to Jira Service Management

From the list of Opsgenie chat integrations, select Copy to Jira for the ones you want to copy to Jira Service Management. Make sure you’re a member of the channel connected to the chat integration, or else you won’t be able to copy it to Jira Service Management.

If you see Give permission instead of Copy to Jira, this means Jira Service Management needs your permission to create channels and post to channels in Slack and Microsoft Teams.

You can check the connected channel from the Connected to column in the table and join it. If it’s a private channel, then you won’t be able to search it on Slack and Microsoft Teams, you can reach out to your admin for help.

Prevent duplicate notifications from Opsgenie chat integrations

After you copy your chat integrations, you’ll have the same integration active in Opsgenie and Jira Service Management. This means you’ll get duplicate notifications for each alert activity.

To fix this: Select Manage chat integrations in Opsgenie, find and turn off your chat integrations in Opsgenie. This will only turn off your Opsgenie chat integrations, the integrations won’t be deleted. You can turn them back on at any time.

Notifications

Your contact methods, notification, and forwarding rules from Opsgenie are now synced with Jira Service Management, without any changes.

You’ll get alert and on-call notifications as usual, but they’ll be sent by Jira once your move is complete and Opsgenie is turned off. Update your filters and blocklist in your email client to ensure that you have access to email notifications from no-reply@jsm-notifications.atlassian.net.

To manage your alert notification settings, go to Personal settings and select Alerts in Notification settings.

Add Jira Cloud mobile app as your notification method

To get notified of alerts, check on-call schedules, and manage your notifications on the go, get the Jira Cloud mobile app for iOS and Android.

Once you’ve installed it, you can add it as a notification method to start receiving push notifications for alerts and on-call. Your notification rules from Opsgenie will be copied to your Jira Cloud mobile app, without any changes.

Select the mobile devices for which you’d like to add the Jira Cloud app as a notification method and select Add Jira Cloud app as notification method.

Prevent duplicate notifications from Opsgenie mobile app

If you have both the Jira Cloud and Opsgenie mobile apps, there’s a good chance you’ll end up getting duplicate notifications for every alert or on-call activity.

To fix this: Turn off the Opsgenie mobile app in your contact methods. This will only turn off your Opsgenie mobile app as a contact method, so your notification rules and preferences will not be affected.

Select Turn off Opsgenie mobile app contact method to make it happen. You’ll no longer get push notifications from the Opsgenie mobile app.

Delete your Opsgenie contact methods

If your Jira admin setup a role-based notification (previously called central notification template in Opsgenie), then your notifications may not get pushed to your Opsgenie mobile app (which is now turned off).

To fix this: Delete your Opsgenie contact method. This will make the Jira Mobile Cloud mobile app your primary contact method in central notification templates.

Select Manage contact methods, then delete any Opsgenie mobile apps you find under Contact methods.

Alerts

All your alerts will now be available in Jira Service Management. To access your alerts, select Your work from Jira Service Management top navigation, and select Alerts. You can also access your alerts from the Alerts widget on the Your work page.

To create an alert manually, you can select Create alert from More actions on the Alerts page.

Turn off Opsgenie permanently

To turn off Opsgenie, you can navigate to Settings > Products > Move from Opsgenie and select the Turn off Opsgenie button.

Once you turn off Opsgenie:

• Opsgenie web and mobile apps won’t be accessible to anyone

• You’ll be able to use operations only in Jira Service Management

This action doesn’t affect or change your billing. Before you confirm, be sure to check all actions in the guide for any open tasks, pending data, or settings that you haven’t moved to Jira Service Management, as any of your unmoved data will be lost.

Automation

Recreate Opsgenie alert actions and incident rules

Your Opsgenie actions and incident rules aren’t automatically moved to Jira Service Management. You can easily recreate them using Jira Automation’s vast library of rule templates and components.

To get started:

1. Go to Settings > System > Global automation > Create rule. For team scope, Go to a team > Operations > Automation > Create rule.

2. Select a trigger that you wish to use. Triggers are the events that set off a rule. Use any of the alert triggers or Issue created trigger with issue type as [system] incident to recreate your Opsgenie action or incident rule.

3. Select a condition if you wish to have it in the rule. Conditions filter the events and only proceed to the next component if the event matches the condition. [issue created with issue type being incident as condition]

4. Select an action. You’ll find all the available actions in the list. For example, Create incident, AWS SSM, AWS SNS, Azure, Jira Edge Connector etc.

You’ve now created an automation rule. This way, you can recreate all your alert actions and incident rules.

Read more about Jira automation actions.

Delete your Opsgenie actions and incident rules

To avoid conflict between Opsgenie and Jira, delete your team's Opsgenie actions and incident rules in Opsgenie. It’s recommended to do this after setting up your automation in Jira. In your Opsgenie team, select Actions and Incident rules and delete all the action channels, actions, and incident rules permanently.

Incident management

We’ll copy your Opsgenie incidents, linked alerts, and relevant data like PIRs to a new service project named ‘Opsgenie Migrated Incidents’ in Jira Service Management. Once it’s complete, you’ll be able to manage your incidents directly in Jira Service Management.

Unavailable fields in Jira Service Management

These incident fields aren’t copied from Opsgenie to Jira Service Management:

• Actions

• Responder roles

• Stakeholder filters

• Stakeholder templates

Copy new Opsgenie incidents to Jira Service Management

Because we’ve already copied your existing Opsgenie incidents and PIRs (Post-incident reviews) to Jira Service Management, it’s recommended that you create and manage your new incidents and PIRs directly in Jira Service Management from now on, as it’s easier and more efficient.

The new incidents and PIRs in Opsgenie won’t be synced automatically to Jira Service Management. If you create new incidents and PIRs in Opsgenie, you’ll be able to copy them once more before moving to Jira Service Management permanently.

Deprecated features and API changes

Opsgenie APIs will continue to work even while you move to Jira Service Management. However, once you complete your move, we recommend that you start using the Jira Service Management Ops REST API.

The Team API in Opsgenie will continue to work as of October 1, 2024 only for teams that were already configured in Opsgenie and are moved to Jira Service Management. However, we recommend that you start using Team API for Jira Service Management going forward.

Several reports in Opsgenie, such as API Usage Analytics, API Usage Analytics by Time, and API Rate Limit, have been deprecated. The associated features work differently in Jira Service Management, making these reports redundant. Reports such as Past ICC Session and DevOps Metric Report are no longer supported. The features associated with such reports have been deprecated in Opsgenie and hence not transitioned to Jira Service Management.

For some reports however, we have the following alternative solutions available:

• Post Incident Analysis Report and Postmortem Report
  The functionality for these reports is already available in Jira Service Management. You can access reporting data using Atlassian Analytics.

• Service Health Report
  You can analyze service health metrics through the Infrastructure Health Report.

• User Management Report
  You can use Identity for any analysis related to user status.

Heartbeats

As we move your heartbeats from Opsgenie to Jira Service Management, the heartbeat email address, which we use to send pings to your systems, is also being switched from Opsgenie (opsgenie.net) to the new Atlassian servers (atlassian.net). Although this change won’t affect your existing heartbeats, if there are scripts you’re using with heartbeat names with the opsgenie.net servers, we recommend updating the name of the heartbeats with the new atlassian.net address in your scripts.

Heartbeats with no assigned team (known as global heartbeats) won’t be moved to Jira Service Management as global heartbeats are not yet supported. Make sure to assign a team to your global heartbeats if you wish to move them to Jira Service Management before starting the move.