migrate-from-opsgenie

Migrating from Opsgenie to ilert

The hard part is not the object mapping — it is that the two products route alerts through different objects. Opsgenie routes team-first; ilert routes source-first. A simple setup maps one-to-one, but any configuration that leaned on team routing rules routes differently after a faithful field-by-field import.

For ilert's own semantics and the CLI behaviour behind a bulk import, read the ilert-essentials skill alongside this one. Where Opsgenie's own data lives — and how to hold a foreign API key while you read it — is under Reading the Opsgenie side below; start there when the job is extraction rather than design.

The routing model difference

In Opsgenie an integration hands an alert to a team, and the team's routing rules decide which escalation applies, with alert/notification policies filtering along the way.

In ilert the Alert Source owns the escalation policy directly. There is no object equivalent to a team routing rule, but two mechanisms between them absorb almost every routing rule you will find, and they are where to look first:

• Routing keys — when the emitter can name the branch it wants. An Escalation Policy carries a routingKey. An event supplying a matching key overrides the alert source's own policy. Keys are comma-separated and evaluated left to right, falling back to the source's policy when none match, and the key can be pulled from the payload with the alert source's routingTemplate. One alert source, several escalation paths, no extra objects.

• Event Flows — for everything else. This is the general answer whenever an Opsgenie rule has no direct equivalent in an alert source setting. An Event Flow is a routing layer that sits above alert sources rather than beside them: it has its own integrationKey / integrationUrl, so emitters post to the flow instead of to a source, as a drop-in replacement for a source URL at the sender. Inside it is a tree of nodes: