What stays the same
- Sentry SDK packages and init calls
- Error capture calls, breadcrumbs, and traces
- Release, environment, and user context fields
- The issue, release, and alert flow your team already knows
Migration from Sentry
Migrate from Sentry without re-instrumenting your apps.
If you already ship Sentry SDKs, urgentry lets you keep that code. Install urgentry, swap the DSN, send a real event, and validate the workflows your team depends on before you move production traffic.
Need shared infrastructure on day one? Start on self-hosted mode instead.
218/218
source-scanned Sentry operations covered
2.2x more
same-host self-hosted throughput
21x less
peak memory than Sentry self-hosted
29x faster
query p95 than Sentry self-hosted
The actual code change
Same SDK. New host.
Most migration pages hide the important part under six paragraphs. This is the part that matters first. If the DSN swap is real, the code should look boring.
# before dsn="https://your-key@o123.ingest.sentry.io/456"
# after dsn="https://your-key@your-host.com/1"
What you validate before cutover
- The first event lands and groups the way you expect
- Releases, source maps, and alert rules still make sense
- Discover, logs, replay, or profiles cover the paths you use
- The operator shape fits the team that has to run it
Proof before cutover
Read the claims like an engineer.
urgentry publishes the compatibility boundary, the same-host benchmark method, and the docs you need to test the switch without guessing.
Compatibility boundary
218/218
source-scanned Sentry operations covered
The public claim stays narrower than "mostly compatible" copy on purpose. Read the compatibility docs before you cut over.
Same-host benchmark line
Stable throughput
2,200 eps
Peak memory
391.8 MB
Query p95
48.82 ms
What that means against Sentry
Throughput
2.2x more
Peak memory
21x less
Query p95
29x faster
| Metric | urgentry self-hosted | Sentry self-hosted |
|---|---|---|
| Stable throughput | 2,200 eps | 1,000 eps |
| Ingest p95 | 0.71 ms | 0.62 ms |
| Query p95 | 48.82 ms | 1400.81 ms |
| Peak memory | 391.8 MB | 8191.7 MB |
Sentry migration checklist
How to migrate from Sentry
Keep the order simple. Prove the small thing first, then widen the blast radius when the boring checks pass.
-
01
Install urgentry in the right shape
Start with Tiny mode if you want the fastest path to a working DSN. Use self-hosted mode if shared services are already the requirement.
-
02
Point one existing Sentry SDK at the new DSN
Use the same SDK package you already ship. The goal is one live event and one honest check, not a big-bang rewrite. If you need language examples, use SDK setup.
-
03
Validate the workflows your team actually uses
Check issues, releases, alerts, Discover, logs, replay, profiles, and the operator flows that matter to your team. Skip the fantasy checklist and test the paths you would miss on a bad day.
-
04
Move production traffic when your own bar says yes
Cut over the production DSN only after the validation bar is good enough for you. Then keep iterating on the operator path with the docs for operations and support.
Sentry migration FAQ
Questions teams ask before the cutover
Can I keep my existing Sentry SDKs?
Yes. urgentry is built so the migration starts with a DSN swap, not a rewrite. Keep the SDKs, point them at urgentry, and validate the first live event.
Do I need to re-instrument my apps?
No. The point of the migration path is to avoid touching every service just to test the platform. The SDK and instrumentation stay put while you change the DSN.
Should I start with Tiny mode or self-hosted mode?
Start with Tiny mode when you want the fastest proof. Start with self-hosted mode when you already know the team needs split roles and shared infrastructure from day one.
What should I validate before moving production?
Check the paths that would hurt if they broke: first event ingest, grouping, releases, alerts, Discover, logs, replay, profiles, and the operator tasks your team actually has to run.
Does urgentry claim full Sentry parity?
No. The public claim is narrower and more useful: compatibility-first on the common ingest and triage path, with public docs and benchmarks so you can test the workflows you care about yourself.