Migrate from Opsgenie to GoAlert

Migrate from Opsgenie to GoAlert: what the move involves

A team facing Opsgenie's end of support in April 2027 needs a self-hosted on-call path that can take over paging before the service stops. Moving to GoAlert is a rebuild, not a file import: schedules, rotations, escalation policies, services and alert sources are recreated in GoAlert by hand, and the effort depends on how complex the schedules are, how many integrations feed Opsgenie, and which notification channels each team relies on. The operations or platform team usually owns the work, often with an implementation partner for the PostgreSQL hosting, identity login, Twilio setup and alert source re-pointing. The main risk is a paging gap, where an alert source still points at Opsgenie or a responder's notification rule was never recreated. The data exports are the first deadline to plan around, because Opsgenie deletes unmigrated data on April 5, 2027, so the schedule and timeline pulls must finish well before that date.

Start by inventorying every Opsgenie team, schedule, escalation policy and integration, and record which ones are actively paging. Confirm with your Opsgenie administrator whether the export described in Atlassian's documentation covers every object you need, and keep copies of the exported schedule files and timeline data in your own controlled storage. Then map each escalation policy to a GoAlert escalation policy and each rotation to a GoAlert rotation, and decide who owns each service. Plan a parallel run in which the same test alerts reach both systems, and check that SMS, voice, Slack and email notifications arrive for every responder. Confirm the Twilio account, sender details and notification rules with your telecom contact before cutover, since GoAlert's current voice and SMS provider support is Twilio only.

Cutover should be a planned change with a written rollback path. Keep Opsgenie active until every alert source has been re-pointed and at least one full on-call rotation has been tested in GoAlert, and set a named owner for the go-live decision. Record the GoAlert configuration, the data encryption key handling and the PostgreSQL backup and restore process as part of the change, because these are the parts an auditor or a future administrator will ask about first. If you run more than one GoAlert instance, decide early how the API-only instances will be deployed, since the getting started guide describes that pattern. Build the timeline backward from April 5, 2027, and treat any integration you cannot re-point in time as a blocker to escalate immediately rather than a detail to fix later.

Which Opsgenie capabilities map cleanly to GoAlert

This table maps each Opsgenie capability in scope to its GoAlert counterpart and marks it as clean, needs rework or gap. Read the status column first, then the notes, to decide which configuration can be rebuilt directly and which needs a workaround or confirmation before cutover.

Capability	Opsgenie to GoAlert status	Notes for the migration
Schedules and rotations	Clean	GoAlert supports rotations and schedules, plus calendar subscriptions. Rebuild them from the exported iCalendar files and confirm handover times match.
Escalation policies	Clean	GoAlert provides automated escalations. Re-create each policy step by step and check the timeout and repeat settings against Opsgenie.
Services	Needs rework	GoAlert lists services as a core object, but routing and grouping may be structured differently. Map each Opsgenie team and integration to a GoAlert service before building.
Timelines and historical on-call data	Needs rework	Timelines are exported through the Opsgenie Schedule API. GoAlert does not import them, so historical records must be archived separately.
SMS and voice notifications	Needs rework	Twilio is the only supported provider for GoAlert SMS and voice. Any other Opsgenie carrier or notification route needs a Twilio account and a new setup.
Slack notifications	Clean	GoAlert can notify a Slack channel as an escalation policy step. Test channel permissions and the bot setup in a staging instance.
Email alert creation	Needs rework	GoAlert creates alerts from email through Mailgun or a built-in SMTP ingress. Confirm mail routing and DNS changes with the mail team before cutover.
Login and access	Needs rework	GoAlert supports GitHub OAuth and any OpenID Connect provider, with Dex suggested for other identity systems. Confirm your SSO setup and user mapping.
Alert sources: generic API, email, Grafana, Prometheus, Site24x7, Sensu	Needs rework	GoAlert documents generic API, email, Grafana, Prometheus, Site24x7 and Sensu sources. Confirm each source's payload format and re-point it to the GoAlert endpoint.
Other Opsgenie integrations	Gap to confirm	No GoAlert source is documented for these integrations. Inventory every integration in Opsgenie and confirm a GoAlert path with the GoAlert project or through a generic API bridge.

