How to migrate from Sentry to ForgeOps

You don't have to choose all-or-nothing on day one. Both SDKs can run side by side in the same app for as long as you want to compare the two in production before removing Sentry entirely; see Switching to ForgeOps if you'd rather approach it that way.

Before you migrate

Review what you actually have configured in Sentry first, so nothing gets lost in the switch:

• Which projects and environments you're tracking
• Each project's DSN and where it's set (env vars, initializers, CI config)
• Alert rules: what triggers them, and who they notify
• Integrations: Slack, PagerDuty, GitHub, Jira, anything wired to Sentry today
• How releases get tagged, if you're using Sentry's release tracking
• Your actual retention requirements, so you pick the right ForgeOps plan for it
• Any issue history you need to keep a record of; see "What happens to your data" below

Install ForgeOps

For a Rails app:

gem "forge_ops_tracker"

ForgeOpsTracker.configure do |config|
  config.dsn = ENV.fetch("FORGE_OPS_DSN")
end

This hooks Rails.error directly, the same reporter API Rails itself uses internally, so unhandled exceptions across requests, background jobs, and console sessions start reporting with no further wiring. Full install steps, including Sidekiq/Solid Queue and every other language, are on ForgeOps' language pages.

Explicitly-rescued exceptions

Anywhere you're calling Sentry directly for an exception you've already rescued, swap it for Rails.error.report:

begin
  risky_operation
rescue StandardError => e
  Sentry.capture_exception(e)
end

begin
  risky_operation
rescue StandardError => e
  Rails.error.report(e, handled: true)
end

What happens to your data

Existing Sentry issue history

Stays in Sentry; there's no automatic import. You're starting ForgeOps' own history for a project fresh from the day you switch, the same way any error tracker's history begins wherever you turn it on.

New errors, going forward

Captured, grouped, and alertable in ForgeOps from the moment the DSN above is set and the app restarts.

Releases and deploys

Set config.release to the same identifier your deploy process already produces (a commit SHA, a slug, whatever you use today) and each release gets its own row with a real crash-free rate, correlated with the errors it introduced.

Performance/tracing data

A separate opt-in from error tracking, same as in Sentry; see Application Health for what it needs and which plans include it.

Alert rules and integrations

Not imported automatically; recreate the ones you noted above under Notification Rules once your first project exists. Slack, Teams, and generic webhooks are available on every paid plan; see Alerting.