Move in from Opsgenie or PagerDuty

You can bring your rota across from Opsgenie or PagerDuty without connecting Oncall to either of them. You save export files yourself, Oncall reads those files, and you review what it understood before anything is kept. It asks for no API key, makes no request to Opsgenie or PagerDuty and changes nothing there.

Only an admin can use the Move-in kit, the screen with the arrows icon in the app. Your pager stays in charge of waking people up: everything you move in arrives paused, and paging stays off.

Save your exports

Oncall reads one JSON file. It is an object with one entry per kind of data, and each entry is either a list or the response the service gave you (the one with a data field). Both work.

From Opsgenie, save these under these names:

• users
• schedules, with the rotations expanded (or save each schedule's detail response)
• overrides, with the schedule's ID added as scheduleId beside data, because Opsgenie's override list does not say which schedule it belongs to. If the file holds only one schedule you can leave it out; with several schedules and no ID, the overrides and every schedule they could change are refused by name.
• escalations
• timelines, the final schedule timelines, as Opsgenie returned them

From PagerDuty, save these:

• users
• schedules, each one as the detailed schedule that includes its schedule_layers. The list response alone is not enough if it leaves the layers out.
• overrides, with the schedule's ID added as schedule_id beside overrides (the same rule as Opsgenie when it is left out)
• escalation_policies

Timelines are optional, and so is the final_schedule inside a PagerDuty schedule. They let Oncall check its answer against yours, which is worth doing (see below).

People are matched by email address. A rotation or override that names someone who is not in your users is rejected, never filled in with a guess.

Leave keys, tokens, routing or integration keys, webhook URLs and calendar URLs out of the file. If any appears anywhere in it, Oncall refuses the whole file and names the field.

The file can be up to 500 KB and 500 objects. It will hold your people's names and email addresses, so keep it private.

Preview, then import

1. Open Move-in kit and choose Opsgenie or PagerDuty under Source.
2. Choose your file under Export JSON.
3. Press Preview import. This is a dry run: it writes nothing, however often you press it.
4. Read the Compatibility review. It counts what mapped, what was rejected and what came across with differences, then lists every object with its reason. Nothing is skipped quietly.
5. If you are happy, press Confirm paused import. Oncall applies exactly the preview you reviewed, so if you pick a different file you preview again first.

The people, schedules and escalation policies land in Paused imported data. They do not get a sign-in, they do not appear as live schedules and they page no one. If the import is interrupted, choose it under Saved import journal and press Resume import.

What the preview checks

If you supplied a final timeline, Oncall compares it with its own answer at every hand-over, inside the window the timeline covers. The result says the two agree in that window, lists each difference, or says no timeline was supplied and so nothing is claimed.

An agreement is only about that window. It does not promise the next clock change, schedule edits you make later, or that anyone was actually reached.

Undo

Press Undo this import on an import in the journal to reverse it. Oncall removes what that import added and puts back what was there before. If anything it added has been changed since, Oncall keeps your change, stops with a conflict named NATIVE_EDIT_CONFLICT rather than overwrite it. The file you supplied stays in the journal as a record.

Erase a person

Under Paused imported data, press Erase person beside someone you imported, type erase followed by their exact email, and press Erase permanently. Oncall removes that paused person, leaves their slots in imported rotations as explicit gaps, and erases them from the import journal. Every export made before the erasure is refused whole if you try to bring it back in. Imports that named them can no longer be undone, and anything still waiting in an import that names them is never brought in. The answer shows a receipt number, and says so if a member of your workspace shares the email; that member is not changed.

People are matched by their exact email, so someone whose address merely contains theirs is left alone.

What comes across

• Opsgenie: a schedule with one daily or weekly rotation of individual people, a hand-over at an exact calendar minute and no time restrictions.
• PagerDuty: a schedule with one current layer whose turns are whole days. Layers that ended before it began are kept as named history in the review, never as coverage. A layer in UTC maps directly; a layer in a zone with clock changes (for example America/New_York) maps only when its final_schedule agrees with Oncall's answer across a clock change, and otherwise is rejected with the first instant they differ.
• Overrides: one person each, not overlapping.
• Escalation policies: one or two steps, each handing to a single schedule after an ordinary "if not acknowledged" delay in minutes, with no repeats.

Oncall keeps the primary rotation. The backup is shown as an explicit gap, because a single source rotation is never relabelled as backup. See Schedules and hand-overs to add one.

What stays different

These are named in the preview rather than approximated. A schedule or policy with any of them is rejected whole, and the reason is listed:

• turns shorter than a day, and PagerDuty schedules outside UTC without a timeline that shows they agree across a clock change
• disabled Opsgenie schedules, since they put no one on call
• two layers active together, a layer still running when its replacement starts later, nested schedules, teams, and empty slots
• overrides with more than one person, and time restrictions
• policies with more than two steps, repeats, other conditions, several people at once, or a person instead of a schedule
• any rotation or rule field Oncall does not know

Some things are not moved at all: notification rules (kept as notes only, never switched on), routes and event rules, maintenance windows, and incident history.

Before you trust it

Oncall has been checked against sample files built from the documented Opsgenie and PagerDuty response shapes, not yet against real customer exports. Run it beside your pager for a week or two and compare, and keep your own export as the record. Moving your data out and in again is covered in Export and restore, and what Oncall leaves alone is in What Oncall does not do.

Format references, read on 13 October 2026: Opsgenie's Schedule API, Schedule Override API and Escalation API; PagerDuty's detailed schedule, schedule overrides and escalation policy references.