What data to export from Opsgenie and what to rebuild

Opsgenie data splits into two groups: records you can export and carry forward as files, and configuration you re-create by hand in GoAlert. Work through both groups before the April 5, 2027 shutdown, when undeleted data is removed. Each card below covers one item in that inventory.

Schedules as iCalendar files

Opsgenie schedules can be exported as iCalendar files, which give you a dated record of who was on call and when. Use these files as the reference for rebuilding each rotation in GoAlert, and keep a copy outside Atlassian's systems. Check each exported file against the rotation handoff times your team actually used, since time zone and override entries are where manual rebuilds most often drift. GoAlert also supports calendar subscriptions, so confirm that the schedule view your responders use matches what you rebuilt.

Timelines through the Schedule API

Opsgenie timelines show how a schedule resolves across overrides and layers, and they are available through the Schedule API. Pull timeline data for each schedule to capture the effective on-call person for each window, not just the base rotation. Store the raw responses in a restricted location, because they contain staff names and contact details. Use them to verify the rebuilt GoAlert schedules for at least one full rotation cycle before cutover.

US and EU API hosts with GenieKey

Opsgenie API calls go to a host that depends on the account region, either the US or the EU endpoint, and authenticate with a GenieKey. Confirm which region your account uses before scripting any export, because a call to the wrong host will fail or return nothing. Create keys with the minimum access needed for reading, and revoke them once the export is complete. Record the key owner and the revocation date in your migration log.

Teams, users and escalation policies

Escalation policies, teams, users and integrations are not carried over as a single file. You re-create them in GoAlert using the exported schedule and timeline records together with Opsgenie's configuration, which you review in the admin console. Map each Opsgenie escalation step to a GoAlert escalation policy step, and note any step that notifies a Slack channel or an email address, since those become separate targets in GoAlert. Confirm each user's contact method and time zone with the person, not from the old export.

Alert sources and integrations

GoAlert documents a generic API, email, Grafana, Prometheus, Site24x7 and Sensu as alert sources. Inventory every Opsgenie integration that creates alerts, then match each one to a documented GoAlert source or a generic API call. Repoint the sources one at a time, and send a test alert through each before you disconnect the Opsgenie side. Integrations without a documented match need a custom build, so scope them before cutover.

Database and self-hosting prerequisites

GoAlert's only hard requirement is a PostgreSQL database. The getting started guide recommends PostgreSQL 17 or newer for new installations and requires the pgcrypto extension, so check both before you provision the database. Set a data encryption key the same way on every instance, because it protects sensitive values such as API keys. Confirm your backup and restore plan for this database, since it holds your on-call history after the Opsgenie export ends.

Data Center download option

Atlassian describes a download option for Opsgenie data that applies only to Data Center customers. If your organization runs Opsgenie as a cloud service, which is the usual case, that option does not apply to you, and you will rely on the API export described above. Confirm your deployment type with Atlassian's account team or your admin before planning the export. If the answer is cloud, budget your time for scripting the API pulls instead of waiting on a file download.

The migration sequence from inventory to decommission

This sequence moves on-call coverage from Opsgenie to a self-hosted GoAlert instance in controlled stages, so every schedule, escalation path and alert source is proven in GoAlert before Opsgenie is switched off. Each step ends with a named artifact that the next step depends on.

