Migrate from Sentry to Bugsly

Bugsly accepts Sentry SDK envelopes, so moving over is mostly a DSN swap. A read-only importer creates your projects and the alert rules that map cleanly, and tells you about the ones that do not. Your event history stays in Sentry; Bugsly starts fresh from the moment you swap the DSN.

Step by step

  1. 1

    Import your projects and alert rules

    In Bugsly, open a project's Settings and use Import from Sentry. Paste a Sentry auth token with read access to your organization and projects, plus your Sentry organization slug. Bugsly creates a project for each Sentry project (matched by slug, so re-running never duplicates) and the alert rules that map cleanly. The token is used for that one request and is never stored. You can also skip the importer and create projects by hand.

  2. 2

    Swap the DSN in your SDK init

    Copy each new project's DSN from the import result (or from project settings) and replace the old Sentry DSN. Nothing else in the init call changes.

    Sentry.init({
      dsn: "https://<public_key>@bugsly.dev/<project_id>",
    });
  3. 3

    Keep your existing Sentry SDK

    Bugsly accepts Sentry SDK envelopes, so you do not have to replace @sentry/* packages. Deploy the DSN change and trigger a test error to confirm it appears in Bugsly. Test every SDK feature you rely on before moving production traffic.

  4. 4

    Upload source maps with sentry-cli

    Create an organization auth token under Settings, Auth tokens, then point sentry-cli at Bugsly. Releases, commits, deploys, source maps, ProGuard mappings and Apple dSYMs use the same sentry-cli commands as before.

    export SENTRY_URL=https://bugsly.dev
    export SENTRY_AUTH_TOKEN=<bugsly auth token>
    export SENTRY_ORG=<your bugsly org slug>
    export SENTRY_PROJECT=<your bugsly project slug>
    sentry-cli sourcemaps inject ./dist
    sentry-cli sourcemaps upload --release "$VERSION" ./dist
  5. 5

    Recreate the alerts that did not import

    The importer reports every rule it skipped and why. Rules with issue filters, non-email actions or unsupported triggers need to be recreated in Bugsly alert settings, where email, Slack, Telegram and webhook destinations are available.

What is and is not imported

  • Imported: project name, slug and platform, and a fresh DSN for each new project.
  • Imported alert rules: new-issue, regression and event-frequency triggers (windows from 1 minute to 1 day) with at most an environment restriction, delivered by email to the person running the import.
  • Not imported: issues, events and other history, issue filters, Slack/PagerDuty/Jira actions, team or member notification targets, members, and settings.
  • The importer only reads from Sentry. It runs against sentry.io or a self-hosted Sentry on a public address, and it never stores your token.

What works, and what does not

Checked against Bugsly's code, not marketing copy. If a gap is a blocker for you, stay on Sentry for that part. Pricing is on the pricing page.

FeatureBugslyNotes
Sentry SDK envelopes (errors, transactions, spans)Change the DSN; keep the SDK.
Issue grouping and AI error analysis
Performance, logs, profiling, session replay
User feedback and cron monitorsUptime checks are included too.
Release health (crash-free rates)
Releases, commits, deploys via sentry-cliA subset of /api/0/ that sentry-cli uses.
JavaScript source maps via sentry-cli
Android ProGuard / R8 mappings
Apple dSYM symbolicationSwift symbol names stay mangled.
Ownership rules and inbound filters
Alert actions: email, Slack, Telegram, webhook
GitHub integration (suspect commits)
Importing history (issues, events)History stays in Sentry. Bugsly starts fresh from the DSN swap.
SSO / SAML
Jira, Linear and PagerDuty actions
Minidump / native crash ingestion
Swift demangling