Migrate from Sentry to Moneat: what changes and what doesn’t

You can move supported Sentry telemetry to Moneat without replacing your SDK. Start by changing the DSN for one service, then verify that errors and any sampled profiles arrive with the context you need.

A production migration also needs checks for source maps, alerts, releases, traces, replays, and any unsupported features. This guide covers those steps, what happens to historical data, and how to switch a service back.

What changes

Moneat accepts Sentry protocol envelopes. Your application keeps its Sentry SDK, while the DSN changes the service receiving those envelopes.

Area	Migration decision
SDK package and capture calls	Keep them for supported signals.
DSN	Replace it with the generated Moneat service DSN.
Alerts and notification routes	Recreate and test them in Moneat.
Source maps and releases	Verify the upload credentials, destination, release, and distribution values.
Historical events	They are not imported; preserve Sentry access or export what you need.
Profiling	Keep Sentry SDK profiling enabled with the matching profiling package and `profileSessionSampleRate` / `profileLifecycle` (or the platform equivalent), then verify profiles under Profiles → Sentry SDK.

Supported envelope data includes common error context such as stack traces, messages, breadcrumbs, tags, user context, environments, releases, and Sentry SDK profiles. Traces and session replays also require their own sampling and validation. A compatible transport is not a promise that every Sentry product behaves the same way in Moneat.

Create a service and copy its DSN

Create a Moneat account, then open Setup → Services & SDKs and create the destination service. Copy the generated DSN from its Sentry-compatible source settings.

The generated DSN is authoritative. It contains a public key and service identifier, so do not copy a host from an old article or assemble the path manually.

Change one service first

Keep the initialization options that you have already tested. Change only the environment variable that supplies the DSN:

JavaScript

import * as Sentry from "@sentry/node";
import { nodeProfilingIntegration } from "@sentry/profiling-node";

Sentry.init({
  // Before: the value was the DSN generated by Sentry.
  // After: set MONEAT_DSN to the DSN generated in Moneat service settings.
  dsn: process.env.MONEAT_DSN,
  environment: process.env.NODE_ENV,
  release: process.env.APP_RELEASE,
  integrations: [nodeProfilingIntegration()],
  tracesSampleRate: 0.1,
  profileSessionSampleRate: 0.1,
  profileLifecycle: "trace",
});

For Node.js profiling, use @sentry/node and @sentry/profiling-node at version 10.70.0 or later, with both packages at exactly the same version. If the service already has this package, keep its existing version pairing when it meets that minimum.

Deploy that change to one low-risk service or environment. Do not change every DSN in the same release until you understand the result.

Validate the event, not just delivery

Trigger a controlled test error and confirm:

the event appears under the expected Moneat service and environment;
the stack trace identifies the application frame that failed;
release, tags, user context, and breadcrumbs are present as expected;
source maps resolve minified browser frames when applicable;
trace and replay links appear only when those signals were captured; and
after enough traced workload (or temporarily setting tracesSampleRate and profileSessionSampleRate to 1.0 in the test environment), check Profiles → Sentry SDK for a sampled profile; and
the corresponding Moneat alert reaches the intended destination.

An HTTP success from the SDK proves only that the payload was accepted. It does not prove symbol resolution, grouping, sampling, alert delivery, or access controls.

Check source maps and releases

If your build uploads source maps, keep the release identifier consistent between the SDK event and the uploaded artifact. Review the release and artifact setup, then run a production-like build and trigger a mapped error.

Do not assume that existing Sentry CLI credentials or organization settings apply to Moneat. Verify the destination and authentication used by the upload job before switching browser traffic.

Recreate alert behavior

Inventory the Sentry rules that currently matter: new issues, regressions, error-rate thresholds, release health, ownership, and notification integrations. Create the Moneat equivalents and send a test event through each important path.

Check the object the recipient sees, the link it opens, grouping and deduplication, and any escalation that follows. Keep the old rule enabled until the new one has demonstrated the required behavior.

Historical data and parallel operation

Moneat does not import historical Sentry events. Keep Sentry available for the history your team still needs, subject to your existing retention and contract.

For a staged migration, move services one at a time. If you require true dual delivery from one service, use a transport or telemetry pipeline that is designed and tested for multiple destinations. Do not copy raw events to a DSN with fetch() from beforeSend; a DSN is not a generic JSON endpoint, and that approach does not mirror Sentry envelopes, attachments, traces, or replays correctly.

Roll back by service

Keep the old DSN available in deployment configuration during the validation window. To return one service to Sentry, restore its previous DSN and redeploy. Alert rules, source-map uploads, and any separate telemetry pipelines may need to be returned independently.

The migration is complete when the required telemetry is useful, the alerts work, and the team has accepted the feature differences—not merely when the first event arrives.

Start with one service | Sentry-compatible SDK setup | Current pricing