How to Migrate from Sentry to jentry (Keep Your Code & SDK)

This guide walks you through how to migrate from Sentry to jentry. Because jentry speaks the same envelope protocol as Sentry and accepts a repointed Sentry DSN, the migration is real-world boring: you point your existing Sentry SDK at the DSN from your jentry project, and your error and performance data starts flowing into jentry with zero application code changes.

Why migration is a one-line change

jentry is wire-compatible with the Sentry SDKs. It implements the same ingest endpoints (the envelope and store APIs), honors the same DSN format, and even returns the same rate-limit headers. The official Sentry SDKs — for JavaScript, Python, Ruby, Go, PHP, Java, .NET, and the rest — don't know or care that they're talking to jentry instead of Sentry. They just POST envelopes to whatever host is in the DSN.

A Sentry DSN encodes three things: a public key, a host, and a numeric project ID. The standard migration keeps your Sentry SDK untouched and swaps in the DSN from the jentry project you create — the key and project ID become jentry's, the SDK stays the same. (If you instead import your Sentry projects into jentry so it recognizes your original keys, then you just use your jentry DSN — see Step 1.)

The one-step path: import your Sentry projects

jentry can import your Sentry projects for you — recreating each one with the same project id and DSN key it has in Sentry. Once imported, your apps' existing DSNs work against jentry with only the host changed. The import is read-only: it reads your projects and keys from Sentry and never changes anything there.

