# How to use a Righthand with Opsgenie

Use Righthand to prepare an Opsgenie transition inventory for an existing customer.

By Righthand Team · 2026-10-12

Source: https://www.righthand.ai/blog/how-to-use-righthand-with-opsgenie

## Quick answer

Use Righthand to prepare an Opsgenie transition inventory for an existing customer. This is a continuity review, not a recommendation to start a new standalone account.

Start with a reviewable deliverable, keeping Opsgenie as the accepted home for its records. This guide uses an explicitly approved snapshot or browser read; it does not assume that every provider API action is exposed by your Righthand connection.

## Evidence and access

Atlassian ended new Opsgenie sales on June 4, 2025 and states that support ends April 5, 2027. See the [official Opsgenie reference](https://www.atlassian.com/software/opsgenie/migration). Provider capabilities and Righthand's available tools are separate checks.

Use preserved inventory for the owner's existing account and migration plan, including alert routes, schedules, destination owners, and actual transition evidence. Verify the required tools and owner-approved scope through [Righthand integrations](/integrations); use the supplied packet when a native read is unavailable.

## Define the objects and authority

Include these fields in the working input: team, alert route, schedule, integration, escalation, owner, proposed destination, migration evidence. These are the requested review columns, not a promise that every provider endpoint returns them under those exact names.

Keep migration, billing, and routing changes with the authorized administrators. A copied schedule is not proof the replacement system pages correctly.

| Responsibility | Owner |
| --- | --- |
| Prepare source scope and access | Account owner |
| Organize evidence and proposed next steps | Righthand |
| Approve consequential changes | the migration administrator |

## Illustrative first-run brief

> Use the owner-provided Opsgenie snapshot or approved read-only view. Review the supplied existing-account inventory and approved migration plan. Identify routes without a destination owner and tests still missing. Do not change schedules or start migration. Run once for the agreed sample, using America/Los_Angeles for the review deadline and preserving source timestamps separately. Return the draft in this conversation by Friday at 3 PM Pacific for the migration administrator to review. Include source references and missing fields. Do not write records, spend money, change permissions, or send external messages. Stop and report an unavailable source rather than substituting another account.

## Expected result and verification

An escalation policy mapped on paper remains awaiting a real destination test. The packet labels that acceptance gap.

Check one source route and its destination mapping against the administrator's plan, then require an approved paging test separately. Record the source cutoff, applied filters, and items excluded from the sample. The reviewer should be able to follow each consequential finding back to an original object. A well-written summary is not evidence that a proposed action happened. If a later write is authorized, verify its specific result separately before changing the task's status.


### Illustrative input and draft output

These synthetic entries show the requested review, not live account results or a provider field schema.

| Source item | Supplied observation | Draft conclusion |
| --- | --- | --- |
| Route A | Destination owner named | Mapping review ready |
| Schedule B | Copied, test absent | Paging acceptance pending |
| Integration C | Legacy access unavailable | Use preserved evidence |

## Common failure and recovery

A site already turned off can have unavailable history or integrations. Use preserved owner evidence and current migration status rather than promising continued access.

For unavailable legacy items, request preserved owner evidence and current destination status. Keep the acceptance gap visible rather than implying continued source access.

## FAQ

### What should the reviewer verify first?

Verify source route, target mapping, migration owner, and approved destination test. Mapping an escalation on paper does not prove paging reaches the right responder.

### How should a repeat run be scoped?

Tie each review to migration milestones and source availability. Recheck destination tests after changes; retain legacy identifiers so unresolved mappings remain traceable.

For connection and permission details, use [Righthand Docs](https://docs.righthand.ai). Review [Pricing](/pricing) alongside any separate provider charges before expanding the workflow.