Sentry Migration Examples | Rails, Laravel, Django, React, Next.js

Stack-by-stack examples for moving error tracking to Telebugs

These are practical migration scenarios, not invented customer stories. Use them to plan how a Rails, Laravel, Django, React, or Next.js project can keep its Sentry SDK workflow while sending new errors to a self-hosted Telebugs instance.

How to use these examples

Start with the general Sentry migration guide. Then use the stack example closest to your app. The pattern is the same in every case: inventory the existing SDK setup, create a Telebugs project, change the DSN in staging, send controlled errors, validate the stored context, rebuild notifications, then roll out gradually.

The examples focus on new errors going forward. They do not promise a historical import of old Sentry issues, comments, assignments, or event history.

Migration map

Stack First validation target Common rollout risk Deeper guide
Rails Controller exception, job error, tags, user context, release. Background jobs and worker environments using a different DSN or release value. Rails error tracking
Laravel HTTP exception, queue job, environment, request context, user context. Queue workers and scheduled commands not picking up updated environment variables. Laravel error tracking
Django View exception, Celery task, request data, tags, environment. Multiple processes or worker containers using inconsistent SDK configuration. Django error tracking
React Browser error, release, sourcemap resolution, route breadcrumbs. Source maps and release names not matching the deployed frontend bundle. React error tracking
Next.js Client error, server error, API route error, release, source maps. Client and server runtimes needing separate validation and deploy hooks. Next.js error tracking

Rails migration example

A Rails app often has errors from controllers, background jobs, mailers, and scheduled tasks. Treat staging as the first migration target. Keep the Sentry Ruby/Rails SDK setup, point the DSN at a Telebugs Rails project, and trigger one controlled error from each runtime that matters.

  • Inventory: Rails initializer, environment variables, release naming, Active Job or worker setup, source map upload if the app ships JavaScript.
  • Staging test: trigger a controller exception, a job failure, and one handled exception if your team reports those.
  • Validate: stack frame quality, tags, user context, request data, breadcrumbs, environment, release, and notification routing.
  • Rollout: move one production service or environment first, keep Sentry available for old issues, and watch job-worker volume closely.
  • Rollback: restore the old DSN and restart the relevant web and worker processes.

Laravel migration example

Laravel migrations need to include more than web requests. Queues, scheduled commands, APIs, and workers are often where production errors become operationally important. Change the DSN in staging and confirm that every process that reports errors has picked up the same configuration.

  • Inventory: Sentry Laravel package setup, `.env` values, queue workers, scheduler, Horizon or supervisor configuration, release naming.
  • Staging test: trigger one route exception, one queued-job failure, and one scheduled-command failure if scheduled work matters.
  • Validate: exception grouping, request context, user context, queue metadata, environment, release, and notification rules.
  • Rollout: restart workers after the DSN change, then move one lower-risk production app or queue first.
  • Rollback: restore the previous DSN and restart web, queue, and scheduler processes.

Django migration example

Django projects commonly have web views, admin actions, management commands, and Celery tasks. Migration works best when each runtime is tested separately instead of assuming a single web request proves the whole app is covered.

  • Inventory: Sentry Python/Django configuration, environment variables, Celery or task workers, deployment release value, logging integration.
  • Staging test: trigger a view exception, a Celery task failure, and a management-command error if those paths report today.
  • Validate: in-app frames, request data, user context, tags, breadcrumbs, environment, release, and worker errors.
  • Rollout: deploy the DSN change to one service first, then confirm both web and worker containers are reporting to Telebugs.
  • Rollback: restore the old DSN and redeploy or restart all reporting processes.

React migration example

React migration usually centers on source maps, release names, browser context, and route breadcrumbs. A DSN change can be simple, but a useful migration proves that production-like minified errors resolve to readable source.

  • Inventory: Sentry browser SDK setup, DSN injection, release naming, environment, source map upload job, routing breadcrumbs.
  • Staging test: trigger a browser exception from a bundled page and one error after navigation.
  • Validate: source map resolution, browser metadata, tags, release, environment, user context, and route breadcrumbs.
  • Rollout: ship to a low-risk frontend environment first and compare source map behavior before moving high-traffic apps.
  • Rollback: redeploy the frontend with the previous DSN and release upload target.

Next.js migration example

Next.js needs client and server validation. A useful migration checks browser errors, server-rendering errors, API route errors, source maps, and release behavior. Treat those as separate test cases even if they share one codebase.

  • Inventory: Sentry Next.js setup, client DSN, server DSN, release naming, build pipeline, source map upload, runtime environments.
  • Staging test: trigger one client error, one server-rendering error, and one API route error.
  • Validate: client/server separation, source maps, request context, breadcrumbs, release, environment, and notification rules.
  • Rollout: deploy one production environment first and watch both browser and server event volume.
  • Rollback: restore previous build-time and server-side DSN values, then redeploy.

Shared validation checklist

  • Does the event arrive in the intended Telebugs project?
  • Does the event include the expected environment and release?
  • Are stack traces readable and grouped in a way your team understands?
  • Do tags, user context, breadcrumbs, request context, and extras match what you expect?
  • Are sensitive fields scrubbed before storage?
  • Do notifications reach the right channel without too much noise?
  • Can the team resolve, mute, annotate, and reopen issues in the new workflow?
  • Can you roll back by restoring the old DSN and redeploying?

When to request a private demo

Use a private demo when the migration question is about workflow rather than infrastructure. Bring one sample project, one representative error, the current Sentry SDK setup, and the context you need to validate: source maps, queue/job metadata, user context, releases, notifications, or MCP access.

Frequently asked questions

Are these real customer case studies?

No. These are stack-specific migration examples based on common Sentry SDK workflows. They are meant to help teams plan validation, not to imply a named customer rollout.

Do we need to change SDKs?

Usually no for core error reporting. Telebugs is Sentry SDK compatible, so the first migration test is usually changing the DSN and validating real events.

Which stack should we migrate first?

Start with the app that has useful errors, manageable volume, and low rollback risk. Avoid starting with the most critical production service unless the team has already validated staging.

Can we keep Sentry during rollout?

Yes. Many teams keep Sentry available for historical lookups while sending new test or production errors to Telebugs project by project.