Inventory services, schedules and integrations
The operations lead and the team leads who own each service list every Opsgenie service, team, schedule, rotation, escalation policy and integration, including the alert sources that feed each one (generic API, email, Grafana, Prometheus or other tools). Pull the schedule and timeline data through the Opsgenie API before anything is changed, so the export is complete. Done means you have an integration inventory that maps each alert source to its service, its escalation policy and its responders, and a confirmed list of owners who will sign off on the new setup.
Pilot GoAlert on PostgreSQL with encryption configured
The platform team deploys a pilot GoAlert instance against a PostgreSQL database. GoAlert's getting started guide lists PostgreSQL 17 or newer as the recommended version for new installations and requires the pgcrypto extension. Set a data encryption key so API keys and other sensitive values are encrypted before they reach the database, and use that same key on every instance if you run more than one. Confirm login through your identity provider (GitHub OAuth or an OpenID Connect provider, with Dex as a bridge where needed). Done means the pilot starts cleanly, a test user can sign in, and the encryption key is recorded in your secrets store.
Recreate rotations, schedules and escalation policies
Using the inventory from the first step, the on-call administrator rebuilds services, escalation policies, rotations and schedules in GoAlert, then checks them against the exported Opsgenie timelines. Where a schedule came from an iCalendar file, confirm that the GoAlert version matches the expected handovers, overrides and time zones. Set up calendar subscriptions if responders need them in their own calendars. Done means each Opsgenie schedule has a GoAlert counterpart, and the team leads have reviewed a printed or exported view of who is on call for the next several rotations.
Run both systems in parallel
Point a copy of each alert source at GoAlert while Opsgenie remains the primary paging path. Where your monitoring stack can send to more than one destination, such as Prometheus Alertmanager or Grafana contact points, add GoAlert as a second receiver. Alerts that arrive in both systems show whether GoAlert paged the right person, at the right time, through the right channel. Compare acknowledgment and escalation records from each side after a set of real incidents and drills. Done means the team has a written list of any mismatches in routing, timing or responder, and each one is closed or accepted by the service owner.
Test notifications and cut over alert sources
Test every notification path an escalation policy depends on: SMS and voice through Twilio (the only supported provider for these channels in the getting started guide), Slack channel steps, and email alerts through Mailgun or the built-in SMTP ingress, as applicable. Run a scheduled test page for each team and confirm each responder receives it, acknowledges it and triggers the next escalation step. Then switch each alert source's destination from Opsgenie to GoAlert, one service at a time, and keep the Opsgenie integration disabled rather than deleted until cutover is signed off. Done means every escalation path has a documented test result and the owners have approved the cutover for each service.
Confirm the export and decommission Opsgenie
Before removing anything, confirm that every schedule, timeline, escalation policy and integration definition has been exported and stored in your retention location, and that the export files open and match the inventory. Check that no alert source still points at Opsgenie and that no team relies on its mobile app for paging. Only then disable the remaining Opsgenie integrations and retire the account. Note that Opsgenie's shutdown date is April 5, 2027, and unmigrated data is deleted after that point, so the export confirmation should be complete well before that date. Done means a signed record shows the inventory is closed, the export is archived and the Opsgenie account is no longer in the paging path.

How to run Opsgenie and GoAlert in parallel and cut over safely

Run both systems at the same time, but move one alert source at a time. Start with the sources that are easiest to redirect and easiest to observe: a generic API integration from a test service, and an email alert path. Create a matching GoAlert service for each, with the same escalation policy members and rotation coverage that Opsgenie uses for that service. For Prometheus or Grafana, add a second receiver or contact point pointing at GoAlert while the existing Opsgenie receiver stays in place, so each alert reaches both systems. Mark the GoAlert copy as informational until its notifications have been verified. For email sources, confirm the Mailgun or built-in SMTP ingress setup in the GoAlert getting started guide before changing any routing address. Confirm which alert sources GoAlert supports today, because the documented list is shorter than Opsgenie's integration catalog.

Test every escalation policy end to end before it carries live traffic. Use real Twilio SMS and voice notifications to real test devices, since Twilio is currently the only supported provider for voice and SMS in GoAlert. Check each step in order: the first responder, the timed escalation to the next responder, the Slack channel step, and the email path. Record the delivery time and whether the acknowledgement stops escalation. Plan the GoAlert deployment with a single default engine instance and the remaining instances started with the --api-only flag, as the getting started guide recommends for multiple instances such as in a Kubernetes cluster. Confirm the data encryption key is identical on every instance, because it protects API keys stored in the database. Test a database switchover while alerts are flowing, since the guide describes it as minimally disruptive.

