Sentry Migration Guide | Move Error Tracking to Telebugs

Who this guide is for

Use this guide if your team already sends production errors to Sentry and wants to evaluate Telebugs as a focused self-hosted backend. It is not a bulk data import guide and it is not a promise that every Sentry product feature has a Telebugs equivalent. It is a practical path for moving the core error tracking workflow.

For the category comparison, read Telebugs vs Sentry. For stack-specific rollout examples, read Sentry migration examples. For the protocol details, read Sentry SDK compatible error tracking.

What usually migrates

• SDK package and initialization: keep your existing Sentry SDK setup and change the DSN.
• Error events: exceptions, stack traces, messages, tags, extras, environment, release, user context, request data, and breadcrumbs.
• Release habits: release names and source map workflows can continue after you point them at Telebugs.
• Alerting habits: rebuild notification routes in Telebugs using email, push, Teams, Discord, webhooks, and rules.
• Team triage habits: grouping, notes, resolve/unresolve, muting, and ownership can move into Telebugs for new errors.

What does not automatically migrate

Historical Sentry issues do not automatically appear in Telebugs. Most teams start fresh for new errors, keep Sentry available temporarily for old incident references, and move project by project.

• Historical issue archives, comments, assignments, and old event history.
• Sentry-specific observability products such as tracing, replay, profiling, logs, uptime, cron, and hosted AI features.
• Exact alert rules, dashboards, ownership settings, integrations, and retention policies.
• Any custom workflow that depends on Sentry APIs beyond standard error reporting.

Migration plan

1. Inventory projects. List apps, environments, SDK packages, release naming, source map upload jobs, and alert destinations.
2. Install or request a demo. Use a private Telebugs demo for team evaluation, or install Telebugs on a staging server.
3. Create the first project. Copy the Telebugs project DSN.
4. Change the DSN in staging. Keep the rest of your SDK configuration as-is.
5. Send controlled test errors. Trigger one backend error, one frontend error if relevant, and one background job or queue error.
6. Validate the context. Check grouping, stack traces, breadcrumbs, tags, user context, release, environment, request data, and source maps.
7. Rebuild notifications. Configure email, webhooks, Teams, Discord, push, and rules for the project.
8. Move one low-risk production service. Watch volume, notification quality, and team workflow for a few days.
9. Repeat project by project. Keep Sentry available for historical lookups until your team no longer needs it.

Validation checklist

• Does the event arrive in the expected Telebugs project?
• Does grouping match how the team thinks about repeated errors?
• Are in-app stack frames readable and useful?
• Do breadcrumbs show the path to the failure?
• Are tags, release, environment, user context, and request context present?
• Are sensitive fields scrubbed before storage?
• Do source maps resolve minified frontend frames?
• Do notifications reach the right people without too much noise?
• Does MCP access, if enabled, expose the context your AI coding tool needs?
• Can the team roll back by restoring the old DSN?

Rollback plan

Keep migration reversible until you are comfortable. The simplest rollback is to restore the old Sentry DSN and redeploy. Events sent to Telebugs stay in Telebugs; events sent to Sentry stay in Sentry. If your team needs a combined historical record, plan that before cutting over critical projects.

Private demo migration review

If you want to test the flow before buying, request a private demo instance. Mention your stack, current Sentry SDKs, and what you want to verify. A focused migration review usually checks one project, one real test error, one notification path, and one source map or release workflow. For concrete stack examples, review Rails, Laravel, Django, React, and Next.js migration scenarios.

Source notes

This guide depends on public Sentry SDK behavior rather than private Sentry APIs. The most useful upstream references are Sentry's platform docs, event payload docs, and envelope docs.

Frequently asked questions

Is migration really just a DSN change?

For basic error reporting, often yes. Still validate real events because source maps, filtering, releases, notifications, and team workflow matter in production.

Can I run Sentry and Telebugs side by side?

Yes. Many teams migrate one project or environment first while keeping Sentry available for old errors and comparison.

Does Telebugs import historical Sentry issues?

Not as an official built-in migration path today. Start fresh for new errors and keep Sentry read-only temporarily if historical reports still matter.

What should I test first?

Test one real error from staging, confirm stack trace quality, verify breadcrumbs and tags, trigger a notification, and check that sensitive fields are not stored.