# How do I move from Sentry to another error tracker without rewriting my instrumentation?

Keep your Sentry SDK and change where it sends. Inventory the SDK features you use, run the new destination alongside the old one, swap the DSN, recreate alert rules, point sentry-cli source map uploads at the new host, verify with a deliberate error, and keep the old DSN as a rollback. Expect gaps: history may not carry over.

Canonical page: https://bugsly.dev/solutions/switch-from-sentry-without-rewriting. Last updated 2026-11-13. All solutions: https://bugsly.dev/solutions (list as JSON: https://bugsly.dev/solutions.json).

## Why it happens

Your instrumentation is the Sentry SDK in your code: init calls, captured exceptions, tags, breadcrumbs and release names. What the SDK does with an event is decided by one value, the DSN, which holds the key, host and project of the destination. The Sentry options documentation states that the DSN tells the SDK where to send events and that without one it sends nothing (docs.sentry.io, read 2026-11-13). Any server that implements the same ingest protocol can therefore receive them.

That makes the code the easy part of a migration. The work is everything that lives in the server: alert rules, ownership rules, integrations, release and source map uploads, and the history of past issues. These are the items teams forget, and discovering one after cutover is how a silent gap appears: no alert fires for a class of errors because the old rule was never recreated.

The risk to manage is therefore not whether events arrive but whether you would notice a problem. A migration done in a deliberate order, with both destinations running briefly and a way back, keeps that risk small.

## How to switch trackers by changing configuration, not code

1. **Inventory what you use.** List the SDK features and server features that matter: error capture, tracing and performance, session replay, profiling, release health, cron check-ins, user feedback, source maps, and which alert rules and integrations your team relies on. Mark each as required, nice to have or unused. This list is what you check the new tool against, and it exposes gaps before you commit.
2. **Create the new project and note its DSN.** Create a project in the new tracker, one per Sentry project, and copy its DSN. Keep the old DSN in your configuration as well, stored in an environment variable rather than hard-coded, so that either can be selected without a code change.

```
# .env
SENTRY_DSN_OLD=https://<key>@o<orgId>.ingest.sentry.io/<projectId>
SENTRY_DSN_NEW=https://<public_key>@bugsly.dev/<project_id>
```

3. **Run both destinations in parallel for a short period.** The simplest overlap is by environment: send staging and one low-risk service to the new DSN while production stays on the old one. To send one app's events to both, the Sentry docs describe creating separate clients with their own DSNs, but they also say multiple clients are not recommended in general and can cause unexpected behavior, so use it only for a short overlap and test it (docs.sentry.io, read 2026-11-13). Tag releases the same way in both so you can compare counts.

```
// short overlap only: a second client with its own DSN
import { BrowserClient, defaultStackParser, makeFetchTransport, Scope } from "@sentry/browser";

const second = new BrowserClient({
  dsn: process.env.SENTRY_DSN_NEW,
  transport: makeFetchTransport,
  stackParser: defaultStackParser,
  integrations: [],
});
const scope = new Scope();
scope.setClient(second);
second.init();
// capture explicitly: scope.captureException(err)
```

4. **Swap the DSN.** Once the new tracker shows what you expect for the overlap, change the value passed to init to the new DSN and deploy. Nothing else in the SDK setup needs to change, because the same options, such as release, environment and beforeSend, are read by the same SDK.

```
Sentry.init({
  dsn: process.env.SENTRY_DSN_NEW,
  release: process.env.GIT_SHA,
  environment: "production",
});
```

5. **Recreate alerts and re-point source map uploads.** Rebuild the alert rules from your inventory in the new tool, and check whether it offers an importer. For source maps, sentry-cli reads its target from environment variables, so change them in CI and keep the same commands. Upload before the deploy goes live and use the same release string the SDK reports.

```
export SENTRY_URL=https://bugsly.dev
export SENTRY_AUTH_TOKEN=<new token>
export SENTRY_ORG=<org>
export SENTRY_PROJECT=<project>

sentry-cli sourcemaps inject ./dist
sentry-cli sourcemaps upload --release "<version>" ./dist
```

