How to migrate from Dynatrace to SigNoz without losing visibility
If your Dynatrace Platform Subscription renewal is coming up, or data residency or lock-in is the concern, the move is an OpenTelemetry instrumentation and dashboard rebuild, not a data copy. Your OneAgent deployments come off service by service, and the SDKs or Collector pipelines that replace them send traces, metrics and logs to a self-hosted SigNoz instance. Plan for the history to stay in Dynatrace until the commitment term ends or your retention window closes, and confirm that with your Dynatrace account team before you set any dates.
Platform or SRE teams usually run this work, often with an implementation partner for the Collector pipelines, ClickHouse sizing and dashboard rebuild. Dynatrace-collected history mostly does not transfer, so the realistic approach is to dual-ship OTLP from the same applications to both platforms for a validation period. Compare the trace, log and metric views side by side, and make sure every alert you rely on has an equivalent in SigNoz before you cut over. Effort and risk concentrate in the services where OneAgent did automatic discovery and code-level visibility, because those need manual instrumentation decisions you did not have to make before.
Be clear about what you are adopting. SigNoz is open core: the Community Edition is MIT licensed for code outside the ee/ and cmd/enterprise/ directories, and its pricing page lists it as free to self-host. The Community Edition does not include SAML, SOC 2 or HIPAA compliance, anomaly detection or prebuilt integrations, and its support is community Slack only. If your auditors or identity team need any of those, confirm with SigNoz which plan or edition provides them before you commit to the design.
Which Dynatrace capabilities map cleanly to SigNoz
This table maps the main Dynatrace capabilities to their closest SigNoz equivalents and marks each as clean, needs rework or gap. Read the status column first, then check the notes for the work each row implies, since most rework sits in instrumentation and alert rebuilding rather than in the SigNoz platform itself.
| Dynatrace capability | SigNoz equivalent | Status and what it means |
|---|---|---|
| OneAgent host and process metrics | OpenTelemetry Collector host metrics and SigNoz infrastructure monitoring | Needs rework: deploy the Collector with host receivers on each host and confirm metric names and tags match what your dashboards expect |
| APM distributed tracing | SigNoz APM and distributed tracing fed by OpenTelemetry SDKs | Clean for supported languages: traces arrive over OTLP, but you must add instrumentation per service, since OneAgent injects it automatically |
| Log management | SigNoz log management ingesting OTLP logs | Needs rework: log SDK maturity varies by language, so confirm each service's log path before removing existing log shipping |
| Infrastructure monitoring | SigNoz infrastructure monitoring | Needs rework: confirm the host and container coverage you need is documented before retiring OneAgent on those hosts |
| Alerting | SigNoz alerts with Alertmanager for deduplication, grouping and notification | Needs rework: every Dynatrace problem rule and notification route must be rebuilt as SigNoz alert rules and tested |
| Dashboards | SigNoz dashboards built with the Query Builder, PromQL or ClickHouse SQL | Needs rework: no automatic conversion is documented, so rebuild each dashboard from its queries and confirm metric names |
| OTLP ingestion | Native OTLP receiver in the SigNoz OpenTelemetry Collector | Clean: OTLP is the shared path that lets the same telemetry feed Dynatrace and SigNoz during the overlap period |
| Automatic discovery of services and dependencies | No equivalent documented as automatic; service maps come from instrumented traces | Gap: confirm with SigNoz whether any automatic discovery exists for your stack, and plan manual service inventory |
| AI root-cause analysis (Davis) | No equivalent; triage relies on your team's queries and traces | Gap: plan runbooks and investigation steps to replace automated causation analysis, and confirm current SigNoz anomaly detection scope |
| Real user monitoring and session replay | Not provided by SigNoz; OpenTelemetry has no stable RUM specification | Gap: use a separate front-end tool such as OpenReplay and link sessions to backend traces by trace ID |
What data and configuration can move, and what stays behind
Dynatrace lets you take configuration out in a few documented forms, but collected telemetry history mostly stays behind. Plan the migration around that split: move definitions where the export allows, rebuild dashboards and alerts from queries, and keep Dynatrace running long enough to cover your retention needs.
Configuration exported as Monaco files
Monaco is Dynatrace's configuration-as-code tool, and it can download settings, automations, documents and SLOs as files. Use these files as a reference inventory of what you configured, even if they do not map one to one onto SigNoz objects. Check which object types your tenant actually exports, because coverage varies by configuration type and version, and confirm that exported files contain no credentials you would need to rotate.
Classic configuration APIs
Some settings are still reachable through classic configuration APIs rather than the newer Monaco export path. Script a read-only pull of alerting profiles, notification integrations and tagging rules into version control before the cutover. Treat the output as a checklist, since the APIs describe Dynatrace's model, not SigNoz's alert rules and dashboards.
Metrics and entity API access
The Dynatrace API can read metrics and entity data, which lets you pull recent history and the topology of services and hosts into a spreadsheet or your own inventory. Use it to record which services exist, their owners and their dependencies. Historical series pulled this way are useful for baselines and reports, but they do not become SigNoz data, so do not expect them to appear in SigNoz dashboards.
Telemetry history and retention overlap
Traces, logs and metrics already collected in Dynatrace mostly stay there, and the Dynatrace retention period sets how far back you can look. Decide which incident reviews, audit trails and capacity baselines you need after cutover, then keep the Dynatrace tenant or export subscription running long enough to cover them. Rebuild SigNoz dashboards from queries against new data rather than from imported history.
Notification channels and on-call routing
Dynatrace problem notifications route through integrations to email, chat, ticketing and paging tools, often with routing rules per team. Recreate each channel and routing rule in SigNoz Alertmanager, then test every path with a synthetic alert. Confirm which on-call tool receives pages during the dual-run period so that no alert fires twice or not at all.
Service tags and OTLP exporters
Dynatrace tags, management zones and the attributes applied by OneAgent tell you which service owns which telemetry. Carry these meanings into OpenTelemetry resource attributes such as service name, environment and team, set in each application's OTLP exporter configuration. Inventory every exporter endpoint and credential, because a missing attribute breaks SigNoz filters and ownership reports.
Migration sequence from inventory to Dynatrace decommission
This sequence moves monitoring from OneAgent to OpenTelemetry-fed SigNoz in controlled stages, so each cutover is proven against a baseline before Dynatrace is switched off at the end of the DPS commitment term.
Build the OneAgent service inventory
Export the list of hosts, process groups, services and applications that OneAgent currently monitors, and map each one to its owning team, runtime, language and critical path. Pair this with an export of dashboards, alerting profiles, problem notifications and SLOs, which you can pull through Dynatrace configuration exports and API access. The output is a service inventory with one row per service, its telemetry types in use (traces, metrics, logs, RUM) and its owner. The step is done when each owner confirms their rows, and any service without an owner is escalated before work starts.
Pilot one service with dual OTLP export
Choose one low-risk service with clear ownership and instrument it with OpenTelemetry SDKs and the OpenTelemetry Collector, configured to export OTLP to both Dynatrace and a self-hosted SigNoz instance. Keep OneAgent running on the same host so the two sources can be compared. Confirm the Collector's authenticator and exporter credentials follow the configuration best practices before go-live. The output is a pilot baseline: request latency, error rates, span counts and log volume recorded side by side for the same time window, with any attribute or naming gaps logged. The pilot is done when both backends show matching traffic for the agreed window.
Run both platforms in parallel
Expand dual-shipping service by service, using the inventory to set the order. Teams rebuild their SigNoz dashboards with the Query Builder, PromQL or ClickHouse SQL and check them against the Dynatrace views they replace. Track which Dynatrace features each team relies on, such as automatic discovery, Davis-based root-cause analysis and user session data, because SigNoz will not replicate them automatically. The output is a gap register listing each lost or changed capability, its owner and the compensating control. The step is done when every service in the inventory is sending OTLP to both platforms and every dashboard has a SigNoz counterpart or an accepted gap.
Create the alert parity list
For every alerting profile, problem notification and SLO in the inventory, write the equivalent SigNoz alert rule, its threshold, evaluation window, severity and notification route. SigNoz uses Alertmanager for deduplication, grouping and notification, so confirm routing and escalation paths in a test environment. Record each Dynatrace alert that has no direct equivalent, and decide whether it is rebuilt differently or accepted as lost. The output is an alert parity list that pairs each source alert with its target rule and a test result. The list is complete when every critical alert has a fired test notification received by the correct on-call group.
Write and approve the cutover checklist
For each service, assemble a cutover checklist covering the OTLP exporter switch, the removal of OneAgent from the host or container image, dashboard and alert sign-off, on-call acknowledgement and the rollback steps. Assign owners for each item and name the approver from the platform and security teams. Confirm the SigNoz deployment has the backup, upgrade and access controls your policy requires, since a self-hosted install puts those tasks on your team. The output is a signed cutover checklist per service. It is complete when each service has an approved checklist and a documented rollback path.
Cut over services and retire OneAgent
Execute the approved checklists in inventory order, removing OneAgent only after the service owner signs off on the SigNoz dashboards and alerts for that service. Keep Dynatrace exports running for the services still in parallel so nothing is lost mid-migration. Monitor each cutover for the agreed stabilization period and reverse it if the rollback criteria are met. The output is a cutover log with the date, owner and result for each service. The step is done when no service in the inventory depends on OneAgent for telemetry or alerts.
Decommission Dynatrace against the DPS term
Before the DPS commitment term ends, confirm with Dynatrace in writing which subscription, deployment (SaaS or Managed) and data retention applies, and export the configuration and any history you must keep. Your contract terms and the rate card set the timing of the final steps, so ask your account team and procurement to confirm the notice period and the consumption position before you stop ingestion. Remove remaining tokens and endpoints, then archive the configuration exports. The output is a decommission record covering the final export location, the date ingestion stopped, the revoked credentials and the signed approval from the owners. The record is complete when the subscription is closed or formally ended in writing.
Running Dynatrace and SigNoz side by side while the DPS commitment runs
The safest way to leave Dynatrace on a committed Dynatrace Platform Subscription (DPS) is to stop treating the move as a single cutover date. Point the instrumented services at an OpenTelemetry Collector gateway, and have that gateway export the same traces, metrics and logs to both Dynatrace and a self-hosted SigNoz instance. Dynatrace documents OTLP ingestion, so the Dynatrace side needs only an exporter change and an API token with the ingest scopes your tenant requires, which you should confirm in the Dynatrace OpenTelemetry documentation. Teams can then move dashboards, alerts and on-call routing to SigNoz one service at a time, and retire Dynatrace only when each service has been verified in SigNoz.
Before the gateway goes into production, check the supply chain of the Collector itself. OpenTelemetry Collector releases ship signed artifacts, SHA256 checksums and SBOM files, so your platform team can verify each binary or container image against its checksum and inventory it against your vulnerability process. Store the exporter credentials in an authenticator extension, such as oauth2client for outgoing requests, rather than in plain configuration files, and apply the Collector configuration best practices to restrict exposed receivers and endpoints. Confirm which Collector distribution and version your SigNoz release expects before you pin it, since the Collector's component stability levels differ and are documented per component.
Dual-shipping has a cost that most migration plans underestimate. Every span, metric point and log line is ingested and billed twice, once by Dynatrace under its DPS rate card and once by SigNoz, where the cost is your own infrastructure for ClickHouse storage, compute and retention, or a SigNoz Cloud plan if you choose it. Moving telemetry to SigNoz does not reduce the Dynatrace commitment, which is a minimum annual amount set in the agreement, so the overlap is usually paid in full. Ask Dynatrace whether the commitment can be adjusted at renewal or whether usage can be redirected, and model the overlap window against the commitment term before you begin.
How the migration differs by starting point
Dynatrace SaaS sends OneAgent data to a tenant that Dynatrace operates, so the first question is where the data already lives and where it must live afterward. Moving to SigNoz means choosing between self-hosting in your own environment and SigNoz Cloud, which offers US, EU and India data centers. The instrumentation path is the same in both cases because OpenTelemetry sends to whichever OTLP endpoint you configure.
- Instrumentation: Replace OneAgent service by service with OpenTelemetry SDKs or auto-instrumentation, and point exporters at a SigNoz OpenTelemetry Collector.
- Hosting: Self-hosting uses Docker Standalone, Docker Swarm or Kubernetes with Helm, with the operational work of ClickHouse, upgrades and backups falling on your team.
- Residency: Confirm whether SaaS-held telemetry can move to a self-hosted store in your own region, and whether SigNoz Cloud's region options meet your rules.
- Dual shipping: Because Dynatrace ingests OTLP, you can export the same traces, metrics and logs to both platforms until the DPS commitment ends.
Before cutover, confirm with your Dynatrace contact and your data protection owner which telemetry, if any, you are allowed to retain outside Dynatrace.
Dynatrace Managed runs in your own environment, so telemetry already stays inside your network and the residency question is mostly about where the new SigNoz data lands. The migration is less about moving data out of a third-party tenant and more about running a second observability stack alongside an existing one you operate. Dynatrace Managed also shares DPS with SaaS deployments, which can affect how you plan the commitment.
- Instrumentation: Keep OneAgent on hosts that are still reporting while new services start with OpenTelemetry, then retire OneAgent per host.
- Hosting: Plan SigNoz on the same platform your Dynatrace Managed cluster uses, or on a separate Kubernetes or Docker estate, and size ClickHouse storage for your retention targets.
- Operations: Your team already runs Dynatrace Managed upgrades, so add SigNoz and Collector upgrade cycles to the same change calendar.
- Shared DPS: Confirm with Dynatrace whether a shared DPS commitment still covers Managed usage during the parallel run.
- Residency: Confirm that your Managed deployment's location and SigNoz's location both meet your data handling policy.
Ask Dynatrace how the DPS commitment applies to Managed usage during dual shipping, and ask SigNoz which Community Edition limits affect your deployment.
Air-gapped and offline Dynatrace Managed environments have the strictest constraints, because nothing can leave the enclave and software arrives only through approved transfer paths. A SigNoz deployment inside the same network must be installed from mirrored images and charts, and every upgrade needs a repeatable transfer process. Dual shipping from inside the enclave only works if the OpenTelemetry Collector and SigNoz both sit inside the boundary.
- Instrumentation: Build OpenTelemetry SDK and Collector images in the enclave's artifact store, and verify signed artifacts and SHA256 checksums on each import.
- Hosting: Use Kubernetes with Helm, Docker Swarm or Docker Standalone from mirrored sources, with ClickHouse and Collector data kept inside the enclave.
- Updates: Plan a manual release cadence, since SigNoz releases and Collector releases cannot be pulled directly, and record the SBOM for each version you import.
- Alerting and access: Confirm that Alertmanager notification paths work without external endpoints, and that SAML or SSO options match your identity setup.
- Support: Community Edition support is through community Slack, which the enclave may not reach, so confirm your support path in writing before cutover.
Confirm with your security office whether the enclave's approval process allows dual shipping at all, and get the mirrored artifact list reviewed before work starts.
A small team usually runs a few services and one or two people own observability. The main risk is taking on a full stack without enough hands to operate it. Starting with a single SigNoz host or a Docker deployment keeps the first phase simple, and the Community Edition covers APM, tracing, logs, infrastructure monitoring and alerting. Confirm early whether you need features the Community Edition leaves out.
- Instrumentation: Start with auto-instrumentation for the few services that matter most, and add manual spans only where the traces are not useful.
- Hosting: Docker Standalone is the simplest path for a single environment, with Kubernetes reserved for teams that already operate a cluster.
- Dashboards: Rebuild only the dashboards people actually open, using the Query Builder before writing PromQL or ClickHouse SQL.
- Feature gaps: Check whether SAML, SOC 2 or HIPAA support, anomaly detection or prebuilt integrations are required, since the Community Edition does not include them.
- Staff time: Count the hours of upgrades, backups and on-call coverage that will fall on the same people who run the rest of the platform.
Ask whether your team can absorb recurring upgrades and backups before choosing a self-hosted path, and get that answer written into the scope.
A large estate has many teams, many services and often several Dynatrace environments with different ownership. The migration needs a sequence, a governance model and a clear owner for the Collector configuration, which becomes shared infrastructure. Telemetry volume and retention drive storage design, and large estates usually need a gateway Collector tier to receive data from many sources.
- Instrumentation: Migrate in waves by team or domain, with a shared OpenTelemetry configuration baseline and a review process for new exporters.
- Hosting: Use Kubernetes with Helm and plan ClickHouse capacity, replication and backup as a platform service, not a team project.
- Collector tiers: Run agent Collectors next to services and gateway Collectors for central routing, authentication and processing.
- Access control: Use Collector authenticator extensions for OIDC on receivers and credentials on exporters where your security policy requires them.
- Commercial options: Compare self-managed Enterprise, Dedicated and BYOC against self-hosting, since those options change who runs upgrades and backups.
Ask for the Enterprise pricing components and the support boundaries in writing before choosing a hosting model, because the self-hosted option shifts operations to your team.
What usually goes wrong in this migration and how to prevent it
Most failed Dynatrace-to-SigNoz migrations fail on details rather than on the platform itself. The cards below cover the gaps teams hit most often, from alerting and data comparison to storage sizing and upgrades, each with a check to run before you rely on the new stack.
Alert gaps from missing baselining
Dynatrace learns normal behavior for each service and raises problems automatically. SigNoz alerts only fire on the thresholds and conditions you write, so a service that degrades slowly may never trip an alert. Before cutover, list every Dynatrace problem type that paged someone in the last six months and confirm an equivalent rule exists in SigNoz for each one. Treat any gap you cannot close as a known blind spot with an owner.
Dashboards that match on sight only
A dashboard can look right while using a different aggregation, such as average where Dynatrace shows a percentile, or a different time window or rollup interval. Two charts that look similar can disagree by a meaningful margin during a spike. Pick a few incidents from the past and compare the same query in both tools, checking the aggregation, filters and units, before retiring the old dashboard.
Sampling differences in traces
Dynatrace and an OpenTelemetry pipeline will rarely keep the same share of traces, and head or tail sampling rules in the Collector change what reaches SigNoz. Errors and slow requests may be dropped if the sampling policy is set only for volume. Document the sampling configuration on both sides, and confirm that error and high-latency traces are retained at the rates your investigations require.
Real user monitoring left uncovered
Dynatrace's real user monitoring, session data and browser-side visibility do not come across through OpenTelemetry, because the OpenTelemetry project has no stable RUM specification. SigNoz will show backend traces only for the frontend calls that reach your services. Inventory which teams depend on browser performance or session data, and assign a separate tool for that scope rather than assuming SigNoz covers it.
ClickHouse storage and retention sizing
Self-hosted SigNoz stores telemetry in ClickHouse, so disk, memory and retention become your team's problem. Ingest volume grows with every service you instrument and every log line you keep. Before go-live, measure daily ingest from the dual-shipping period, set retention per signal type, and ask your platform team to size storage and backups for that growth, including the cost of the disks and staff time to run them.
Unplanned upgrades of SigNoz releases
SigNoz ships releases on a frequent cadence, so a Helm chart or Docker image that tracks latest can change the platform under you. A minor release can alter query behavior, schema migrations or collector configuration. Pin the version in your deployment manifests, test each upgrade in a staging environment with real dashboards and alerts, and record the release notes you reviewed for every change.
Cutover before parity
Teams often switch alerting to SigNoz before dashboards, alert rules and service coverage match Dynatrace, then discover the gaps during an incident. Set explicit parity criteria, such as every critical service reporting traces, every paging alert reproduced, and an agreed period of side-by-side comparison. Keep the Dynatrace subscription running until those criteria are met, and plan the commitment end date with your procurement team.
What drives cost and duration, and how to keep each down
This table lists the factors that change the cost and effort of moving from Dynatrace to self-hosted SigNoz, with the one-time and recurring side of each. Read it as a checklist for scoping a migration and for the questions to put to any quote. The main takeaway is that instrumentation and dashboard rebuild effort scale with the estate, while the DPS term sets when savings can start.
| Driver | Why it moves cost or effort | How to keep it down |
|---|---|---|
| Number of services and languages | Each service and language needs an OpenTelemetry SDK or agent setup, tested in staging before cutover. Effort rises with the count of distinct runtimes. | Group services by language and framework, start with a small set of pilot services, and reuse one tested configuration per runtime. |
| OneAgent versus OTLP instrumentation effort | OneAgent installs automatically on hosts. OTLP requires SDK or auto-instrumentation changes, collector deployment and verification of span and metric names. | Start with auto-instrumentation where the language supports it, and confirm coverage gaps against the OpenTelemetry status page for each language. |
| Dashboard and alert count | Dynatrace dashboards and problem rules do not transfer automatically. Each one is rebuilt in SigNoz and tested against live data. | Export and inventory dashboards first, retire unused ones, and rebuild only those tied to on-call or service level objectives. |
| Retention and storage on ClickHouse | Storage in a self-hosted SigNoz install grows with ingest volume and retention period. Disks, backups and query performance all depend on these two settings. | Set retention per signal type, sample high-volume traces, and drop noisy logs at the collector before they reach ClickHouse. |
| DPS term left to run | The DPS agreement carries a minimum annual commitment, so running Dynatrace and SigNoz in parallel costs more during the overlap. Savings begin only after the commitment period ends. | Confirm the end date and any commitment terms with Dynatrace, and plan the dual-shipping window and cutover around that date. |
| Staff skills for self-hosting | Your team runs upgrades, backups, scaling and ClickHouse operations. These are recurring tasks that need Kubernetes or Docker and database skills. | Confirm internal skills early, decide who owns on-call for the observability stack, and budget training or outside support as a recurring line. |
| Community Edition versus Enterprise support | Community Edition is free to run but has community Slack support only and omits SAML, SOC 2 and HIPAA compliance, anomaly detection and prebuilt integrations. Enterprise adds vendor support and those features at a published starting price on SigNoz's pricing page. | Map your required features and support obligations first, then compare the Community Edition with the Enterprise option and ask for written scope on what each includes. |
Questions buyers ask before moving from Dynatrace to SigNoz
What does a move from Dynatrace to SigNoz cost, and what drives it?
The cost has two sides: the software subscription and the people or partner effort to move. SigNoz Cloud and SigNoz Enterprise are priced separately from the self-hosted Community Edition, which carries no license fee. The SigNoz pricing page lists Cloud Teams from $49 a month including $49 of usage, and Enterprise from $4,000 a month, so confirm current figures with SigNoz before budgeting. Your effort is driven by the number of services and languages to instrument, how many dashboards and alerts to rebuild, the infrastructure you run for ClickHouse and the collector, and the length of the overlap while Dynatrace is still licensed under DPS. Ask any implementation partner for a fixed-scope quote built from a written list of services, dashboards and alert rules.
How long does a Dynatrace to SigNoz migration take?
The duration depends on the size of the estate and on when your Dynatrace commitment ends, so no fixed timeline applies to every team. The work usually runs in phases: inventory services, add OpenTelemetry instrumentation to a pilot service, send the same telemetry to both platforms over OTLP, rebuild dashboards and alerts, then cut over. Dynatrace documents OTLP ingestion, which makes the parallel run possible, but the overlap period should match your DPS term and your validation needs. Ask for a phased plan with exit criteria per phase rather than a single end date.
What does the migration need from our own engineering and operations teams?
Your teams must own decisions that only they can make, even when an outside partner does the build. Expect to provide access to the Dynatrace tenant and its configuration, a list of critical services and their owners, access to your Kubernetes or virtual machine platform, and sign-off on data retention and access rules. On the engineering side, application teams need time to change instrumentation and to check that traces, metrics and logs arrive with the attributes they expect. Operations teams need to run and patch the SigNoz stack, including ClickHouse storage, backups and upgrades, which SigNoz documents as the customer's responsibility in its self-hosted Enterprise model.
Can our own team run this migration without an outside partner?
A capable platform team can do the work alone if it has time, experience with OpenTelemetry and ClickHouse, and an agreed plan to keep production alerting intact. SigNoz publishes self-host installation options for Docker Standalone, Docker Swarm and Kubernetes with Helm, so the install path is documented. The harder parts are usually replacing Dynatrace's automatic discovery and root-cause features, reproducing alert behavior and running the stack after go-live. If those skills are thin, a fixed-scope engagement can cover planning, implementation, hardening and handover, and a retainer can cover ongoing upgrades and support.
Can we move our Dynatrace history into SigNoz?
In most cases, collected telemetry history does not transfer, and you should plan for the old data to stay in Dynatrace for its retention period. What can be moved is configuration and definitions: dashboards, alert logic and service mappings can be exported from Dynatrace and rebuilt in SigNoz, using its Query Builder, PromQL or ClickHouse SQL. Confirm what Dynatrace will export for your tenant and version, and decide with auditors whether historical data must be retained elsewhere for incident reviews or compliance.
What does SigNoz Community Edition leave out compared with Enterprise?
The Community Edition is free to self-host and includes APM and tracing, log management, infrastructure monitoring, alerting and LLM monitoring. According to the SigNoz pricing page, it does not include SAML, SOC 2 or HIPAA compliance, anomaly detection or prebuilt integrations, and its support is community Slack only. SSO is listed on every plan, while SAML is limited to the Teams and Enterprise plans. Enterprise, starting at $4,000 a month per the same page, adds enterprise support and deployment options such as Cloud Dedicated and BYOC. If you need SAML, a SOC 2 report from the vendor, or contractual support, confirm these with SigNoz before you commit.
Does DeployOpen issue compliance certifications for a SigNoz deployment?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue audit reports, attestations and certifications. Ask SigNoz directly whether it holds the SOC 2 or HIPAA status you need, because the Community Edition pricing page does not list them. Your own assessor will decide what evidence is sufficient for your environment.
What DeployOpen does and does not do in this migration
DeployOpen plans, implements, integrates, hardens, backs up and documents the self-hosted SigNoz deployment and the OpenTelemetry Collector pipeline inside your own infrastructure. In practice that means agreeing which SigNoz install method your environment supports (Docker Standalone, Docker Swarm or Kubernetes with Helm), sizing the ClickHouse storage and retention, configuring the Collector as an agent or gateway, setting up dual-shipping over OTLP while the Dynatrace DPS commitment runs, and writing the runbooks for upgrades and backups. Most of this work is delivered as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before any work starts. Ask for that written scope to name the services, the environments and the hand-over items explicitly, including who owns the Dynatrace tenant and the SigNoz admin accounts after go-live.
Two areas stay with your team or with other parties. DeployOpen does not change your application code beyond agreed instrumentation changes, and it does not decide which Dynatrace capabilities you can retire. Those decisions belong to your service owners and to whoever holds the DPS contract. Feature gaps such as automatic discovery and AI-assisted root-cause analysis need a documented replacement plan, which DeployOpen can help write, but no open-source tool will reproduce them automatically. Confirm with SigNoz which features your chosen edition includes, since the pricing page places SAML, SOC 2 and HIPAA compliance, anomaly detection and prebuilt integrations outside the Community Edition. On compliance, DeployOpen can prepare configuration, access controls, logging and backup evidence for an assessment. It does not issue audit reports, attestations or certifications. Those come from independent auditors or certification bodies, and your compliance lead should agree early on which evidence they will expect.
How DeployOpen scopes, runs and supports the migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure. For a move from Dynatrace to self-hosted SigNoz, we start with a written scope that fixes the services, environments and dependencies involved before any instrumentation work begins.
How we scope
- Inventory which services run OneAgent today and which Dynatrace features, such as automatic discovery and Davis root-cause analysis, your teams rely on.
- Agree in writing the services to instrument, the OTLP dual-shipping window and the cutover criteria for each dashboard and alert group.
- Confirm the DPS commitment term, deployment model (SaaS or Managed) and data retention needs with your procurement and finance teams before scoping.
How we build
- Deploy self-hosted SigNoz with its OpenTelemetry Collector and ClickHouse in your environment, using Docker or Kubernetes with Helm as your standards require.
- Replace OneAgent with OpenTelemetry instrumentation service by service, routing traces, metrics and logs to SigNoz while Dynatrace keeps receiving the same OTLP data.
- Rebuild dashboards with the Query Builder, PromQL or ClickHouse SQL, recreate alerts in SigNoz, and test each alert path against real notification targets.
How we hand over
- Deliver configuration as code, Collector pipeline files, Helm values and a runbook covering installation, upgrades and backup procedures for your operators.
- Document the gap register listing Dynatrace capabilities SigNoz does not replace, with the compensating controls or accepted risks agreed with your owners.
- Train your platform and on-call teams on querying, alert tuning and Collector changes, then record the dashboard and alert inventory as evidence.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the migration engagement.
- Track SigNoz and OpenTelemetry Collector release notes against your environment and plan upgrades in a staging copy before production changes.
- Prepare systems, controls and evidence for your compliance assessments; independent auditors, not DeployOpen, issue any audit report or certification.
