Do I need to change my code to migrate from Sentry?

No. Parsemend implements Sentry's ingest protocol, so the official Sentry SDK stays installed and initialised as it is. Only the DSN value changes.

Will my historical Sentry issues move to Parsemend?

No. Parsemend starts grouping from the first event it receives. Keep the Sentry project open in read-only mode for as long as you need the history, and run both destinations in parallel during the transition.

Can I send events to Sentry and Parsemend at the same time?

Yes. Initialise a second Sentry client with the Parsemend DSN, or fan the events out with a relay. Sending to both is the safest way to compare grouping before you commit.

How to migrate from Sentry to Parsemend

Parsemend implements Sentry's ingest protocol. That is not a compatibility layer bolted on at the edges — it is the envelope endpoint, the legacy store endpoint, and all three of the DSN authentication forms the SDKs use. So the migration is small.

Change one line

Your DSN looks like this today:

SENTRY_DSN=https://9f2c1a7b4e6d8054a3f1c9b27e0d5a83@o4507.ingest.sentry.io/4507123

Point it at your Parsemend project:

SENTRY_DSN=https://9f2c1a7b4e6d8054a3f1c9b27e0d5a83@ingest.parsemend.com/4507123

Redeploy. The SDK stays installed, Sentry.init() stays where it is, and every event you already emit now lands in Parsemend.

We have verified this end to end with sentry/sentry 4.29.0 (PHP) and @sentry/node 10.64.0. Other Sentry SDKs speak the same wire protocol, but those two are the ones we have actually run, and we would rather say so than imply a matrix we have not tested.

What carries over

Breadcrumbs — normalized and stored with the event.
Tags, environments and releases — indexed as key/value pairs, so you can filter without a full-text scan.
Custom fingerprints — including {{ default }} expansion, so your existing grouping rules keep behaving.
Rate-limit handling — Parsemend answers with 429, Retry-After and X-Sentry-Rate-Limits, which your SDK already knows how to back off from.

Envelope item types Parsemend does not yet store — transactions, logs, check-ins — are accepted and dropped rather than rejected. Your SDK will not start erroring because it sent something we do not keep.

What does not carry over

Historical issues. Parsemend starts grouping from the first event it sees. There is no import, and building one would produce grouping that disagrees with Sentry's anyway.

Tracing, session replay, profiling, logs, cron monitoring. Parsemend has none of these. If your team relies on them, migrating means losing them. That is a real cost and you should weigh it before changing the DSN.

Run both for a release cycle

The low-risk path is to send events to both destinations and compare. Initialise a second client with the Parsemend DSN:

import * as Sentry from "@sentry/node";

Sentry.init({ dsn: process.env.SENTRY_DSN });

const parsemend = new Sentry.NodeClient({
  dsn: process.env.PARSEMEND_DSN,
  transport: Sentry.makeNodeTransport,
  stackParser: Sentry.defaultStackParser,
  integrations: Sentry.getDefaultIntegrations({}),
});

Leave it for a release. Compare issue counts and grouping. When Parsemend's issue list stops surprising you, drop the Sentry client.

Then turn on the part you came for

Migration is not the point; it is the toll. The point is that once your errors are in Parsemend, an agent can pick one up, state its root cause, write a patch, and open a draft pull request — running wherever you tell it to, against whichever model you trust. Start with the four fix modes and pick the one whose privacy story you can defend to your security team.