Move from Sentry without changing client DSNs

Metric can accept an existing Sentry DSN and map it to a Metric project. Installed applications keep their current SDK configuration. The old public key and project ID may differ from the keys and IDs generated by Metric.

Keep the same client-facing address and port

For a direct replacement, Metric must accept requests on the same public IP address and port that clients previously used for Sentry. A correct public key, project ID and DSN mapping do not redirect network traffic. If Metric is exposed on another address or port, existing clients will continue sending to the old endpoint.

For example, if the old DSN is:

https://0123456789abcdef0123456789abcdef@sentry.example.com:8443/123

clients continue connecting to sentry.example.com:8443. Keep that hostname, its client-facing IP address, port 8443, HTTPS and a valid certificate for sentry.example.com. Without an explicit port, HTTPS uses 443 and HTTP uses 80. Preserve any path prefix, such as /sentry/, as well.

When using a reverse proxy or load balancer, preserve its public address and port and change its ingest upstream to Metric. Metric's internal container IP and port can differ. Forward requests with their bodies, query strings and authentication headers; strip an existing path prefix at the proxy before forwarding to Metric's /api/{project_id}/envelope/, /api/{project_id}/store/ and /api/{project_id}/minidump/ routes. Keep the old external project ID in these paths. Do not replace it with Metric's internal ID.

If your DSN uses a hostname, changing its DNS record is another possible cutover, but old DNS caches may continue reaching the old IP. Keeping the original public endpoint avoids that dependency. A DSN containing a literal IP cannot be moved through a DNS change. Applications with certificate pinning also need a compatible TLS termination setup.

You must control the existing endpoint. A DSN pointing directly to a Sentry-owned host such as *.ingest.sentry.io cannot be redirected by entering it in Metric. An already configured tunnel or proxy that you control can instead change its upstream.

Add the existing DSN

1. Create or select the destination project in Metric.
2. Open Settings → Project → DSN keys with project administrator access.
3. Select Use an existing DSN.
4. Enter a label and paste the complete existing Sentry DSN, including its public key and project ID. Click Use DSN to save it.
5. Repeat for every active DSN used by installed clients. Several DSNs can feed the same Metric project.

The list displays the imported DSN. Connect an SDK also shows it, alongside any ordinary Metric DSNs. Metric retains the original external project ID, including IDs larger than its own internal project IDs. Legacy DSN passwords are discarded; they are not needed for ingestion.

An existing native key, including a disabled one, cannot be imported. A previously imported public key cannot be reassigned to another project. Each mapping uses a dedicated Metric key, so Disable on its row stops the imported DSN using the ordinary key revocation mechanism. Other keys continue working. Project policy, rate limits and deletion apply to imported DSNs too.

Switch traffic

1. Configure the destination project's data categories, privacy filters and limits. Check the SDK compatibility matrix against your installed SDK versions and the data they send.
2. Before changing production routing, test an unchanged client DSN against Metric through an isolated proxy or DNS override that preserves its hostname, port and TLS validation. Confirm that an event appears in the selected project.
3. Switch the existing proxy's ingest upstream, or replace Sentry with Metric on the same client-facing IP and port. Two services cannot listen on the same address and port simultaneously; a proxy makes the handover easier.
4. Check new events and rejected requests. Keep the old Sentry service available behind the proxy while validating, so you can restore the previous upstream.

This preserves client configuration; uninterrupted delivery still depends on the handover and SDK retry behavior. It does not copy historical Sentry data, alert settings, source maps or debug files. Upload artifacts needed by old application releases to Metric separately.

API and storage

Administrators can also use the ordinary project-key endpoint:

POST /api/v1/projects/42/keys
Content-Type: application/json

{
  "label": "Existing production clients",
  "existing_dsn": "https://0123456789abcdef0123456789abcdef@sentry.example.com:8443/123"
}

Use the same authenticated session/CSRF or scoped API-token requirements as other project-key commands. The response contains the internal dsn_key used for administration, including disabling the imported DSN. Listing project keys includes existing_dsn for imported keys.

Schema generation 21 adds the dsn_maps collection and its index automatically when upgrading from generation 20. Existing project, key and event documents are not rewritten. Do not edit MongoDB manually to create or change mappings.