Decide the cutover with a checklist owned by a named on-call lead, who signs off each source before it moves. The checklist should confirm that every escalation policy has passed a live SMS, voice, Slack and email test, that schedules and overrides match the exported Opsgenie data, that the GoAlert database has backups and a tested restore, and that login through the chosen identity method works for every responder. Name a rollback step for each source: re-enable the Opsgenie route and disable the GoAlert route, with the owner and the time recorded. Keep Opsgenie receiving alerts for at least one full on-call rotation after the last source moves, and confirm the Opsgenie shutdown date with Atlassian before setting the final decommission date.

What drives the cost and duration of an Opsgenie migration

This table compares the cost components and effort drivers in an Opsgenie to GoAlert rebuild, showing who is paid for each part and what is one-time or recurring. Read each row as a lever: the first column names the driver, and the other columns explain why it moves effort and how to keep it down. The main takeaway is that schedule and escalation count, notification types and evidence needs usually matter more than the software itself.

Driver	Why it moves cost or effort	How to keep it down
Number of schedules and rotations	Each rotation, override and escalation policy is rebuilt by hand in GoAlert, so effort grows with every team and layer of escalation.	Inventory schedules before starting, retire unused ones and consolidate teams with identical rotations.
Alert integrations and sources	Each integration must be re-pointed to GoAlert's generic API, email, Grafana, Prometheus, Site24x7 or Sensu source, and each one needs its own test.	Group sources by type, migrate the highest-volume ones first and remove integrations no longer sending alerts.
Notification types	SMS and voice depend on Twilio, which is currently the only supported provider, so each channel needs provider setup, numbers and test calls.	Limit the first cutover to channels people actually use, and confirm Twilio pricing and number costs directly with Twilio.
PostgreSQL hosting and high availability	GoAlert needs PostgreSQL 17 or newer with pgcrypto, and multiple instances need a switchover plan, so this is recurring infrastructure plus setup and failover testing.	Confirm whether your platform team already runs managed PostgreSQL, and ask for backup and failover tests to be scoped in writing.
Identity bridge	GitHub OAuth or any OpenID Connect provider must be wired in, and Dex may be needed to bridge other identity systems, which adds configuration and access review.	Use an existing OpenID Connect provider where possible and document role mapping once rather than per user.
Data encryption key management	GoAlert recommends one encryption key shared by every instance for sensitive values such as API keys, so key storage and rotation need an owner.	Store the key in your existing secrets process and agree the rotation procedure before cutover.
Testing time	Each escalation path, notification and integration needs a verified test, and missed test coverage is the most common cause of paging gaps after cutover.	Write test cases from the schedule inventory and run them in a staging instance before the Opsgenie shutdown date.
Regulatory evidence needs	Auditors may ask for records of who was on call, escalation settings and change approvals, so the migration must preserve exported timelines and sign-off records.	Agree the evidence list with your auditor early and keep exported Opsgenie data under your own retention rules.

What usually goes wrong when moving off Opsgenie

Most failed Opsgenie-to-GoAlert cutovers trace back to a short list of gaps: data that was never exported, policies rebuilt by hand, paths that were never exercised, and configuration that drifts between instances. Each card below names one of these failures, how to prevent it, and what to check before the decommission gate closes.

Exports finished after the deadline

Opsgenie removes undeleted data on April 5, 2027, so an export that is only half complete on that date is lost. Pull schedules, timelines and escalation data through the Schedule API early, using the US or EU API host that matches the account, and store the output as versioned files. Keep a checklist that maps every Opsgenie schedule, team and escalation policy to an exported file and a GoAlert object, and treat any unmapped item as blocking.

Escalation policies rebuilt in the wrong order

When teams re-create escalation steps by hand, they often swap the order of levels or copy a timeout from memory. A responder then gets paged too late, or the same person is paged twice in a row. Rebuild each policy from the exported definition, record the step order and timeout for every level, and walk through one simulated incident per policy with the on-call owner before any live rotation is switched over.

SMS and voice paths never tested

