home / skills / jeremylongshore / claude-code-plugins-plus-skills / sentry-migration-deep-dive

sentry-migration-deep-dive skill

/plugins/saas-packs/sentry-pack/skills/sentry-migration-deep-dive

This skill guides migrating from other error trackers to Sentry, coordinating parallel runs, mapping APIs, and validating parity.

npx playbooks add skill jeremylongshore/claude-code-plugins-plus-skills --skill sentry-migration-deep-dive

Review the files below or copy the command above to add this skill to your agents.

Files (5)

SKILL.md

1.7 KB

---
name: sentry-migration-deep-dive
description: |
  Execute migrate to Sentry from other error tracking tools.
  Use when migrating from Rollbar, Bugsnag, Raygun,
  or other error tracking solutions.
  Trigger with phrases like "migrate to sentry", "sentry migration",
  "switch from rollbar to sentry", "replace bugsnag with sentry".
allowed-tools: Read, Write, Edit, Bash(npm:*), Bash(pip:*), Grep
version: 1.0.0
license: MIT
author: Jeremy Longshore <[email protected]>
---

# Sentry Migration Deep Dive

## Prerequisites

- Current error tracking tool access
- Sentry project created
- API access to old tool (for data export)
- Parallel run timeline established

## Instructions

1. Complete assessment phase documenting current tool usage
2. Set up Sentry projects matching existing structure
3. Install Sentry SDK alongside existing tool for parallel running
4. Map feature equivalents between old tool and Sentry APIs
5. Run both tools in parallel for 2-4 weeks
6. Compare error capture rates and verify parity
7. Recreate alert rules in Sentry matching old tool
8. Export historical data from old tool API if needed
9. Remove old SDK dependencies and configuration
10. Train team on Sentry dashboard and cancel old subscription

## Output
- SDK migration complete
- Historical data exported (if needed)
- Alert rules recreated
- Team transitioned to Sentry

## Error Handling

See `{baseDir}/references/errors.md` for comprehensive error handling.

## Examples

See `{baseDir}/references/examples.md` for detailed examples.

## Resources
- [Sentry Migration Guide](https://docs.sentry.io/product/accounts/migration/)
- [SDK Documentation](https://docs.sentry.io/platforms/)

Overview

This skill guides teams through a practical, low-risk migration from other error tracking tools to Sentry. It packages a step-by-step migration plan, checks, and outcome criteria so you can run both systems in parallel, validate parity, and complete a safe cutover. The goal is a clean SDK migration, recreated alerts, and an informed team using Sentry.

How this skill works

The skill inspects your current error tracking setup and provides a staged checklist: assessment, project mapping, SDK installation for parallel runs, feature mapping, and data export options. It recommends timelines, verification steps for capture parity, and a final removal and training process to fully transition to Sentry. It also points to official Sentry resources for SDKs and migration specifics.

When to use it

When replacing Rollbar, Bugsnag, Raygun, or another error tracker with Sentry
When you need to validate error capture parity before decommissioning the old tool
When you must migrate alerting and workflows to Sentry without losing history
When you require a parallel run to compare capture rates and false positives
When you need an actionable plan to train the team and remove old SDKs

Best practices

Run Sentry alongside the existing tool for 2–4 weeks to compare real traffic
Document current usage, project structure, and alert rules before starting
Map features and API equivalents early to avoid surprises during cutover
Export historical data from the old tool if retention or compliance requires it
Recreate alerts and integrations in Sentry and verify notifications before disabling the old system

Example use cases

A web app migrating from Rollbar to consolidate observability in Sentry while retaining historical errors
An engineering org replacing Bugsnag to unify error tracking and alerting across services
A SaaS product validating error capture parity between Raygun and Sentry during a phased rollout
A compliance-driven team exporting retained error data before decommissioning the old provider

FAQ

How long should I run both tools in parallel?

Run both for 2–4 weeks to capture representative traffic and identify gaps in capture or alerts.

Do I need to export historical data?

Only if retention, compliance, or debugging needs demand it; otherwise recreate alerts and accept a new baseline in Sentry.