On January 16th, 2025, the Atlassian Community Events (ACE) chapter known as ITSM/ESM Masters — an online/virtual ACE affiliated with a topic, not a city — brought together a panel of experts to discuss the ongoing merge of two Atlassian products, Jira Service Management (aka JSM) and Opsgenie (OG).
The panel was comprised of people with three different perspectives. The Atlassian perspective, an Atlassian Solution Partner perspective, and an Atlassian customer perspective:
The Atlassian Community Leaders and hosts for this panel, yours truly and Jóvin Jóvinsson, started the meeting by asking the panelists questions they had prepared for the event. Next, we took questions from the 170-member audience.
Here's a summary of most of the questions and their answers. I say most because we encountered a technical glitch with Zoom and compounded it with user error. As a result, we failed to capture a recording or transcript of this event successfully.
So, Jóvin and I prepared this from memory (with help from our panelists).
Why did Atlassian move Opsgenie features into Jira Service Management?
In 2018, when Atlassian acquired Opsgenie, the plan was always to make on-call schedules, alerts, etc, available within Jira Service Management so that Jira Service Management customers could access a complete ITSM solution without context switching. The first step of that was to make incident management features available from the Jira Service Management UI. As of today, we've enhanced that experience, removed clicks to make it more efficient, and started to build some of the Opsgenie features (like incident rules) using automation. This opens up the incident management experience to a lot more power in the future.
How do customers know how much time they have to move? And what if I need more time?
You will find your personalized timeline within your account management menu — provided you have access rights.
Go to Settings>Operations>Move from Opsgenie; it will have a purple "new" tag next to it. Once you click it, your timeline will appear. Each customer's timeline is unique.
If you need more time, please get in touch with the Atlassian JSM support team so they can evaluate your case.
Can you walk us through the steps of what happens with the move?
First, you'll see your move dates from Settings > Products > Move from Opsgenie. Once you click "get started," the wizard will walk you through the process step-by-step.
Most of your data will be moved over via the wizard, but some will need to be moved manually. The wizard will highlight and explain before you do anything.
Once everything has been moved and one of your account administrators confirms this is the case, you may turn off Opsgenie.
Eventually, according to your individual timeline, Opsgenie will be read-only. Before this happens, you will need to ensure all of your users have switched from the Opsgenie mobile app to the Jira mobile app.
Finally, Opsgenie will be turned off for good, again according to that individual date in Settings.
How much downtime will customers experience?
Once you initiate the merge, you will not experience any downtime. Honest!
The wizard will walk you through everything step-by-step, and it will let you know which actions you'll have to take manually if you're using anything that's been deprecated. If any discrepancies need your attention, it will let you know that, too. For example, there is a difference between Opsgenie and Jira Service Management user roles.
The wizard will guide you through the whole process.
Additionally, before you start the merge, you can contact the JSM support team to get the new experience in your sandbox for testing.
Will we have to update our API calls to a new endpoint?
Your Opsgenie API endpoints will continue to work for now, but we highly recommend using the new JSM Ops API since you'll need to change over to the JSM Ops API eventually.
Opsgenie integrations will continue to work other than the ones that are deprecated. You can refer to this document for details.
For folks who have fully merged, what has their experience been like?
This is anecdotal and may sound gratuitous, but I've spoken to a few community leaders who have completed the merge, including transitioning their teams from the Opsgenie mobile app to the Jira mobile app. In each case, they were happy with the process.
What is your plan to address the upcoming changes at Brown University?
We have converted our sandbox environment fully to the new UI and we are developing the API changes we need, including; schedules, team members, team member roles, default integrations/escalations, custom user roles, manager roles to user assignment, services, and service responders, The API will maintain state between JSM/OG services based on the brown application portfolio (asset) and JSM service object.
We adjusted our timeline to start synchronization on July 1st, 2025, to thoroughly test the APIs in the sandbox before the synchronization. We don't anticipate problems during the synchronization, but I prefer to have the in-house-built tools ready in case of problems.
In addition, we've started developing a communication plan to inform responders about the new UI, with an emphasis on the phone app experience.
We are eagerly awaiting SCIM functionality for Teams provisioning. This may eliminate my need to maintain team membership with the API.
How long have you been using Opsgenie and JSM?
In 2019, we implemented commercial Opsgenie as part of an initiative to move to a lights-out data center. It was a lot of work, but there was a huge payoff.
We standardized our Criticalities/ Priorities and implemented monitoring integrations to alert teams when high-priority systems were offline.
Since then, we have migrated our entire environment to Jira Service Management and Opsgenie as a cost-savings effort, and we have grown our use of Opsgenie into a full-fledged incident management system.
It has been a critical component of our business during major events.
Did you use another service management platform before JSM and/or Opsgenie?
Yes. In 2020 we moved from Remedy (for Change Management and Data Center Requests) to Jira Service Management. Remedy was an onsite deployment and needed a lot of care and feeding. Since moving to JSM in the cloud, we have implemented service management (Incident, Change Management, CMDB using Asset) and many features with automation.
Some Trundl customers use the Opsgenie mobile app — will they be able to continue using it after the merge?
As Kate mentioned earlier, no. The features of the Opsgenie mobile app have been migrated to the Jira mobile app. You'll want to uninstall the Opsgenie app following the merge to avoid duplicate push notifications.
What impacts have you seen for customers who use Opsgenie but not Jira Service Management?
While customers are encouraged to leverage the complete feature set of the combined OG + JSM platform, for now, at least, it is still possible to license Opsgenie standalone (as long as you don't have JSM). I recommend working with an Atlassian Partner for this type of arrangement.
Are there any Opsgenie integrations being deprecated as part of this merge?
Yes, a handful of outdated integrations are being deprecated — a complete list can be found on the Atlassian support site.
These include ZyrionEmail, FirebaseCrashlytics, and Pagerduty. Integrations with these legacy tools can still be established through the Opsgenie API if necessary.
(directed to Kate from Atlassian) Is there a "by when" deadline customers need to be aware of?
Yes. But as I mentioned, it varies by customer. Customers can find their timeline via Settings > Products > Move from Opsgenie. But remember, you can ask for an extension via the JSM support team.
(directed to David from Trundl) Given that Opsgenie is a critical application teams rely on as their eyes and ears when they're not available, how do you think Atlassian could improve transparency around the merge?
I feel an unintended side-effect of every customer having their own customer-specific timeline is that it created the appearance that there was no timeline. In my opinion, Atlassian could have done a better job of making this clear.
(directed to Kate) How does licensing work post-merge?
Once your Opsgenie has been disabled after completing the merge users will only need to pay for a JSM license, and not both.
(directed to David) If my organization currently has services emailing Jira when an issue arises, how should we transition this to the merged product?
Don't look to simply point the email notifications at new JSM. Instead, if your service can make use of APIs, look to configure an effective trigger that can hit the JSM Ops endpoint.
This way you can optimize your alert payload and make full use of the power of the Jira platform - custom fields and other aspects instead of just a Summary and Body.
(directed to Kate from Atlassian) Is there any Atlassian-authored reading material on this topic we should know about?
For sure! I suggest the following:
- Detailed guide: Merge Opsgenie with Jira Service Management
- Guide for moving data: Start shifting from Opsgenie to Jira Service Management
- How To: Migrating Opsgenie to JSM
- Finally, as I mentioned above, if you need to, you can contact the JSM support team for assistance
One final note: Jóvin and I are certain there were questions that we failed to remember. If you attended the event and your questions are not included here, please drop them in the comments below. We'll ask our panelists to provide us with an answer so we can add your question (and the answer) to the article.
Dave Rosenlund _Trundl_
Global Director, Products @Trundl
Boston
201 accepted answers
5 comments