How to export your data from Opsgenie before the April 2027 shutdown
Schedules can be exported as iCalendar files, timelines can be pulled through the Schedule API, and the remaining configuration and history need a deliberate export before April 5, 2027, when undeleted data is removed. If your team is working against a renewal or end of support clock, set that date as the deadline for every copy you need, and plan the work backward from it. The export gives you a record to rebuild from. It does not restore your account into a new Opsgenie-compatible system, so you will re-create services, rotations and escalation policies in your destination yourself. Some objects may have no one-click export, so confirm with Atlassian which items its tools cover before you assume a gap is covered.
Start with schedules. Export each one as an iCalendar file so the shift patterns are preserved in a format you can review against the live schedule. GoAlert documents calendar subscriptions, but confirm how far an iCalendar file maps onto its schedules before you rely on it. Timelines need a different path: pull them through the Schedule API, which authenticates with a GenieKey. Before scripting the pull, confirm in Atlassian's current API documentation which host serves your account, since Opsgenie runs separate US and EU hosts, and confirm what scope the key needs. Save each response with its date and schedule name so you can check the files against the source later.
Everything else needs a deliberate pull. Services, users, teams, escalation policies, routing rules, integrations and alert history may not be covered by the two methods above, so list each object type and decide whether it will be exported through the API, copied by hand or left behind. The download option Atlassian describes applies to Data Center customers, so check your deployment type before planning around it. Keep the export in storage you control with access restricted, because it may contain contact details and integration credentials. Then rebuild in GoAlert, which requires PostgreSQL 17 or newer, and test notifications before cutover. The GoAlert documentation covers the objects you will need to recreate.
What you can export from Opsgenie and how
This table lists each Opsgenie data type to pull before the April 5, 2027 shutdown, the method and format it comes out in, and what to confirm before you rely on it. Read the export method column first, because iCalendar files and API calls produce different outputs. The main takeaway is that schedules can be exported in two forms, while everything else depends on API access with GenieKey authentication from the host that matches your account region.
| Data type | Export method | Format | Limits or notes |
|---|---|---|---|
| On-call schedules | iCalendar export of each schedule | iCalendar (.ics) files | Good for shift review; confirm whether overrides and layers appear in the file. |
| Schedule timelines | Schedule API, timeline requests | JSON | Captures computed rotations and overrides; confirm endpoint paths and date range parameters. |
| Teams and users | Teams and users API | JSON | Needed to map responders to GoAlert accounts; confirm which contact methods the response includes. |
| Escalation policies | Escalation policy API | JSON | Use as a reference for rebuilding escalation levels and targets in GoAlert. |
| Services and integrations | Services and integrations API | JSON | Integration keys are secrets; store them securely and use them to re-point alert sources. |
| Alert and incident history | Alert and incident list API | JSON | Confirm pagination and the record retention window early, since older records may be unavailable. |
| Saved configuration such as notification rules | Notification rules API, where exposed | JSON | Confirm which rule types the API returns, and document any settings it does not cover. |
| Authentication and API hosts | GenieKey header against the US or EU API host | HTTPS requests | Choose the host for your account region; confirm exact paths and rate limits in Atlassian's current Opsgenie API documentation. |
What does not export cleanly and how to work around it
A schedule export and an API pull will not carry everything that makes an Opsgenie account work day to day. The items below are the ones teams most often find missing after the first export, and each needs a decision before the April 5, 2027 deadline: record it, rebuild it, or ask Atlassian whether a documented export exists.
Integration keys and API secrets
Each integration on a service carries an API key that alert sources such as monitoring tools use to send alerts. Those keys are not portable, so every sending system must be given a new credential that points at the destination. Build a manual inventory listing each service, integration type, sending system and owner, then reissue the credentials in GoAlert and update each source. Confirm with Atlassian whether integration keys appear in any export before you assume they are lost.
Alert notes and attachments
Notes, comments and attachments added to alerts during past incidents are part of the incident record. Check whether your export covers alert-level detail for the period you need, and decide which closed incidents must be kept. For anything outside that scope, archive the records in your incident system of record rather than trying to rebuild them inside GoAlert, which is an on-call and notification tool.
Custom fields and team settings
Custom alert fields, team-level configuration and role assignments have no direct one-to-one equivalent in GoAlert. List every custom field used by your routing or reporting, then map each one to a GoAlert service, label or escalation step, or drop it with sign-off from the owning team. Team membership should be rebuilt from your identity provider groups so access stays aligned with who is actually on call.
Automation actions and webhook logic
Opsgenie automation actions, routing rules and outbound webhooks encode decisions that people may forget exist. Export or screenshot each rule, note its trigger and effect, and check which downstream systems depend on it. GoAlert handles escalation, notification and alert sources, so each rule must be reproduced as a GoAlert policy step, a source configuration or a receiving script that you test before cutover.
Mobile app and notification preferences
Individual users set their own notification methods, contact numbers, quiet periods and mobile app settings in Opsgenie. These preferences are tied to user accounts rather than to schedules, so they will not move with a schedule export. Ask each responder to confirm their contact methods in GoAlert and test a notification to every number before the first live rotation. Voice and SMS depend on Twilio, so confirm that your sender and country coverage are set up before testing.
The export sequence to finish before the deadline
This sequence moves Opsgenie schedules, timelines, configuration and history into an encrypted, access-controlled archive that is verified item by item. Each step produces a named output and a sign-off, so the archive is complete before Opsgenie data is removed on April 5, 2027.
Inventory the account and name owners
List every team, schedule, rotation, escalation policy, service, integration and user in the Opsgenie account, and name the person who owns each one. Record which teams are on call for which services and which alert sources send alerts to them, because those links are what you will need to rebuild later. Keep the register in a controlled location that only the migration team can edit. The output is a signed inventory register. The Opsgenie account owner and each team lead confirm their entries are complete before you move on.
Create and test a GenieKey on the correct host
Confirm which Opsgenie API host matches your account's data region, US or EU, using Atlassian's documentation or your admin console. A request to the wrong host may not return your data. Create a GenieKey with the narrowest access the export needs, and record its owner and how it will be revoked after the migration. Store the key in your secrets manager, never in a script, ticket or shared document. Test it with one read-only request against a known schedule. The output is a passing test log and a key record, and the platform administrator signs off that the key is scoped to the migration.
Export schedules as iCalendar files
For each schedule in the inventory, export it as an iCalendar file, which records the on-call shifts in a format that calendar tools can open. Name each file with the team, the schedule name and the export date so it can be matched to the register. Open two or three files and compare their shifts with the schedule view in Opsgenie for the same period. The output is one iCalendar file per schedule and a short comparison note. The lead for each schedule signs off that the shifts match.
Pull timelines and escalation data through the Schedule API
An iCalendar file may not capture every override or escalation detail, so use the Schedule API with your GenieKey to pull schedule timelines and the escalation data each team relies on. Save each response as JSON with the schedule ID, the request time and the host used. Check the record count and a sample of overrides against the Opsgenie interface. Log any request that returns an error, and retry it once the cause is known. The output is a JSON set per schedule and an error log. The on-call lead for each team signs off that overrides and handoffs appear correctly.
Export configuration and history
Export the remaining configuration, including services, integrations, users and contact methods, along with alert history. Use the method Atlassian documents for your deployment, and confirm with Atlassian which export options apply to your plan. If you run Data Center, check the download option Atlassian describes for that deployment type before relying on the API alone. Save each export under its inventory ID. The output is a set of configuration and history files with a manifest. The Opsgenie account owner signs off that every register item has an export or a recorded reason for exclusion.
Encrypt and store the archive under access control
Bundle the schedule files, JSON, configuration and history into one archive, and encrypt it before it leaves the export workstation, with the encryption keys held outside the archive. Generate a checksum manifest so the copy can be verified later. Place the archive in a location that only named migration staff can read, with access logged and a retention period set by your compliance lead. Remove working copies from laptops and shared drives. The output is an encrypted archive, its checksums and an access list. The security lead signs off on storage and access.
Verify the export against the inventory
Reconcile the register against the stored archive, item by item. Each schedule, team, service, integration and user should show as exported, excluded with a stated reason, or flagged for manual checking. Restore a copy of the archive to a separate location and confirm the checksums still match. Do not close the export while any item remains open. The output is a signed reconciliation sheet. The Opsgenie account owner and the security lead both sign it, and it becomes the input to the migration plan.
How to verify the export is complete before deleting anything
A successful download does not prove the export is complete. Start by comparing counts: the number of schedules, rotations and escalation policies in your export should match what the Opsgenie admin screens show for the same account. Where they differ, find out why before going further, because a missing escalation policy is far easier to catch now than after deletion. Then open a sample of exported timelines and check shift start and end times against the schedule as Opsgenie displays it, paying particular attention to time zones. A shift that is correct in UTC can still be an hour wrong for a local team. Finally, confirm that user and team references resolve to people you can identify. List every unmatched user, because each one is a future gap in an escalation policy.
Keep a dated record of what was exported, by whom, and from which API host. The record should name each file, its size and a checksum, the date of the run, the person who ran it, and whether the account used the US or EU host. Record the key identifier used for authentication, never the GenieKey itself. Export files contain staff names, contact details and on-call patterns, so store the record and the files in a restricted location with the same access controls you apply to other personnel data. This record is what your auditors, security team and any later investigation will ask for, and it lets someone else repeat the check if the first attempt is questioned.
Use one rebuilt schedule as the acceptance test. Recreate a single schedule in GoAlert from the exported data, then compare who is on call at several sample times against the Opsgenie schedule for the same periods. GoAlert's documentation covers the schedule and calendar subscription features you will rebuild against, so check that subscribed calendars show the same shifts. Then run a test notification through the channel you plan to use, such as Twilio for SMS or voice or a Slack channel, and confirm the right person receives it. Only when the rebuilt schedule and the test notification both pass should anyone approve deletion of the source data.
Export paths for Opsgenie cloud and Data Center customers
For Opsgenie cloud tenants, the export is an API job. Schedules can be pulled as iCalendar files, and timelines can be read through the Schedule API. Requests go to the API host for your tenant's region, either the US host or the EU host, and authenticate with a GenieKey. Because the work is scripted, most of the effort is in writing, running and checking the pull, not in clicking through the interface.
- Choose the host first. Confirm whether your tenant is in the US or EU region, and send every request to that host only.
- Create a scoped GenieKey. Issue a key for the export, record which team owns it, and revoke it once the export is verified.
- Pull schedules as iCalendar. Save each schedule as its own file so rotations can be reviewed in any calendar tool.
- Pull timelines through the Schedule API. Store raw responses with timestamps so override and rotation history can be compared later.
- Test one team end to end. Compare the export for a single week against what on-call engineers saw in Opsgenie.
Before running the full export, confirm the endpoint paths and response fields in Atlassian's current Opsgenie API documentation.
Organizations running Opsgenie in a Data Center deployment should not assume the cloud API path applies to them. Atlassian documents a download option for Data Center customers, and that option determines what can be taken out of the product and in what form. The team needs to confirm which deployment it runs, then confirm what the download contains before scheduling any extraction work.
- Confirm the deployment model. Check the deployment type in your contract and administration console before planning the export.
- Read the download scope. Find out whether it includes schedules, timelines, escalation policies, users, services and alert history.
- Check the file format. Confirm the format and whether it can be loaded into GoAlert, or whether it needs transformation first.
- Identify the access owner. Determine who can run the download, and whether an administrator or Atlassian involvement is required.
- Store a controlled copy. Keep the download in a location you control, with a retention record that names the owner.
If the download does not cover a data type you need, document the gap now so it can be rebuilt manually in GoAlert before cutover.
The two paths differ mainly in where the effort sits. The cloud path puts effort into scripting, key management and validation by your own staff. The Data Center path puts effort into the gap between what the download contains and what GoAlert needs, plus any manual rebuild. Both paths are largely one-time work for the export itself, while GoAlert hosting and the PostgreSQL database recur after cutover.
- Cloud effort drivers: the number of teams, schedules and escalation paths, and how much timeline history you keep.
- Data Center effort drivers: how much data the download leaves out, and how many rotations must be rebuilt by hand.
- Who is paid for what: your internal staff run the export, a partner is paid only if a fixed-scope engagement is agreed in writing, and Atlassian is paid for product licensing until shutdown.
- Items to request in writing from the Atlassian account team: the shutdown and deletion dates, the export methods supported for your deployment, the data types included, the file formats, any API rate limits, and whether Atlassian will confirm deletion in writing.
- Recurring costs to model separately: GoAlert hosting, database operations and Twilio usage for SMS and voice, which follow the cutover and not the export.
Record the written answers in your change record before the export starts, so the migration plan rests on confirmed statements.
What to plan before the Opsgenie contract ends
Exporting Opsgenie data is only one part of leaving. The cards below cover the decisions that have to be made before the final export run, so that exported schedules, timelines and integration details can be used once GoAlert is running. Each item has an owner and a date, and most depend on the others.
Date of the final export run
Set the last export run as a fixed date well ahead of April 5, 2027, the date after which undeleted Opsgenie data is removed. Work backward from that date to the rehearsal export, the GoAlert cutover and the rollback window. Confirm with Atlassian which data sets remain retrievable after the shutdown starts, and record that answer in writing. Treat the final run as a deadline, not a task that can slip into the last week.
Owner of each data set
Assign one named owner to schedules, rotations, escalation policies, timelines, users, and alert routing rules. Owners confirm that an export is complete and that the exported version matches what responders actually use. Without owners, gaps such as overrides or temporary schedule changes tend to surface only during an incident. Record who approves each data set as ready for import.
Storage location and retention for exports
Exported schedules and timelines contain staff names, contact details and on-call patterns, so they are personal data. Decide where the files will live, who can read them, how they are encrypted, and how long they are kept after GoAlert goes live. Check this with your privacy and information security teams before the first export, because the storage location is hard to change once files are copied across several systems.
Integrations to re-point
List every system that sends alerts to Opsgenie, including monitoring tools, cloud alarms, email senders, chat bots, and custom scripts that call the Opsgenie API. For each one, note the current integration type, the owning team, and the GoAlert alert source that will replace it. Alert sources such as Prometheus, Grafana, email and the generic API need to be tested against GoAlert before the old integration is switched off.
GoAlert hosting and PostgreSQL plan
GoAlert needs PostgreSQL 17 or newer for new installations and the pgcrypto extension. Decide where the database and the GoAlert instances will run, who operates them, and how they are backed up and failed over. Plan for at least one instance in default engine mode and additional instances in API-only mode if you run more than one. Confirm the data encryption key is stored in a secrets system and is identical on every instance before any credentials are imported.
Notification provider account
Twilio is the only supported provider for GoAlert voice and SMS notifications, so an account with Twilio needs to exist before cutover. Confirm that sender numbers, country coverage and message templates work for every responder who receives pages, and that Slack and email delivery are tested alongside them. Ask who owns the Twilio account, how its billing is tracked, and who can rotate its credentials.
Questions teams ask before exporting Opsgenie data
How much effort does an Opsgenie data export take?
The effort depends on how much you need to pull and how well your current setup can be exported. The main drivers are the number of schedules, since each has its own calendar and rotation history, the number of integrations and alert sources whose settings you must record, how far back your timelines and history go, and whether your team already has working API access. A small account with a few schedules and one API user is a short task. A large account with years of history, many integrations and several regions takes longer because each item needs to be checked, saved and labeled so it can be rebuilt in GoAlert.
Can one internal engineer export Opsgenie data alone?
A single engineer with administrator access and API experience can usually complete the export, provided the scope is small. Schedules can be downloaded as iCalendar files, and timelines can be pulled through the Schedule API using a GenieKey for authentication. The harder part is not the download but the inventory: someone must know which teams own which schedules, which escalation paths depend on them, and which alert sources send alerts to them. Teams with many owners often split this work between an engineer who runs the API calls and an on-call lead who confirms the rotations.
What does an Opsgenie export need from security and compliance teams?
Security and compliance teams should review three areas before any export starts. First, GenieKey credentials must be issued to a named owner, scoped to the minimum access needed, stored in a secrets manager, and revoked when the work ends. Second, exported files contain on-call names, contact details and schedule history, so they should be encrypted at rest, moved over approved channels and kept in a restricted location. Third, retention rules must be set for the exports and for the copies in GoAlert, including who can read them and when they are deleted. Your compliance team should record these decisions, since auditors will ask how this personal data was handled during the move.
How long does the export take?
The duration is set by the same drivers that set the effort: the number of schedules, integrations and alert sources, the depth of history you keep, and how many API hosts and regions your account uses. Atlassian's documentation and your own account inventory are the right sources for a planning figure, so no duration is given here. A practical approach is to count schedules, rotations and integrations first, run one schedule end to end as a test, and then extrapolate. Plan the export well before April 5, 2027, because deleted data cannot be recovered after that date and rebuild work in GoAlert needs time for testing.
Do we need a consultant, and what does a fixed-scope engagement cover?
A consultant is not required, but many teams bring in outside help when the account is large, multi-region or tied to many integrations. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For an Opsgenie export, a written scope could cover the schedule and timeline inventory, the export runs, a check of the files, and the handoff notes for rebuilding in GoAlert. Ask any provider for a written scope, the exact deliverables and the acceptance criteria before you sign. Quotes follow from that scope.
What should we confirm with Atlassian before the Opsgenie deadline?
Confirm the exact shutdown and data deletion dates in writing, since undeleted data is removed on April 5, 2027. Ask which API host applies to your tenant, the US or EU host, so your scripts do not fail or pull from the wrong region. Ask how GenieKey credentials are created, rotated and revoked, and whether any export feature applies to your plan or deployment type. If you run Data Center, ask which download option Atlassian describes for your version and what it includes. Also ask whether schedule history, timelines and attachments are covered, and whether any export limits apply. Record each answer with the date you received it.
How DeployOpen scopes and delivers an Opsgenie data export
DeployOpen treats the Opsgenie export as a fixed-scope piece of work with written deliverables, agreed before any data is pulled. The work covers schedules, timelines and the metadata needed to rebuild on-call in GoAlert, run inside your own infrastructure and in line with your retention and access rules.
How we scope
- Inventory which teams, schedules, escalation policies and integrations exist in your Opsgenie account and which API host region they use.
- Agree in writing which data classes are exported, such as schedules as iCalendar files and timelines, and where each export is stored.
- Confirm with your Atlassian contact which export path applies to your plan and deployment before the April 5, 2027 deletion date.
How we build
- Create scripted exports using GenieKey authentication, with keys held in a secrets store and scoped to read-only access.
- Validate each export by comparing record counts and sample schedules against the live Opsgenie view before anything is deleted.
- Store exports encrypted on infrastructure you control, with checksums and a log of every run for audit review.
How we hand over
- Deliver a runbook covering each export command, its inputs, its outputs and the known gaps that need manual review.
- Document where each file sits, who holds access and how long it is retained under your data handling policy.
- Walk your on-call and platform leads through the handover so they can rerun or extend the export without DeployOpen.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer if your rebuild in GoAlert runs past the export.
- Ask for a quote that lists the export, validation, documentation and handover items separately, so each cost is visible.
- Confirm with your own security and compliance teams what evidence they need, since DeployOpen prepares records but does not issue audit reports.