6. **Verify with a deliberate error, and keep a rollback.** Throw a known error in the new environment and confirm it arrives, shows original file names and lines, carries the release, and fires the alert in the right channel. Keep the old project and DSN for a few weeks and note the exact value to revert, so a bad cutover is undone by one configuration change.

```
// trigger from a test route or console
throw new Error("migration-check " + new Date().toISOString());
```


What moves by configuration and what you rebuild

| Item | Moves by changing the DSN? | What to do |
| --- | --- | --- |
| Error capture, tags, breadcrumbs, release | Yes | Keep the SDK code as is |
| Performance, replays, check-ins | Yes, if the destination ingests them | Confirm in your inventory |
| Alert rules | No | Recreate, or use an importer if offered |
| Source maps | No | Re-upload with sentry-cli pointed at the new host |
| Integrations | No | Reconnect each, and check for gaps |
| Past issue history | No | Assume the new project starts fresh unless the tool says otherwise |

Written from the SDK behavior in the Sentry options and multiple-instances documentation (docs.sentry.io, read 2026-11-13). No claims are made about Sentry's export features.

## When to use Bugsly

Bugsly accepts the Sentry event protocol, so the DSN swap above works for browser, Node, Python, Django, FastAPI, Rails, Go, Java, PHP and Flutter SDKs. You can also use Project Settings -> Import from Sentry: with a read-scope Sentry auth token, used once and never stored, it creates projects by slug and the alert rules that map cleanly, and lists the rules it cannot map. The full walk-through is at /migrate-from-sentry.

The honest gaps: Bugsly does not import issue history, so a new project starts fresh. It has no SSO, no Jira, Linear or PagerDuty actions and no native minidump ingestion. Apple dSYMs are supported, but Swift symbol names stay mangled. Alerts go to email, Slack, Telegram or webhooks.

## When Bugsly is not the right answer

If your team depends on SSO, on opening Jira or Linear tickets or paging via PagerDuty straight from an issue, or on native crash dumps, do not move to Bugsly for those workloads. Choose a tracker that has them, and run the same inventory and parallel test against it.

If you need to preserve years of issue history for audit reasons, keep the old project readable and do not treat the new one as a replacement for it.

## Ask your AI assistant to do it

Connect the Bugsly MCP server (https://bugsly.dev/mcp), then paste:

> Assign to Bugsly: use list_projects to confirm the migrated projects exist, then list_issues on each and report which ones received events since my cutover, and use list_monitors to show the cron monitors I recreated. Do not resolve or ignore anything; show me what you found so I can approve the next step.

## Frequently asked questions

### Do I need to change my code to switch from Sentry?

Usually only the DSN value, if the new tracker accepts the Sentry protocol. Alert rules, source map uploads and integrations are configured on the server side and need rebuilding.

### Can I send events to two trackers at once?

Yes, with separate clients and DSNs, but the Sentry documentation says multiple clients are not recommended in general. Use it for a short overlap, or split by environment.

### Will my old Sentry issues appear in the new tracker?

Not by default. With Bugsly specifically, history from other tools cannot be imported and a new project starts fresh, so keep the old project available for reference.

### How do I keep source maps working after switching?

Point sentry-cli at the new host through SENTRY_URL and the new auth token, and upload with the same release string the SDK reports.

### How do I roll back if something is wrong?

Keep both DSNs in environment variables. Reverting is changing the value back and redeploying.

## Sources

- Sentry docs: Options for Browser JavaScript (read 2026-11-13): https://docs.sentry.io/platforms/javascript/configuration/options/
- Sentry docs: Multiple Sentry Instances (read 2026-11-13): https://docs.sentry.io/platforms/javascript/best-practices/multiple-sentry-instances/

## Related

- Migrate from Sentry: https://bugsly.dev/migrate-from-sentry
- Sentry alternative comparison: https://bugsly.dev/sentry-alternative
- Compare with Sentry: https://bugsly.dev/vs/sentry
- Minified stack traces and source maps: https://bugsly.dev/solutions/minified-stack-traces-source-maps