The integration layer is where most Opsgenie migrations get hard. Users, groups, and schedules import cleanly through the migration tool; integrations don’t. An AlertOps SE was direct with a New York MSP about the constraint during a migration call: “The only thing that it cannot bring over is your integration.” The reason is that Opsgenie integrations are configurations with external dependencies (monitoring tools, ticketing systems, custom webhooks) and the destination side of each integration needs to be configured manually to match what the source system expects.
This guide is the procedure for migrating Opsgenie integrations to AlertOps without breaking the upstream connections. Covers inbound integrations (observability tools feeding alerts in), outbound integrations (AlertOps feeding into ITSM and chat), the ConnectWise deprecation story affecting MSPs specifically, and what the AlertOps migration team handles hands-on.
Hub-and-spoke integration map showing inbound observability sources (Datadog, Splunk, Prometheus, AWS CloudWatch, Azure Monitor, New Relic, PRTG, SolarWinds) flowing into AlertOps as free inbound integrations, then outbound to destinations including ServiceNow and Jira (bidirectional with status sync), Microsoft Teams and Slack (outbound), and ConnectWise (bidirectional via dedicated API). Premium tier supports 3 outbound integrations per incident; Enterprise tier supports unlimited.
What does “integrations” actually mean in an Opsgenie migration?
Three categories of integration appear in every enterprise Opsgenie environment.
Inbound integrations receive alerts from external systems. Datadog, Splunk, Prometheus, AWS CloudWatch, Azure Monitor, New Relic, PRTG, SolarWinds, and dozens of others. The integration is typically a webhook URL that the external system posts alert payloads to, plus routing rules that determine which AlertOps team or rotation receives the alert.
Outbound integrations push status and updates to downstream systems. ServiceNow, Jira, Microsoft Teams, Slack, custom internal systems. The integration is typically a webhook or API call that AlertOps triggers when an incident changes state.
Bidirectional integrations sync state both directions. ServiceNow ticket creation when an alert opens, status synchronization as the incident progresses, ticket closure when the incident resolves. AlertOps’s ServiceNow and Jira integrations are first-class bidirectional integrations rather than one-way webhooks.
Each category requires a different migration approach.
How to migrate Opsgenie integrations
The full procedure runs in six steps.
Step 1: Inventory every Opsgenie integration. Use the Opsgenie API integration endpoint to pull the complete list. For each integration, capture: source system, integration type (webhook, API, email), endpoint URL, payload format, routing rules, and the team/rotation it feeds. For larger environments with hundreds of integrations, this inventory is the longest part of the migration.
Step 2: Audit which integrations are still active. Some integrations in the inventory will be dormant (the source system was retired, the project ended, the team that owned it moved on). The migration is the moment to retire dormant integrations rather than carry forward the operational debt. For each integration on the list, confirm the source system is still active and the routing target is still correct.
Step 3: Build the AlertOps inbound integrations. For every active inbound integration in the inventory, create the corresponding AlertOps integration. AlertOps’s marketplace exceeds 200 pre-built integrations across observability, monitoring, ITSM, CMDB, chat, and ticketing. An AlertOps SE described the coverage during an MSP demo: “200+ pre-built integrations… anything which sends a webhook like an API… or maybe even a simple email we can customize and build it for you. So it’s on our end. We’ll take care of building that. Inbound is free.” For source systems not on the marketplace, AlertOps supports custom webhook integrations and the migration team builds these as part of the engagement.
Step 4: Update the source system endpoint URLs. For each inbound integration, update the source monitoring tool to point at the new AlertOps webhook URL. This is the cutover moment per integration – the alerts start flowing to AlertOps instead of Opsgenie. During the parallel-run cutover window, configure source systems to fire to both platforms simultaneously so the safety net stays in place.
Step 5: Configure the outbound integrations. For every active outbound integration in the inventory, configure the AlertOps outbound webhook or API call. Premium tier supports up to three outbound integrations per incident; Enterprise tier supports unlimited. For environments with more than three outbound destinations per incident, the Enterprise tier is the required configuration. The migration team handles the outbound configuration as part of the engagement.
Step 6: Validate bidirectional integrations specifically. ServiceNow, Jira, and other bidirectional integrations require validation that status synchronization works both directions, assignment changes propagate, and ticket lifecycle aligns with incident lifecycle. Test alerts during the parallel-run window confirm the round-trip.
The ConnectWise deprecation story (MSPs read this)
For managed service providers running Opsgenie with the ConnectWise PSA integration, the migration story has an additional layer. Atlassian deprecated the Opsgenie ConnectWise integration, grandfathered existing customers into a brittle, unsupported state, and stopped accepting new ConnectWise integrations through Opsgenie. An IT director at a New York luxury-residential MSP described the situation: “They basically said we can’t deal ConnectWise. They’re not working with us. They’re not fixing us. They deprecated the service so you couldn’t get it again, but because we had it, we were grandfathered into it. But we just built out everything around it ourselves.”
A second MSP described the same pattern: “Office 365 basically deprecated their ConnectWise integration a while ago. It was still working for us, but we couldn’t add any new integrations for that or make any significant changes.”
AlertOps has an actively maintained, dedicated ConnectWise API integration. As an AlertOps SE described to one of the affected MSPs: “Since OpsGenie nerfed down their integration piece, we have a much more robust tool and we can configure it much faster. We do have a dedicated API connection with ConnectWise.” For MSPs running on grandfathered Opsgenie ConnectWise configurations, the migration is the opportunity to land on a supported integration rather than continue maintaining custom shims around a deprecated one.
Patterns that recur in enterprise migrations
Four integration patterns require explicit handling.
Datadog as observability source feeding AlertOps. The most common inbound integration in enterprise environments. The Datadog webhook fires into AlertOps; OpsIQ correlates the alerts; the responder receives enriched incidents. For environments where Datadog is the primary monitoring source, the integration carries most of the alert volume.
New Relic routing to JIRA + ServiceNow simultaneously. A pattern observed at an enterprise dev tools customer: New Relic alerts route into AlertOps, then AlertOps fires outbound to both JIRA (for engineering ticket creation) and ServiceNow (for ITSM record). The Enterprise tier’s unlimited outbound configuration handles this multi-destination routing.
PRTG email-only outbound. Some Opsgenie deployments used PRTG with email-only outbound to AlertOps because the customer’s network team did not open PRTG to the internet for webhook delivery. AlertOps supports email-based inbound integrations for these constrained environments.
Multi-stack chat + monitoring + ITSM. A representative enterprise integration stack: Slack, JIRA, Microsoft Teams, NetCrunch, Site24x7, Azure Monitor, plus a custom internal alerting system. The AlertOps free migration team builds out the full stack as part of the engagement; for environments with custom in-house systems, the team builds the webhook adapter and validates the payload mapping.
What the migration tool migrates versus what’s hands-on
The automated migration tool handles users, groups, schedules, and escalation policies. It does not auto-migrate integrations. Integration migration is hands-on with the AlertOps Solution Engineering team during the migration engagement. The typical engagement runs three to six working sessions for enterprise environments with dozens of integrations, with the inbound configuration on the AlertOps side and the source-system endpoint updates done together during the parallel-run cutover window.
For environments running custom or non-standard integrations, the migration team builds the adapter as part of the engagement. As one AlertOps SE described to a mid-market data center customer: “200+ pre-built integrations – anything which sends a webhook like an API or maybe even a simple email we can customize and build it for you. It’s on our end. We’ll take care of building that.”
Frequently asked questions
How do I migrate my Opsgenie integrations to AlertOps?
Integration migration is hands-on with the AlertOps Solution Engineering team rather than fully automated. The procedure runs in six steps: inventory every Opsgenie integration, audit which are still active, build the AlertOps inbound integrations, update source system endpoint URLs, configure outbound integrations, and validate bidirectional integrations specifically.
Can the AlertOps migration tool auto-migrate my integrations?
No. The automated tool handles users, groups, schedules, and escalation policies but not integrations. Integrations require source-side endpoint updates and destination-side configuration that the migration team handles hands-on during the engagement.
What happens to my Opsgenie ConnectWise integration?
Atlassian deprecated the Opsgenie ConnectWise integration. Existing customers were grandfathered into a brittle, unsupported state with no new integrations possible. AlertOps has an actively maintained, dedicated ConnectWise API integration that replaces the deprecated Opsgenie one.
Does AlertOps integrate with Datadog?
Yes. AlertOps’s Datadog integration is bidirectional. Datadog alerts fire into AlertOps; OpsIQ correlates; AlertOps can push status updates back to Datadog. The integration is part of the 200+ pre-built marketplace.
How many outbound integrations does AlertOps support per incident?
Premium tier supports up to three outbound integrations per incident. Enterprise tier supports unlimited outbound integrations. For environments routing incidents to many downstream systems simultaneously (JIRA + ServiceNow + Slack + Teams + custom), Enterprise is the required configuration.
Is inbound integration free in AlertOps?
Yes. Inbound integrations are included in AlertOps Enterprise without per-event metering. Outbound integrations are capped on Premium (three per incident) and unlimited on Enterprise.
Does AlertOps support custom webhook integrations?
Yes. For source systems not on the 200+ marketplace, AlertOps supports custom webhook integrations. The migration team builds the adapter as part of the engagement, including payload mapping and endpoint validation.
What does the AlertOps ServiceNow integration do?
The AlertOps ServiceNow integration is bidirectional and first-class. Status updates flow both directions, assignment changes synchronize, ticket lifecycle aligns with incident lifecycle.
