Migrate from Sentry to GlitchTip: what the move involves
If your Sentry renewal, data residency requirement or lock-in concern is pushing you toward GlitchTip, the application code mostly stays as it is. The DSN changes, and the alert rules, projects, teams and integrations are rebuilt in GlitchTip by hand, because they do not carry over automatically. GlitchTip is compatible with Sentry client SDKs and its backend is MIT-licensed, and the Sentry SDKs themselves are open source, so the instrumentation you already ship keeps working. Confirm the exact SDK versions your services use against GlitchTip's current compatibility notes before you change anything in production.
Platform or security engineering usually owns the work, with an implementation partner if the team lacks capacity for deployment, hardening and backup. The main effort sits in the server side: standing up GlitchTip with PostgreSQL 14 or later, choosing between the single-service and separate web and worker layouts, and deciding whether Valkey or Redis 7 or later is needed. Inventory every Sentry project, each environment's DSN, and each alert routing path first, because those are where gaps usually appear. Ask your partner to scope the rebuild of alert rules and integrations as a separate deliverable so it is not lost in the cutover.
The main risks are silent loss of alerts and history that matters for audits or incident reviews. Run GlitchTip in parallel with Sentry for a period, sending events to both, and compare alert behavior for the same test errors before you retire the SaaS project. Decide up front which historical issues you need to keep, because GlitchTip will not inherit them, and agree the retention and access rules for the GlitchTip database in your own environment. Confirm each Sentry feature you depend on is covered by GlitchTip before you commit the cutover date.
Which Sentry capabilities map to GlitchTip, and which need rework
This table compares the Sentry features most teams rely on with what GlitchTip covers today, marking each as clean, needs rework or gap. Confirm every row against GlitchTip's documentation for the version you plan to run, because feature sets change between releases. Treat anything marked needs rework as work your team must plan and test before cutover.
| Sentry capability | GlitchTip status | What to do before cutover |
|---|---|---|
| Error and exception capture | Clean | Keep the Sentry SDKs and change each project DSN to the GlitchTip project DSN. Send a test exception from every service. |
| Log messages | Clean | Confirm that message-level events from your SDK configuration appear as expected in the GlitchTip issue list. |
| CSP violation reports | Clean | Update the report-uri or report-to endpoint in each Content Security Policy so browsers post to GlitchTip. |
| Performance monitoring of slow requests and database calls | Needs rework | Check which transaction and span data your Sentry SDK sends, then compare it with the performance views in GlitchTip and adjust sampling settings. |
| Uptime monitoring | Needs rework | Sentry uptime checks do not transfer automatically. Recreate each monitor in GlitchTip with email or webhook alerts, and add scheduled pings for jobs that must report in. |
| Log search | Needs rework | Confirm the query syntax and filters GlitchTip supports, and rewrite any saved searches or dashboards your team uses in Sentry. |
| Issue grouping and release tracking | Needs rework | Verify that fingerprinting rules and release and environment tags still group issues the way your team expects. Set release names in the SDK so new deployments are tracked. |
| Alert rules | Gap | Alert rules are not exported from Sentry. Re-create each rule in GlitchTip and test it with a sample event before you rely on it. |
| Integrations (Slack, Jira, PagerDuty and similar) | Needs rework | Confirm which integrations GlitchTip offers in your version, then reconnect the ones you need and document any that have no equivalent. |
| SSO and access controls | Needs rework | Confirm the supported authentication options for your deployment, and map Sentry teams and roles to GlitchTip organizations and members. |
| Data retention | Needs rework | Set retention in your own environment and export any history you must keep from Sentry before the old project stops receiving data. |
What history and configuration can be exported from Sentry
Sentry's web API covers most of what you can pull out of a SaaS account, but it does not hand you a ready-made GlitchTip import. Plan the export in three parts: data you can extract, configuration you rebuild by hand, and history you choose to leave behind.
Issues and events via the web API
The Sentry web API exposes issues and their events for each project, which is the raw material for any historical record you want to keep. Check the API reference for the endpoints and filters available on your plan, since event retention in Sentry is finite and older events may no longer be returned. Confirm which fields you need (title, culprit, first and last seen, tags and stack traces) before writing any script, because not every field maps cleanly to GlitchTip's data model. Store exports in a location your security team has approved, since stack traces can contain personal data.
Project and team settings
Project names, slugs, platforms, teams and member roles are the configuration you will recreate in GlitchTip before any events arrive. Export them from the API so the naming scheme stays consistent and each project's DSN can be issued in the right place. Ask the team to confirm which projects are active, since abandoned projects are common candidates for retirement rather than migration. Note that membership and SSO assignments often live outside the project export and must be checked in Sentry's organization settings.
Region-specific API hosts
Sentry SaaS runs in more than one region, and the API host you call depends on where the organization was created. Using the wrong host returns errors or incomplete data, so confirm the host in Sentry's API documentation and in your organization's settings before scripting the export. Record the region in your migration log, because it also determines where your data has been stored. This matters for EU data residency reviews, where the region of the export and the destination of the archive are both in scope.
Cursor pagination and rate limits
List endpoints return results in pages and signal the next page through cursor values in response headers, not through page numbers. A script that assumes page numbers will silently miss records, so follow the Link header until it reports no further results. Read the rate limit headers on each response and back off when the remaining allowance runs low. For a large organization, plan the export as a resumable job that records the last cursor, so an interrupted run does not restart from zero.
Alert rules and integrations
Alert rules, issue ownership rules, and integrations such as Slack, email routing and webhooks do not come across as data you can replay into GlitchTip. Treat them as a manual inventory: list each rule, its condition, its recipients and its destination, then recreate it in GlitchTip and test it with a sample event. Document each rule you retire, so the on-call team knows which alerts stopped and why. Expect this step to take longer than the data export.
Historical events as a judgment call
Most teams do not need every historical event in the new tool. Open issues, recurring errors and events tied to an audit or incident review are worth keeping; the long tail of resolved noise usually is not. Decide per project what history must be retained, for how long, and who can access the archive, and record that decision for your compliance evidence. If you keep an archive, store it separately from the live GlitchTip database so it does not compete for storage with current error tracking.
The migration sequence from inventory to decommission
This sequence moves Sentry error tracking to self-hosted GlitchTip one project at a time, so each team confirms events arrive correctly before production traffic moves and Sentry is retired only after its history has been exported.
Inventory projects, DSNs, SDKs and alert rules
The platform owner lists every Sentry organization, team, project, environment and the DSN each application uses, along with the Sentry SDK package and version in each codebase, the alert rules and the integrations (chat, ticketing, email) attached to each project. Record which items have no GlitchTip equivalent so they can be rebuilt by hand. Done when the inventory is a single reviewed sheet that every project owner has signed off, and each SDK version has been checked against GlitchTip's documented Sentry SDK compatibility before any code changes.
Install GlitchTip and pilot one project
Deploy GlitchTip on your own server with Docker Compose, or on Kubernetes with the Helm chart, using an external PostgreSQL 14 or later database; GlitchTip also supports Valkey or Redis 7 as an optional add-on. Create the organization, teams and one low-risk project in GlitchTip, then point that project's DSN in a staging build at GlitchTip. Done when a deliberately thrown test exception appears in GlitchTip with the correct environment, release and stack trace, and the platform team has confirmed the install's backups and TLS settings.
Re-create alert rules and integrations in GlitchTip
For the pilot project, rebuild each alert rule and notification integration in GlitchTip, using the inventory from the first step as the checklist. Send test alerts to the same channels the on-call team uses today, and confirm that each recipient receives them. Uptime checks and scheduled heartbeats that were run separately also need an equivalent in GlitchTip if you plan to use them. Done when every alert in the inventory has a matching GlitchTip rule that has fired a test alert to the intended recipients.
Run both DSNs in parallel
Keep the existing Sentry DSN active in production and add a second DSN pointing at GlitchTip for the same services, so the same errors reach both systems during a set observation window agreed by the team. Compare event counts, grouping behavior, release tags and source map or symbolication results between the two tools for each project. Done when the owners of each project have recorded that GlitchTip groups and labels events as expected and that no project is missing errors it reported to Sentry.
Cut over by repointing production DSNs
Change the production DSN for each project in configuration or environment variables, release the change through the normal deployment process, and keep the Sentry DSN in the configuration for a rollback path until the cutover is confirmed. Projects move in the order set in the inventory, with the pilot first. Done when every production service sends new events only to GlitchTip, the Sentry project shows no new events for those services, and the owners have confirmed the change in their deploy records.
Export Sentry history and decommission Sentry
Before the Sentry subscription or self-hosted instance is closed, export the issues, events and project settings you need for audit or reference, using the Sentry web API and the export approach in the companion migration guide. Record what was exported, where it is stored and who can access it, then revoke Sentry tokens and integrations and cancel the plan or retire the self-hosted instance. Done when the export is verified, the retention owner has signed off on storage, and no application still references a Sentry DSN.
How repointing the DSN moves error traffic to GlitchTip
The cutover from Sentry to GlitchTip happens in each application's configuration, not in its code. Each service keeps its existing Sentry SDK and only its DSN changes, which is usually handled through an environment variable such as SENTRY_DSN so that the same build can point at either backend. Because GlitchTip accepts events from Sentry's open-source SDKs, the application code path that captures exceptions stays the same. Before changing anything, confirm with GlitchTip's installation documentation that your deployment is reachable from every service over HTTPS, and check the SDK versions in use against the compatibility statements on the GlitchTip website. Do not assume a specific SDK version is supported unless you have verified it in your own test environment.
During the parallel run, keep two DSN values per service: the current Sentry DSN and the new GlitchTip DSN. The simplest pattern is to have the service send to Sentry as before and add a second, independent client or a secondary environment variable that points at GlitchTip, so each backend receives the same exceptions. Make the GlitchTip DSN a separate secret in your configuration store so it can be enabled per environment, starting with staging and then a low-traffic production service. To confirm that events arrive, trigger a known test exception from each service, then check that it appears in the matching GlitchTip project with the expected environment, release and tags. Compare event counts for a few days before you stop sending to Sentry.
Rollback is a single configuration change: restore the original Sentry DSN and redeploy or reload the affected service. Keep the Sentry DSN in your secrets store for the whole parallel period and until the retention window you have agreed for historical data has passed, so that restoring it is quick. Plan for the risk that a misconfigured DSN fails silently, which means errors stop appearing in both tools without anyone noticing. Add a check that fires when a project receives no events for an expected period, and test the rollback once on a non-critical service before you need it in an incident.
What drives migration effort and how to keep it down
This table lists the factors that change how much work a Sentry to GlitchTip move takes, who carries each part of that work and what to ask for in a written quote. Read each row as a question to answer for your own estate before asking for scope. The main takeaway is that alert rules, integrations and SDK changes usually outweigh the server setup, so inventory them first.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of projects and environments | Each Sentry project needs a matching GlitchTip project, DSN and environment mapping, and production, staging and development often differ in tags and release names | Consolidate inactive projects before the move and agree the environment naming scheme in writing |
| Number of SDKs and languages | Each application repository needs its DSN changed and its Sentry SDK version confirmed as compatible with GlitchTip, and mixed-language estates need more testing | Group services by SDK and change the DSN through configuration or environment variables rather than code edits |
| Alert rules and integrations to re-create | Sentry alert rules, issue ownership rules and notification integrations do not move automatically and must be rebuilt and tested by hand in GlitchTip | Export the rule list from Sentry first, rank rules by who depends on them, and rebuild only those still in use |
| Event volume and retention needs | Higher event volume increases database growth and worker load, and retention periods you must keep for audit or support drive disk size | Sample noisy events on the client, agree retention per project and size disk from measured traffic during the parallel run |
| SSO and team structure | Teams, roles and any single sign-on setup must be mapped to GlitchTip organizations and users, and access reviews need evidence of the mapping | Map Sentry teams to GlitchTip organizations on paper first and confirm which identity provider login options your GlitchTip version supports |
| Hosting choice: single server or Kubernetes | Compose on one server needs less setup, while Helm on Kubernetes adds cluster, ingress and managed database work; GlitchTip recommends an external managed database with Helm | Choose the hosting model by the platform team's existing skills and ask the implementer to price each option separately |
| Who pays for each part | The client pays cloud or data center hosting, licences for any managed database, and internal staff time, while the implementer's fee follows the written scope | Ask for line items for setup, alert rebuild, SDK changes, parallel run and handover, each with its own acceptance criteria |
Questions teams ask before moving from Sentry to GlitchTip
Does moving from Sentry to GlitchTip require changes to application code?
In most cases, no. GlitchTip states that it is compatible with Sentry client SDKs and can receive error data from applications through Sentry's open-source SDKs, so the main change is the DSN each project sends events to. The DSN is usually set in configuration or an environment variable, which makes the change a deployment setting rather than a code rewrite. Teams should still confirm that the SDK versions in each service are supported by GlitchTip, check any custom integrations, and test that source maps, release identifiers and environment tags arrive as expected in a staging project before switching production traffic.
How long does a Sentry to GlitchTip migration take?
The duration depends on how many projects and services send errors, how many alert rules and integrations must be rebuilt by hand, and how long the team wants both tools running in parallel. Duration is not a fixed figure, so ask for a timeline in the written scope rather than relying on a general estimate. The biggest drivers are the number of Sentry projects, the complexity of alert routing and notification channels, the number of environments that need separate DSNs, and the availability of engineers who can validate events after each switch.
Can historical Sentry issues and events be imported into GlitchTip?
Sentry's web API can export issues, events and project settings, but importing that history into GlitchTip is a separate piece of work and should be confirmed for your data before you commit to it. Teams often keep Sentry read-only for a retention period and archive the exports they need for audit or post-incident review. Ask whether the scope includes a history import, which fields map cleanly, which items will be re-created by hand (alert rules and integrations in particular), and how issue identifiers and fingerprints will be handled so that recurring errors keep their context.
What does the team need to provide for the migration?
The migration needs access and knowledge from the people who own the applications and the Sentry account. Typically this includes:
- Sentry administrator access to list projects, DSN keys, teams, members and alert rules
- Owners of each application who can change DSN settings and deploy the change
- The hosting environment for GlitchTip, with PostgreSQL 14 or later and the chosen Docker Compose or Kubernetes setup
- A staging environment and a rollback plan for each service
- Named people to approve alert routing and on-call contacts
Ask the implementation partner to list these inputs in the written scope so that dependencies are visible before work starts.
Can our own engineers migrate from Sentry to GlitchTip in-house?
Many teams can do the core work in-house, because the change is mainly DSN configuration and GlitchTip is documented with Docker Compose for a single server and a Helm chart for Kubernetes. The harder parts are operational: running PostgreSQL with backups, sizing workers as event volume grows, setting up TLS and access control, and keeping both tools aligned during the parallel period. Teams with limited platform capacity often hire a partner for the setup and hardening, then keep the operation in-house. Decide based on your staffing, your change calendar and how many services need to move.
What cost components should we ask about before moving to GlitchTip?
Separate the costs into one-time and recurring items. One-time costs include planning, DSN changes, rebuilding alert rules, history export and any import work, testing and documentation. Recurring costs include the server or cluster that runs GlitchTip, the PostgreSQL database and optional Valkey or Redis, backups, storage that grows with event volume, updates and on-call time. Ask for each component in the quote and compare it with your current Sentry plan, including event quotas, retention and any features gated behind higher tiers. GlitchTip's hosted plans are published on its website if you prefer to compare a managed option, while self-hosting moves the infrastructure cost to your side.
Should we run Sentry and GlitchTip in parallel during the cutover?
Running both in parallel is a common way to reduce risk, because each service can switch its DSN after its tests pass and can fall back if events do not arrive correctly. The cost is a short period of duplicate alerting, so define which tool is the source of truth for on-call notifications at each stage. Plan a clear end date for the parallel run, document which services have moved, and keep Sentry's alert rules disabled once GlitchTip has taken over for that project to avoid duplicate pages.
What usually goes wrong and how to prevent it
Most failed Sentry-to-GlitchTip moves fail on the edges rather than the core: alerts that never got re-created, DSNs baked into shipped builds, and history expectations nobody wrote down. Each card below names one of these risks and the check that prevents it before the DSN switch.
Alert coverage lost at cutover
Sentry alert rules, issue alerts and metric alerts do not move with the events, so a project can go live on GlitchTip with no notifications at all. Build an inventory of every rule per project in Sentry, then re-create each one in GlitchTip and send a deliberate test error to confirm the on-call channel fires. Keep Sentry alerts active until the GlitchTip rules have been verified in production.
DSNs hard-coded in shipped builds
Mobile apps and client-side bundles often embed the DSN at build time, and users on older versions keep sending events to the old endpoint long after you change it. Find every place the DSN appears, including CI variables, mobile configuration files and web bundles. Plan a release that reads the DSN from configuration, and keep the old Sentry project receiving events until installed versions have fallen off.
Release and source map configuration
Stack traces are only readable when release names, environment tags and uploaded source maps or debug symbols match the events being sent. A pipeline that still uploads to Sentry will leave GlitchTip with minified, unresolved traces. Confirm with GlitchTip's documentation which upload paths it supports for your platform, then update the CI steps and run one release end to end before cutover.
Uncounted integrations
Sentry usually feeds other systems through its integrations, such as chat notifications, issue trackers, webhooks and deploy markers, and these are easy to forget because they live in project settings rather than code. List every integration per project and decide for each whether GlitchTip supports the same destination, supports it through a webhook, or needs a replacement. Record the decision in the cutover plan.
Expectations for historical data
Teams often assume years of Sentry issues and events will arrive in GlitchTip, but migration usually covers only what can be exported, and some history is better kept read-only in Sentry during a retention window. Agree in writing which issues, events and project settings you will export, and what is retired. Use the Sentry export guidance to confirm what the web API returns before you commit to a plan.
Unclear ownership of uptime checks
GlitchTip uptime monitoring can alert on failed checks and on scheduled pings that stop arriving, but nobody may own those checks after the move. Assign one owner per monitored service, confirm the alert destination is email or a webhook your on-call team actually reads, and test a failed check and a missed heartbeat before you retire any existing monitoring.
How the move differs by team size and starting point
A small team on hosted Sentry usually has a handful of projects, a short list of alert rules and a single on-call group. The move is mostly about standing up one GlitchTip instance, creating an organization and teams that mirror the old ones, and changing DSNs in each application's configuration. Because the Sentry client SDKs stay in place, the code changes are typically limited to the DSN value and any environment settings. History is the main judgment call: a small team may decide that recent unresolved issues are worth exporting and older events can be left in the Sentry archive.
- Configuration scope: Most changes are DSN values in environment variables or secrets, which a single pull request per service can cover.
- Alert rules: A short, hand-written list is usually faster to re-create than building export tooling.
- Parallel running: Run both DSNs for a short overlap period so that you can compare event counts before cutting over.
- Hosting choice: The single-server Docker Compose path described in the installation guide is usually enough at this scale.
- Ownership: Name one person to own the instance, backups and upgrades, because nobody else may know it exists.
Before you start, confirm the current number of projects, alert rules and integrations in your Sentry account, and check whether anyone else sends events from scripts or CI jobs that you might miss.
A large estate has many teams, many projects and many DSNs spread across services, mobile apps, frontends and batch jobs. The migration becomes a program rather than a switch. Inventory matters most: every DSN lives in code, infrastructure configuration, secrets stores or third-party tooling, and each owner needs to know when their service changes. Teams should map Sentry teams and projects to GlitchTip organizations and teams before anyone edits configuration, and decide whether the new layout keeps the same boundaries or consolidates them.
- DSN inventory: Search repositories, deployment manifests and secret stores for each DSN so that no service is missed at cutover.
- Wave planning: Migrate in groups, starting with low-risk services, and keep the Sentry project active until each group is verified.
- Alert rule rebuild: Expect the largest effort here, since rules and integrations accumulate over years and each team owns its own.
- Capacity planning: Ask the vendor or your own engineers to size PostgreSQL, worker services and optional Valkey or Redis for the combined event volume.
- Access model: Map Sentry roles to GlitchTip membership early, so that platform owners and application teams see the right projects.
Before committing to a schedule, ask each team lead to confirm which services they own, which DSNs they use and whether any alert routing depends on Sentry-specific integrations.
Regulated teams usually move because they need events, accounts and keys to stay within a jurisdiction or within their own data center. In this case the question is less about feature parity and more about where every component runs: the GlitchTip application, PostgreSQL, any cache, backups, logs and the network path from applications to the collector endpoint. Legal and security reviewers will want the data flow written down, including who can administer the instance and how access is logged. Anything that cannot be confirmed in the target environment should be marked as an open item.
- Data map: Document where events, user data, source maps and backups are stored, and which operators can reach them.
- Hosting location: Confirm that the chosen data center or cloud region matches the residency requirement, including backup copies.
- Access controls: Plan single sign-on, role assignments and audit logging for administrators of the instance.
- Assessment evidence: Keep configuration records, change history and restore test results, since an independent auditor or certification body will decide what counts as sufficient evidence.
- Vendor support: Ask whether the hosting partner or vendor can sign agreements your data protection policy requires.
Before you choose a hosting option, confirm with your compliance lead which controls and data categories are in scope, and check the hosted GlitchTip plans against those requirements rather than assuming they match.
Teams that already run self-hosted Sentry have the operational skills for a stateful web service with background workers, but they also carry its footprint. Moving to GlitchTip changes the platform underneath the SDKs, so the migration plan should separate the application cutover from the decommissioning of the old stack. Existing Sentry data can be exported through the web API, which covers issues, events and project settings, while the self-hosted database and file storage remain available until the team is satisfied with the new instance. Any customizations, plugins or integrations built against the self-hosted Sentry will need review, because GlitchTip does not cover every Sentry feature.
- Component review: Compare the services you run today with GlitchTip's PostgreSQL and optional Valkey or Redis requirements, and note what can be retired.
- Custom integrations: List plugins, webhooks and scripts that depend on Sentry-specific endpoints, and confirm their GlitchTip equivalents.
- Retention decisions: Decide how long the old Sentry database is kept after cutover, since that choice affects storage and recovery.
- Team skills: Reuse existing Docker or Kubernetes runbooks, but review the GlitchTip installation documentation for its own configuration keys.
- Parallel period: Keep the old instance readable during the overlap so that engineers can check historical issues.
Before starting, confirm which features your team actually uses from the self-hosted stack, because the features you drop determine what you must rebuild or accept as a gap.
What to keep on Sentry or pair with another tool during the move
Before cutting any DSN over to GlitchTip, list every Sentry feature your teams rely on and decide, for each one, whether it moves, stays on Sentry or gets paired with another tool. Session replay is the clearest case: it is a separate product area built around recorded user sessions, not around error events, so GlitchTip's error tracking, performance monitoring, uptime checks and log search do not replace it. A team that depends on replays for front-end debugging should plan a second tool for that work, for example self-hosted OpenReplay running beside GlitchTip, which keeps errors in one place and replays in another. Write the list down with the people who use each feature day to day, because the features most often forgotten are the ones that quietly support triage.
Check every item on that list against GlitchTip's own documentation and its current feature set rather than against this page, since product scope changes between releases. Ask specifically about the features you use: issue assignment and ownership, release and deploy tracking, source map handling, custom fingerprinting, integrations with chat and ticketing tools, and the webhook or email alert types you need. For each gap, record whether the workaround is a configuration change, a script that calls the API, or a separate tool, and who in your organization owns that workaround after the migration.
Keep Sentry running on its existing plan for the features you intend to retain until the gap is closed or replaced. Stopping a subscription before the paired tool is live usually means losing the replay history or the triage view that engineers depend on during an incident. If you plan to pair OpenReplay, install it in a staging environment first, confirm that its front-end snippet does not conflict with your existing Sentry JavaScript SDK configuration, and test the masking settings before any production user sessions are recorded. The decision to keep, pair or drop each feature should be signed off by the engineering and privacy owners together, and written into the migration plan.
Official sources for the migration
These three sources cover what GlitchTip runs on, what it does, and how it is built. Read the installation documentation before sizing infrastructure, the website for the feature and compatibility claims you will test, and the backend repository to confirm license and release state. Check each against your own Sentry SDK versions before cutover.
Installation requirements and deployment paths
The installation documentation sets out the two deployment routes that matter for this migration: Docker Compose on a single server and the Helm chart for Kubernetes. It also lists PostgreSQL 14 or later as a requirement, with Valkey or Redis 7 or later as an optional add-on. Confirm which process layout you need, a single service or separate web and worker services, before you provision the database, because that decision shapes how your ingest capacity scales during the parallel run.
Feature coverage and compatibility claims
The GlitchTip website states that it accepts error data from applications through Sentry's open-source SDKs and lists the categories it covers: error tracking, performance monitoring, uptime monitoring and log search. Treat these as the claims to test. Build a checklist from the features your team uses in Sentry today, such as release tracking, issue assignment and specific integrations, and mark each one as covered, partly covered or missing before you tell stakeholders the migration is complete.
Backend license and release history
The backend repository is a Django application hosted on GitLab and is MIT licensed, which determines what you may run, modify and redistribute inside your own environment. The releases page lists version history, so pin a specific release in your deployment manifests rather than tracking the latest tag. Record the version you deploy, and check the release notes for schema changes before each upgrade so that your parallel period does not break during a routine update.
How DeployOpen plans and runs a Sentry to GlitchTip migration
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Sentry to GlitchTip move, we start by agreeing in writing which projects, SDK integrations and history are in scope, then build and test the GlitchTip deployment alongside your existing Sentry setup.
How we scope
- Inventory every Sentry organization, team, project and DSN that receives events from your applications
- Record the alert rules, integrations and notification routes that must be re-created in GlitchTip
- Agree in writing which Sentry history is exported, and which is left in read-only Sentry access
How we build
- Deploy GlitchTip with Docker Compose on one server or with the Helm chart on Kubernetes, using PostgreSQL 14 or later
- Repoint each project's DSN to GlitchTip in staging first, keeping the existing Sentry SDK code unchanged
- Test error capture, grouping, release tagging and alert delivery before any production DSN is switched
How we hand over
- Document the deployment, DSN mapping, alert rule inventory and the parallel-running period in writing
- Provide a runbook for backups, upgrades and restore tests for the PostgreSQL database and GlitchTip service
- Confirm with your team which Sentry features are not covered by GlitchTip before the cutover is signed off
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed before work starts
- Ongoing support, upgrades and continuous testing are available as a retainer
- Ask us to scope a retainer covering GlitchTip upgrades, backups and access reviews after handover
