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 for as long as you need the history, and run both destinations in parallel during the transition.

Does Parsemend keep traces, logs and cron monitors?

Yes. Transactions and spans, log records and cron check-ins are stored, and a check-in creates its cron monitor automatically. Session, replay, profile and attachment items are accepted and dropped, so an SDK that sends them keeps working, but nothing from them is kept.

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 is an error tracker your coding agent can read. It receives events over Sentry's ingest protocol: the envelope endpoint, the legacy store endpoint, and all three of the DSN authentication forms the SDKs use. That is why the migration is small.

Change one line

Create a project in Parsemend and copy its DSN from Settings → Projects → your project → Keys. 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) for events, transactions, logs and check-ins, and with @sentry/node 10.64.0 for events and 10.65.0 for the rest. 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

Errors and grouping. Breadcrumbs, tags, environments and releases are stored and indexed. Custom fingerprints, including {{ default }} expansion, keep your grouping rules behaving.
Traces. transaction items are stored as transactions and spans, sampled per project, and an issue lists the traces its events belong to. The trace view is a list and a nested span tree, not a waterfall.
Logs. log items are stored with level, body and attributes, searchable by body and linked to their trace when it exists.
Cron monitors. A check_in item with a monitor_config creates its monitor. Missed, timed-out and failed check-ins open regular issues, and an ok check-in resolves them.
Rate-limit handling. Parsemend answers with 429, Retry-After and X-Sentry-Rate-Limits, which your SDK already knows how to back off from.
Releases and source maps. Uploads use the sentry-cli protocol, and JS source maps are resolved by debug ID before grouping. The protocol is covered by tests, but we have not recorded a run of the real sentry-cli binary yet, so check your upload step during the parallel run.

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.

Session replay, profiling, release health and attachments. session, replay, profile and attachment items are accepted and dropped rather than rejected, so your SDK will not start erroring, but nothing from them is kept. That also means no crash-free rates and no crash-free-rate alerts. Native symbolication (dSYM, PDB, ELF) is not supported either. If your team relies on any of these, migrating means losing them, and you should weigh that before changing the DSN.

Alert rules and dashboards. Rules do not transfer, and a new Parsemend project starts with no alert rule at all. Create one (email, Slack, Discord or a signed webhook) before you switch, or nothing will notify anyone. Instead of query dashboards, each project gets a fixed Health page: error count, failure rate and p95.

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 connect your agent

On the Developer plan (€9 a month, 50% off at launch), the issues you just moved can be read by the coding agent you already use:

npm install -g @parsemend/cli
parsemend login
claude mcp add parsemend -- parsemend mcp

For Codex, the last line is codex mcp add parsemend -- parsemend mcp; Cursor takes the standard mcpServers block in ~/.cursor/mcp.json. The agent calls list_issues and get_issue_context for the stack trace, events, trace and logs, fixes the code in your checkout with its own model, and asks before post_back sends the diff to the issue. Parsemend needs no GitHub access and asks for no AI keys. The details are on bring your own agent and the MCP server.