# How PandaDoc replaced Opsgenie and removed years of internally supported code. URL: https://rootly.com/customers/pandadoc Customer: PandaDoc Author: Adam Frank and Sebastian Vietz Published: 2026-10-05 Updated: 2026-10-05 > When Atlassian deprecated Opsgenie, PandaDoc's SRE team evaluated Jira Service Management, found the same constraints, and went to market instead. They chose Rootly over incident.io, rebuilt five years of custom Opsgenie tooling in a few weeks, and are deleting code they had maintained for years. ## Results - **200 hours** of engineering time returned every month - **89%** fewer after-hours pages - **64%** lower MTTR > “I regret not making the decision to switch earlier, instead of waiting until Opsgenie came to an end.” > Uladzimir Karabeinik, Senior Engineering Manager, PandaDoc [PandaDoc](https://www.pandadoc.com/) is a document workflow platform for proposals, quotes, contracts, and e-signature, plus an online notary service in the US, on a mission to deliver transformative technology that simplifies the way companies operate and win. Editor’s note: Atlassian is retiring Opsgenie, with end-of-life scheduled for April 2027—factor a migration path into any evaluation. **Founded:** 2011 in Minsk, Belarus **HQ:** San Francisco **Size:** ~700 employees **Reliability target:** 99.99% on the critical path Atlassian notified PandaDoc that Opsgenie was being deprecated, and PandaDoc should move to Jira Service Management. So they evaluated it and found a similar tool with similar constraints, plus the prospect of rebuilding every integration they had already built. That's when the question changed. Instead of migrating sideways, PandaDoc's SRE team went to market, chose Rootly over incident.io, and rebuilt its entire setup in a few short weeks. The payoff was not a better pager. It was removing the custom Slack agents, hand-built slash commands, and payroll exporters they had maintained for years. ## The notice that changed the question SRE teams are famous for owning too much and constantly context switching, and PandaDoc is no exception. To make Opsgenie work the way PandaDoc needed it to, the team wrote a lot of code: custom Slack agents, slash commands built by hand, and a bespoke exporter to approximate on-call payments so the accounting team could process them. Around five years of accumulated custom development on Opsgenie, and every line of it was theirs to maintain. Then Atlassian deprecated Opsgenie and pointed customers at Jira Service Management. PandaDoc did the responsible thing and evaluated it, then reached an unwelcome conclusion, which Aliaksandr puts in a few words. > "JSM is the same thing with the same shortcomings." **—Aliaksandr Litvin, Site Reliability Engineer** Same tool, same constraints, and a requirement to rebuild integrations they had already built once. If they had to redo the work anyway, the obvious next question was whether they should do it somewhere better. A second frustration was the kind of thing only an on-call engineer notices. Opsgenie had a concept of responder alerts: when your team was attached to an incident, you received the most critical alert, and you had no influence over its priority. That meant being woken for things that didn't warrant it, with no way to express the difference. ## The decision between the two leading platforms: Rootly or incident.io Rootly and incident.io both offer Slack-native incident management with the surrounding tooling PandaDoc wanted, which is roughly what the team had spent years assembling on top of Opsgenie themselves. Aliaksandr built a proof of concept on each platform. Three things settled it. The first was AI, and specifically a scribe that captures an incident as it unfolds rather than reconstructing it afterward. Aliaksandr wanted the record to build itself while his responders stayed on the problem, not just have a transcript after. The second was Terraform. Rootly already had mature modules and a CLI, which matters to a team that manages everything else as code. Aliaksandr's verdict: "far more pleasant than poking at APIs". The third was not technical at all. Both of them raised it without being asked, and both made it clear it counted. Rootly's team felt personal and professional, and they showed expertise throughout the evaluation. Underneath it all was a simpler calculation. Staying in the Atlassian ecosystem meant keeping every piece of custom code they had written, and writing more of it. Moving meant handing that work back to a vendor and getting a better tool in exchange. > "I regret not making the decision to switch earlier." **—Uladzimir Karabeinik, Senior Engineering Manager** ## Five years of custom work, rebuilt in a few short weeks A working setup came together quickly, and the core build was finished inside a month, which is a striking number set against five years of accumulated Opsgenie customization. It was possible because Rootly ships the primitives that experienced teams end up building for themselves: workflows, templating, escalation logic, service-based alerting; opinionated rather than written from scratch. Aliaksandr's team did not have to reinvent their process, only re-express it, and his verdict on the result is that the final setup looks considerably better than the one they had spent years assembling. The remaining time went where it should, on people. PandaDoc implemented Rootly to fit their process like-for-like rather than redesigning in flight, which is the right order of operations for a migration that touches every first responder: reproduce what already works, let the teams settle, then improve. They brought every stakeholder along, including the accounting team that depended on on-call payment data. > "Rootly is easy to use, flexible Lego blocks, and every workflow accelerates the next one." **—Uladzimir Karabeinik, Senior Engineering Manager** ## From maintaining the tool to using it ### Deleting code instead of migrating it As Uladzimir frames it, whatever they rebuild as workflows or find available natively lets them drop their custom repositories and code bases entirely, and with them the obligation to keep someone else's on-call tool working. He is careful to say it is hard to quantify this early, because the team deliberately migrated like-for-like first. The direction, though, is clear: less of their own software to run, and more attention for the reliability work it was distracting from. ### Pages that respect priority The change Aliaksandr singles out is small, specific, and exactly the kind of thing that decides whether engineers trust their pager. Because Rootly attaches alerting to services and respects incident priority, and because deferral policies exist, he can now avoid a category of after-hours pages that Opsgenie's responder alerts fired regardless. For a team running 24/7 weekly rotations, being woken precisely rather than indiscriminately is what keeps a rotation something engineers are glad to be part of. ### One place to see everything Every policy now lives in one place with a history attached. When something triggers, or fails to, the answer is in the workflow history rather than in somebody's reconstruction. Aliaksandr notes this has already proved useful more than once, which is a modest way of describing the end of a common and miserable category of debugging. ### What the rest of the business noticed Two AI capabilities have landed beyond the SRE team. Stakeholders use the @Rootly agent: rather than joining a call to find out where things stand, they ask the agent and get the context themselves, so the people working the problem aren't also fielding questions. And the Scribe agent has made communicating during and after an incident materially easier, a benefit that accrues to everyone who needs to be told what is happening rather than everyone who is fixing it. Separately, the on-call readiness report gave engineering management a view it didn't previously have. > "Everyone absolutely loves the Rootly agent. It has made getting context and communicating a lot easier." **—Aliaksandr Litvin, Site Reliability Engineer** There is a version of this story where a deprecation notice is simply an expense: a forced migration, a rebuilt integration layer, the same constraints on a different invoice. PandaDoc got the opposite, because they treated the notice as a reason to ask what they actually wanted rather than where Atlassian was pointing. In a few short weeks, they had a setup that looks better than the one they spent years customizing, the ability to express which pages are worth waking someone for, and a growing list of their own repositories they no longer need to keep alive. The only part Uladzimir would change is the timing.