GoAlert uses Twilio as the only supported provider for voice and SMS notifications, so the paging path depends on a Twilio account, sender numbers and phone numbers being configured correctly. Teams often test the web interface and assume phones will ring. Send a test page to every responder on every contact method, confirm delivery and acknowledgment, and repeat the test after any change to the Twilio account or phone number records.

Encryption key differs between instances

GoAlert encrypts sensitive values such as API keys before they are written to the database, and it recommends using the same encryption key on every instance. In a clustered deployment, an instance started with a different key can fail to read secrets written by its peers, which causes intermittent notification failures that are hard to trace. Store the key in your secrets manager, inject the identical value into every pod or host, and verify each instance reads a known test secret after deployment.

Alert sources still pointing at Opsgenie

Monitoring tools, Prometheus Alertmanager routes, Grafana contact points and email forwarding rules often keep sending alerts to the old Opsgenie integration after the new on-call schedule is live. Those alerts then reach no one once Opsgenie shuts down. Inventory every integration before cutover, re-point each one to a GoAlert alert source such as the generic API, Grafana, Prometheus or email, and keep the Opsgenie integrations disabled but not deleted until a decommission gate confirms zero traffic.

PostgreSQL without pgcrypto

GoAlert's only hard requirement is PostgreSQL, and the getting started guide asks for PostgreSQL 17 or newer on new installations with the pgcrypto extension enabled. A database that starts without pgcrypto can fail during setup or first use, and managed database services sometimes restrict extension installation. Confirm the server version and extension availability with your database team before the install, and include the extension check in the same runbook step as the database creation.

How the migration differs by team size and starting point

A small team with one or two schedules usually has a short list of services, a single escalation path and a handful of people in rotation. The export and rebuild work is mostly manual and can be verified by one person who knows the on-call history. The main risk is not volume but missing a notification path that only one engineer ever used.

Schedules and rotations: Confirm each rotation, handoff time and override in Opsgenie, then rebuild it once in GoAlert and compare the next several shifts.
Notification methods: Check which users receive SMS, voice, push or email, and confirm that Twilio is set up for the voice and SMS steps you need.
Alert sources: List every integration that sends alerts to Opsgenie and re-point each one, since a small team often forgets a cron job or a single vendor webhook.
Hosting footprint: A single GoAlert instance backed by PostgreSQL is the simplest deployment, so confirm who will patch and back up the database.
Test cadence: Run a test page to each responder and an escalation test before cutover.

Before starting, ask your team to list every person who has ever been paged in the last year, because that list is the easiest way to find an integration nobody documented.

Questions teams ask before moving from Opsgenie to GoAlert

How much effort does moving from Opsgenie to GoAlert take?

The effort depends mostly on how many schedules, escalation policies, services and alert integrations you have, and how many of those integrations need new endpoints. A team with a few rotations and one or two alert sources is working on a very different job from a team with dozens of services, overrides and custom integrations. Start by counting those objects in Opsgenie and mapping each one to a GoAlert service, rotation, schedule or escalation policy. Add the work to stand up PostgreSQL, set the data encryption key, configure Twilio for SMS and voice, and test every notification path. Ask any implementation partner to price the work against a written inventory, not a general estimate.

How long does a migration to GoAlert take before April 5, 2027?

The timeline is set by your inventory, your testing window and your change freeze dates, not by a fixed duration. Opsgenie shuts down on April 5, 2027, and unmigrated data is deleted, so the export and any archive work must finish before that date with room to spare. Work backward from the deadline: export data first, rebuild schedules and escalation policies second, re-point alert sources third, then run parallel notifications and test escalations before cutover. Confirm the exact shutdown and deletion dates in Atlassian's own notices, since those are the dates that control your plan.

What does the migration require from the on-call team?

The on-call team has to validate the rebuilt rotations, since only people who take pages know whether a schedule matches how they actually work. Engineers should confirm contact methods, time zones, override patterns and escalation delays, and they should take part in test pages during a parallel run. Expect several short review sessions rather than one large one. Someone also needs to own the decision on cutover, so that a missed page is traced to a named step rather than to the tool. Confirm your team's availability for test windows before you set dates.