1. 1In Sentry, create an auth token: Settings → Auth Tokens → Create New Token, with the project:read scope. Copy it.
2. 2In jentry, open Import from Sentry — the button on your Projects page (or the link on the new-project screen).
3. 3Enter your Sentry URL (https://sentry.io, or your self-hosted URL), your Sentry organization slug, and the auth token, then click Import projects from Sentry. jentry recreates each project here, preserving its project id and DSN key(s). The token is used once and never stored.
4. 4In each app, change only the DSN host to jentry.app — keep the same key and project id (see Step 2). Redeploy. Done.

Prerequisites

• A jentry account (sign up free at jentry.app — no credit card, 5k events/mo on the Free tier).
• Your existing app already instrumented with an official Sentry SDK. If it works with Sentry today, it works with jentry.
• Access to wherever your DSN lives: an environment variable (e.g. SENTRY_DSN), your SDK init() call, or your secrets manager.
• Permission to redeploy (or restart) the service so it picks up the new DSN.
• Optional but recommended: your source maps / debug symbols upload step, so stack traces stay readable after the cutover.

Step 1 — Create a project in jentry

Log in to jentry and create a project (or use the one created during onboarding). jentry assigns it a project ID and a public key, and gives you a ready-made jentry DSN. You have two valid paths from here:

• Use jentry's native DSN — copy the DSN jentry shows you and drop it into your app. Simplest for new projects.
• Repoint your existing Sentry DSN — keep your current key and project ID and just swap the host to jentry.app. Best when you don't want to touch secrets in many places, or when the same DSN is baked into builds. jentry accepts the repointed DSN as long as the key matches the project's public key.

Step 2 — Point your SDK at the jentry DSN

Replace your DSN value with the one from your jentry project. This is the only required config change — your SDK code stays exactly as-is. (If you imported your Sentry projects into jentry, only the host differs, as shown below.)

# Before — pointing at Sentry
-SENTRY_DSN=https://<key>@o123.ingest.sentry.io/456

# After — pointing at jentry (your jentry DSN, no SDK change)
+SENTRY_DSN=https://<key>@jentry.app/456

If your DSN is hardcoded in your SDK init instead of an env var, it's the same edit — only the host string changes:

// JavaScript / Node — unmodified @sentry/node, just a new host
import * as Sentry from '@sentry/node';

Sentry.init({
  // dsn: 'https://<key>@o123.ingest.sentry.io/456',  // old: Sentry
  dsn: 'https://<key>@jentry.app/456',                 // new: jentry
  tracesSampleRate: 1.0,
});

# Python — unmodified sentry-sdk, just a new host
import sentry_sdk

sentry_sdk.init(
    # dsn="https://<key>@o123.ingest.sentry.io/456",  # old: Sentry
    dsn="https://<key>@jentry.app/456",                # new: jentry
    traces_sample_rate=1.0,
)

No new package, no SDK version bump, no API changes. Keep everything else exactly as it is.

Step 3 — Redeploy and trigger a test event

Redeploy or restart the service so it loads the new DSN, then force one event so you have something to look for:

// Throw a deliberate test error after init
Sentry.captureException(new Error('jentry migration smoke test'));

# Python equivalent
import sentry_sdk
sentry_sdk.capture_message("jentry migration smoke test")

Step 4 — Verify events are arriving

Confirm jentry is receiving data before you decommission anything on the Sentry side:

1. 1Open your project's Issues view in jentry — your test error should appear within a few seconds.
2. 2Click into the issue and confirm the full stack trace renders. If you upload source maps / debug symbols, check that frames are de-minified.
3. 3Generate some normal traffic and confirm performance transactions show up (p50/p95/Apdex) under Performance.
4. 4Check that releases and environment tags are tagged correctly if you set release/environment in your SDK.

Step 5 — Run jentry and Sentry in parallel during cutover (recommended)

A single DSN sends events to exactly one host, so the SDK can't natively dual-write. For a safe, reversible cutover you have a few honest options:

• Canary by service/instance: point one service (or a fraction of your fleet via a feature flag on the DSN env var) at jentry, leave the rest on Sentry. Compare what lands in each for a day or two, then roll the rest over.
• Canary by environment: send staging to jentry first, keep production on Sentry until you're confident, then flip production.
• Time-boxed cutover: flip everything to jentry but keep your Sentry project active (don't delete it) for a week so you can roll back instantly if needed.

All three keep your Sentry project untouched and reversible. There's no lock-in — your SDK is the same either way.

Step 6 — Importing your projects and settings

Set up the equivalents of your Sentry configuration in jentry. Most of this is fast because the concepts map one-to-one:

• Projects & teams: recreate your projects in jentry and assign teams (RBAC is supported). Connect GitHub/GitLab/Google via OAuth.
• Alerts: rebuild your alert rules (email, Slack, webhook). The notification model mirrors Sentry's, so issue-alert and metric-alert style rules carry over conceptually.
• Releases & suspect commits: keep your existing release tagging in the SDK and wire up your repo integration so jentry can attribute suspect commits.
• Crons & uptime: re-add your cron monitors and uptime checks; jentry supports both.
• Source maps / debug files: point your existing upload step at jentry so symbolication keeps working.

What does not auto-migrate: historical data

Be clear-eyed about this. Migrating the DSN moves new events going forward — it does not copy your history out of Sentry. Specifically, the following stays in Sentry and does not transfer:

This is normal for any monitoring migration and not specific to jentry. Because there's no painless bulk export of raw Sentry events, the pragmatic approach is: cut over new traffic to jentry, and keep your Sentry account around (even downgraded) as a historical archive until the data ages out of relevance.

Rollback: it's instant

Because the only thing you changed was the DSN host, rolling back is the reverse of Step 2 — restore the original host and redeploy:

# Roll back to Sentry — just restore the original host
-SENTRY_DSN=https://<key>@jentry.app/456
+SENTRY_DSN=https://<key>@o123.ingest.sentry.io/456

As long as you didn't delete your Sentry project, events resume flowing to Sentry immediately. This is exactly why we recommend keeping Sentry active during the cutover window — your safety net costs nothing.

Troubleshooting

No events appear in jentry

• Check the host: the most common cause is a typo — confirm it's exactly jentry.app and that the scheme is https.
• Stale build: make sure the running build actually has the new DSN. CI/CD often bakes the DSN into the image at build time; a redeploy of an old image keeps the old host.
• Key / project-ID mismatch: if you repointed your Sentry DSN, the public key in the DSN must match the jentry project's public key, and the project ID must match. Otherwise jentry rejects the request with an auth error.
• SDK initialized too early/late: confirm init() runs before the code that errors, and that you didn't accidentally leave dsn empty (an empty DSN disables the SDK silently).

Events arrive but stack traces are minified

• Source maps / debug files aren't being uploaded to jentry. Repoint your existing upload step (the same one you used for Sentry) at jentry and confirm the release name in the SDK matches the release you uploaded artifacts for.

Browser SDK events are blocked

• jentry's ingest endpoints send permissive CORS headers for browser SDKs, so this is rarely a CORS issue. If a corporate proxy or content-blocker is the culprit, you can use the SDK's tunnel option to route events through your own backend — the same option you'd use with Sentry.

Getting 429s / rate-limit responses

• jentry enforces per-project rate limits and a monthly event quota per plan (Free 5k, Team 100k, Business 1M). It returns standard Retry-After and X-Sentry-Rate-Limits headers, which the SDK respects automatically. If you're hitting limits, either add sampling (tracesSampleRate / sample rates) or move up a plan.

Is jentry right for your migration?

Honest positioning: jentry is the lean, affordable, fast alternative for teams who found self-hosted Sentry too heavy (its on-prem stack runs ~50 containers — ClickHouse, Kafka, Snuba, Relay — and wants 16GB+ RAM) or hosted Sentry too pricey. jentry is not trying to out-scale Sentry's SaaS at billions of events per month. If you're a normal team that wants error tracking, performance, releases, alerts, crons, uptime, replays, and dashboards without the cost or the ops burden, the one-line migration makes it nearly free to try and trivial to roll back.