Get started with Jira Service Management for admins
Your first stop for learning how to get started with Jira Service Management.
Who is this for?
This article is for Opsgenie customers who have already merged their Opsgenie account with Jira Service Management and are ready to complete their move and set up operations within Jira Service Management. If you’re a standalone Opsgenie customer looking to merge with Jira Service Management to move your configurations, read more about merging Opsgenie with Jira Service Management.
After merging, you’ll still need to complete your move to Jira Service Management to set up operations and use alerting features in Jira Service Management as a native experience. If you haven’t already, read how to start moving from Opsgenie to Jira Service Management.
Merging Opsgenie and moving to Jira Service Management won’t interrupt your ongoing processes—you will continue receiving alerts in both Jira Service Management and Opsgenie. These systems will remain in sync until Opsgenie is permanently turned off.
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
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.
This happens if they are an admin in Opsgenie but aren’t a product admin in Jira Service Management.
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.
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.
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.
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.
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.
We can change your data residency only before your Opsgenie data is synced with your Jira Service Management instance.
Read more about data residency.
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 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
Soasta
Dynatrace AppMon
Crashlytics
Loom
Monitis
Pingdom Server Monitor
Pingometer
Rigor
Runscope
SaltStack
Statusy
Threat Stack
Thundra
Trace by RisingStack
UptimeProject
Stackdriver
OEC
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
Integration | Available for integration in Jira Service Management |
---|---|
AppSignal | Yes |
ConnectWise | Yes |
ConnectWiseManage | Yes |
Grafana | Yes |
MonitisEmail | Yes |
MSTeams | Yes |
Nagios | Yes |
NagiosXI | Yes |
NewRelicSyntheticsEmail | Yes |
OEMEmail | Yes |
Observium | Yes |
PagerDuty Integration API | No |
PingdomWebhook | Yes |
PingdomEmail | No email integration. There is one more integration type for pingdom. |
UptimeRobotEmail | Yes |
ServiceNow | Yes |
ServiceNowV2 | Yes |
Slack | Yes |
Zendesk | Yes |
ZyrionEmail | No |
FirebaseCrashlytics | No |
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 and video tools in Jira Service Management can be managed in Settings > Products > Chat and video tools. Connecting your chat tools with Jira Service Management helps your on-call team stay notified of alerts, manage them, and take action on them—directly from Slack and Microsoft Teams.
Your chat integrations aren't automatically moved to Jira Service Management because your chat tools are connected with Opsgenie.
What you need to do:
Connect your chat tools with Jira Service Management
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.
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.
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.
The integration will be copied without any changes, but the status will be OFF by default. Make any changes to the integration’s settings and then turn it on manually so it’s operational.
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.
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.
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.
Make sure your Jira Cloud mobile app is up-to-date and that you allow it to send you push notifications in your mobile settings.
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.
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.
While you’re on the contact methods page, make sure to check and update any missing contact methods so that you receive all the alert notifications that are configured to reach you.
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.
What happens to Opsgenie alerts?
While it’s possible for you to work on your alerts on Opsgenie, it will support only critical actions. All of your alert-related data from Opsgenie are now natively available on Jira Service Management, so you’ll no longer have to switch to Opsgenie.
Once Opsgenie is turned off, it can’t be recovered. Hence, turn it off only after you’re sure you’ve moved all your Opsgenie data and settings to Jira Service Management.
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.
You must be a Jira admin or a team admin to set automation rules.
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:
Go to Settings > System > Global automation > Create rule. For team scope, Go to a team > Operations > Automation > Create rule.
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.
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]
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.
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.
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.
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 permanenetly.
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 no longer work.
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.
Was this helpful?