Can an internal team migrate from Opsgenie to GoAlert without outside help?

An internal team with Linux, PostgreSQL and on-call operations experience can do the migration, provided it has time to build, test and document the new paging path. The harder parts are usually not the installation but the inventory, the alert source re-pointing and the notification testing across SMS, voice, Slack and email. Teams without a spare engineer for several weeks often bring in outside help for scoped pieces, such as the export, the high-availability setup or the test plan. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own environment under a written scope, and it can cover any of those pieces. Ask for a written scope before deciding.

What does running GoAlert cost compared with Opsgenie?

GoAlert is Apache 2.0 licensed, so the software itself carries no license fee. The recurring costs are the infrastructure and staff that run it: PostgreSQL hosting, the servers or containers for GoAlert instances, and Twilio usage for SMS and voice notifications, which Twilio bills to your account. Staff time covers upgrades, backups, monitoring of the paging system itself and on-call for the platform. Twilio is currently the only supported provider for voice and SMS, so ask for a quote that prices message volume at your expected paging rate. Compare these items against Opsgenie's subscription and any Jira Service Management licensing before deciding.

Does GoAlert cover the full Opsgenie feature set?

GoAlert covers the core on-call work: services, escalation policies, rotations, schedules, calendar subscriptions, and alerts from a generic API, email, Grafana, Prometheus, Site24x7 and Sensu. It also notifies Slack channels as an escalation step and supports SMS and voice through Twilio. Check every Opsgenie integration you rely on against that list, and check any feature your team uses that is not on it, such as specific incident workflows, stakeholder updates or vendor-specific connectors. Where a gap exists, decide whether to build a replacement, change the workflow, or choose a different destination. The sibling comparison of Opsgenie and GoAlert sets out these differences in more detail.

What should be tested before cutting over alert notifications?

Test every notification path that a real page would travel, including each escalation step, each contact method, each time zone and each override. Send test alerts from every re-pointed source, such as the generic API, email, Grafana and Prometheus, and confirm the on-call person receives them through SMS, voice and Slack. Verify acknowledgment and escalation timing, and rehearse a failed-acknowledgment path. Run the old and new systems in parallel long enough to cover a full rotation, and record the results. Ask your team to sign off on the test log before you switch the routing.

How DeployOpen scopes and runs an Opsgenie to GoAlert migration

A written scope comes before any work starts. DeployOpen agrees the list of Opsgenie teams, schedules, escalation policies, integrations and alert sources in scope, the GoAlert deployment target, the deliverables and the acceptance checks in writing. The first phase is inventory and export: pulling schedules, timelines and escalation data through the Opsgenie API for the correct regional host, and confirming the export covers every team that still pages people. Because Opsgenie data is removed after the April 5, 2027 shutdown, the export plan and its owner should be fixed early, and the client should confirm which data its own retention rules require it to keep.

The second phase deploys GoAlert inside the client's own cloud account, data center or air-gapped network. That covers the PostgreSQL database with the pgcrypto extension, the data encryption key shared across every instance, identity login through the client's chosen provider, and the rebuild of services, rotations, schedules and escalation policies from the inventory. Alert sources are re-pointed in the same phase, such as the generic API, email, Prometheus or Grafana sources, with each change recorded so that an alert path is never left without an owner. Notification testing follows as its own gate: SMS and voice through Twilio, Slack steps and email ingress are each exercised against the rebuilt policies, and the client signs off the results before cutover.

Cutover support and decommission evidence close the engagement. DeployOpen supports the switch of live alert traffic, records the results of parallel paging, and produces a decommission record that shows which Opsgenie integrations were disabled and which exports were archived. Ongoing upgrades, backups, hardening and continuous testing are available as retainers after handover. DeployOpen does not publish a price list. A quote follows from the written scope, so the client should ask for the phases, the deliverables and the client-side tasks to be itemized, and should confirm which Twilio and hosting costs remain with the client.

Migrate from Opsgenie to GoAlert