How to migrate from Dynatrace to OpenTelemetry, Prometheus and Grafana without losing coverage
If your Dynatrace Platform Subscription (DPS) commitment is approaching renewal, or you need telemetry to stay inside your own environment, the migration replaces OneAgent with OpenTelemetry instrumentation, sends traces to Jaeger and metrics to Prometheus, and rebuilds dashboards and alerts in Grafana. Platform engineering usually owns the collector, storage and dashboard work, while application owners change instrumentation in their own services, and the work normally moves one service at a time. Because Dynatrace documents OTLP ingestion, you can run both paths in parallel: keep OneAgent reporting while OpenTelemetry exports the same services to the new stack, then compare coverage before you cut over. The effort depends mostly on how many services you run and how many dashboards and alerts depend on Dynatrace-specific views. Confirm both numbers in your own inventory before you agree a timeline with anyone.
The biggest risk is not raw telemetry. Traces, metrics and logs move over OTLP without much difficulty. What you lose is automatic discovery, dependency mapping and the AI-assisted root-cause analysis that Dynatrace provides out of the box. Plan for this gap explicitly: list the services where engineers rely on automatic topology, decide which of them need manual instrumentation or service maps, and agree who will own root-cause triage after cutover. Also check that your collection path does what OneAgent did for host and process data, since OpenTelemetry Collector components have mixed stability levels, and the OpenTelemetry status page lists them per component. Log SDK maturity also varies by language, so confirm each language your teams use before you commit to a service order.
Time the cutover against the DPS term, not the other way round. Ask your Dynatrace account team for the exact commitment end date and whether consumption can be reduced during a parallel run, then schedule the last OneAgent removal after the new dashboards and alerts have run through at least one full incident cycle. Prometheus is not a good fit where per-request accuracy is required, so keep any billing or audit-grade counters in a system you have validated for that purpose. Before the cutover, confirm the Prometheus, Alertmanager and Grafana versions you will run, check which of them are still receiving bug fixes, and agree the retention you need in Prometheus, since its default local retention is short and the storage docs say local storage is not replicated. Ask a DeployOpen-style implementation partner or your own team to produce this inventory as a written scope before any work starts.
Which Dynatrace capabilities map cleanly, which need rework, and which are gaps
This table maps each main Dynatrace capability to its open-source counterpart and labels the migration effort as clean, needs rework, or gap. Read the migration note in each row to see what you rebuild, what you keep, and what you will need to cover another way before the DPS commitment ends.
| Dynatrace capability | Open-source equivalent | Migration note |
|---|---|---|
| OneAgent host and process metrics | OpenTelemetry Collector host metrics receiver with Prometheus storage | Needs rework: deploy the Collector on each host, then rebuild host dashboards and alerts from the new metric names. |
| Distributed tracing from OneAgent | OpenTelemetry SDK or auto-instrumentation exporting traces to Jaeger | Needs rework: each service needs OTLP export configured and its trace context checked end to end. |
| Custom metrics and metric ingestion | Application OpenTelemetry metrics scraped or received by Prometheus | Clean for most metrics: Prometheus accepts OTLP metrics when started with the OTLP receiver flag, but confirm cardinality and naming before cutover. |
| Log collection and enrichment | OpenTelemetry Collector log pipeline to a backend you choose | Needs rework: OpenTelemetry log SDK maturity varies by language, so confirm each service's log path. Prometheus does not store logs. |
| Dashboards and alerting | Grafana dashboards with Alertmanager for routing and silences | Needs rework: no automated conversion from Dynatrace dashboards is documented, so each dashboard is rebuilt by hand. |
| Configuration as code | Grafana provisioning files for data sources, dashboards and alerting resources | Clean for Grafana objects: provisioning loads YAML or JSON at startup. Dynatrace settings still need to be exported and mapped separately. |
| Automatic discovery of services and dependencies | No equivalent in the open-source stack; services must be instrumented and configured explicitly | Gap: plan for manual service inventory and instrumentation coverage checks. |
| AI root-cause analysis | No equivalent in the open-source stack; investigation depends on engineers using traces, metrics and logs | Gap: budget for longer incident investigation and runbook work during the first months. |
| Real user monitoring | No stable OpenTelemetry RUM specification, as Dynatrace itself notes; a separate front-end tool is required | Gap: front-end monitoring needs its own replacement and is not covered by this stack. |
What data can be exported from Dynatrace, and what stays behind
Dynatrace documents a limited set of export paths: configuration, metadata and some metric access. Collected telemetry history mostly does not come with you, so the migration plan has to assume a clean start on the new stack while the old system stays readable through the commitment period.
Configuration as code with Monaco
Monaco downloads settings, classic configuration APIs, automations, documents and SLOs as configuration-as-code files. These files are the most useful record of what your Dynatrace environment does, so store them in Git before any cutover. They show alert conditions, dashboards and SLO definitions that you will rebuild by hand in Grafana and Alertmanager. Check which object types your tenant uses, because coverage differs by object type and some settings may need manual recreation.
API access to metrics and entities
The Dynatrace API exposes metric series and entity metadata such as hosts, services and process groups. You can use it to pull a point-in-time inventory of what is monitored, which services depend on each other and which metrics are in use. This gives you a service list to drive OpenTelemetry instrumentation order. It does not give you a full historical backfill into Prometheus, so treat exported metric samples as reference data rather than a migrated time series.
Telemetry history mostly stays behind
Traces, logs and high-resolution metrics collected by OneAgent generally remain in Dynatrace. Plan for a clean start: Prometheus begins with its own local retention, which defaults to 15 days, and Jaeger starts with the traces you send after instrumentation. Ask Dynatrace in writing what history, if any, can be extracted for your tenant and at what cost, and document the gap for auditors and incident reviewers before the cutover.
Keep the old system read-only
Your DPS commitment continues to accrue for the term of the agreement, so retiring Dynatrace early does not reduce the bill. Keep the tenant readable for historical queries, post-incident reviews and audit evidence until the term ends. Confirm with Dynatrace how read-only access, user licenses and Managed deployments are billed during this period, and whether the same DPS commitment can be shared across SaaS and Managed deployments that you run.
Rebuild alert routing in Alertmanager
Dynatrace problem notifications are routed through its own integrations, which do not carry over. Rebuild routing in Alertmanager, using grouping and silences to match your on-call rules, and point Prometheus at every Alertmanager instance rather than through a load balancer. Map each existing notification channel to a receiver, test each route with a controlled alert, and confirm that paging targets still receive every severity during the parallel run.
Connect Grafana to existing identity
Grafana can authenticate users through LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth in all editions. SAML, team sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud, so plan group-to-team mapping manually if you run open source. Reuse your existing OIDC or LDAP provider, map roles before go-live, and document who can edit dashboards and alert rules.
The migration sequence: inventory, pilot, parallel run, cutover and decommission
This sequence moves production telemetry from OneAgent to OpenTelemetry in controlled stages, so each service is proven on the self-hosted stack before Dynatrace is switched off.
Inventory services, agents and dashboards
Your team lists every host running OneAgent, every application it instruments, every Dynatrace dashboard, alerting profile, problem notification and automation that depends on those signals. Map each item to an owner and to the service it supports. Note which OneAgent features you rely on, such as automatic discovery, code-level tracing and real user monitoring, because these will need a different approach. The output is a signed inventory that shows which services are in scope, which are not yet covered by OpenTelemetry, and which Dynatrace assets are needed for audit or incident history. You are done when every dashboard and alert has a named replacement or a documented retirement decision.
Pilot one service with OpenTelemetry and a Collector
Choose one low-risk service with a clear owner. Add OpenTelemetry SDK or auto-instrumentation for its language, then run an OpenTelemetry Collector as an agent or gateway that receives OTLP from the service, processes it, and exports traces to Jaeger and metrics to Prometheus. Prometheus can receive OTLP metrics when started with the --web.enable-otlp-receiver flag, or it can scrape the Collector. Confirm that the Jaeger and Prometheus versions you deploy match the release documentation you rely on, and check the stability level of each Collector component in its README before adopting it. The pilot is done when traces appear end to end in Jaeger and the service's core metrics are queryable in Prometheus.
Run a parallel period with dual OTLP shipping
Configure the same Collector or application exporters to send the same telemetry to Dynatrace over its OTLP API and to the self-hosted stack. Dynatrace ingests OpenTelemetry traces, metrics and logs, so the commitment period can overlap with the new stack. Compare trace coverage, span names, metric values and error rates between the two backends for a representative load. Record gaps, such as missing automatic topology or code-level context, and decide whether each gap is acceptable. Expect some consumption to be billed during this period under your DPS agreement, so ask Dynatrace how OTLP ingest is metered before you start. The step closes when your team signs off that the self-hosted data is complete enough for the services in scope.
Cut over service by service with Grafana and Alertmanager
Move one service at a time. For each service, build its Grafana dashboards from Prometheus and Jaeger data sources, provisioned as code where possible, and route its alerts through Alertmanager to the same on-call channels that Dynatrace notified. Test each alert with a controlled fault, confirm grouping, inhibition and silences behave as intended, and run Alertmanager as a cluster if you need high availability, pointing Prometheus at every instance. Remove the OneAgent and Dynatrace notification for that service only after its dashboards and alerts have been checked by the service owner during a normal change window. Track which services are cut over and which remain on Dynatrace in a single register.
Decommission OneAgent after the DPS term decision
When every in-scope service reports through OpenTelemetry and every alert has been tested, remove OneAgent from remaining hosts and stop the Dynatrace-side notifications and automations. Make the DPS term decision with your procurement team before this step, because the commitment is typically one to three years with a minimum annual commitment, so ending early may not reduce what you owe. Export the configuration and any history you need for audit using the Dynatrace export options, and document where the retained data is stored. The step is complete when OneAgent is no longer running in production, the retained exports are verified, and the runbook for the self-hosted stack is handed to the operations team.
Running Dynatrace and the open-source stack side by side
Run both platforms in parallel by sending the same telemetry to two destinations from one OpenTelemetry Collector pipeline. Instrument each service with OpenTelemetry once, then configure the Collector's otlp receiver to feed two exporters: an otlphttp exporter pointing at Dynatrace's OTLP endpoint and exporters that write to your self-hosted backends. Traces go to Jaeger and metrics go to Prometheus, which accepts OTLP at /api/v1/otlp/v1/metrics when started with --web.enable-otlp-receiver. Because Dynatrace documents OTLP ingestion, this parallel path works while the DPS commitment runs. Keep the Collector configuration under version control, and review the OpenTelemetry Collector configuration docs for the authentication and exporter settings before you enable a second destination in production.
Overlap is only useful if you compare the two sides on purpose. Pick a fixed set of services and a fixed window, then record the request rate, error rate and latency percentiles each platform reports for the same endpoints. Expect differences in how each tool aggregates, samples and labels data, and document them rather than forcing the numbers to match. Compare alert behavior the same way: run new Alertmanager rules in notification-only mode, log every firing and resolution, and check each one against the Dynatrace problem record. Confirm with your operations team which alert channels are live on each side so that a single incident does not page people twice during the overlap.
Plan storage before you rely on Prometheus for history. A standard Prometheus server is a local time series database with a default retention of 15 days, and its storage is not clustered or replicated, so treat it like any other single-node database with its own backups and disk capacity. If you need longer history or redundancy, configure remote write to a long-term store such as Grafana Mimir, and confirm its operating model, license and sizing with the project before you commit. For Grafana, high availability requires two or more active-active servers behind a load balancer sharing MySQL 8.0 or later or PostgreSQL 12 or later. SQLite, the default, does not scale for production, so provision the external database before the cutover.
What drives cost and duration, and how to keep each under control
This table lists the factors that set the cost and length of a Dynatrace exit, from service count to the remaining DPS term. Read each row as a lever: the middle column explains why it moves the budget and the right column shows what to reduce or ask for in a quote.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Number of services and languages | Each service and language pair needs its own OpenTelemetry instrumentation path, test and rollout. Mixed runtimes multiply the work faster than service count alone. | Inventory services by language and runtime first. Group similar services into waves and start with those that already have stable OpenTelemetry SDK support. |
| OneAgent-specific features in use | Automatic discovery, process-level code visibility, and automatic root-cause analysis have no one-to-one open-source equivalent. Teams relying on them need more manual instrumentation and design work. | List which OneAgent features the teams actually use. Retire unused ones early and plan replacements for the rest, confirming gaps with each component's documentation. |
| Dashboard and alert count | Every dashboard and alert is rebuilt by hand in Grafana and Alertmanager, and each must be validated against the old signal. Counts often grow over years of use. | Export and prune the Dynatrace inventory before rebuilding. Rebuild shared templates once, and use Grafana provisioning so new dashboards are reproducible. |
| Prometheus cardinality | High-cardinality labels inflate memory, disk and query load. Prometheus is designed for reliability over precision, so unbounded label values degrade the stack quickly. | Review label sets in the OpenTelemetry Collector before export. Drop or aggregate unneeded attributes and keep user or request IDs out of metric labels. |
| Prometheus retention and storage | Local storage defaults to 15 days and is not clustered or replicated. Longer retention means larger disks, backup work or a remote write target for long-term storage. | Set retention to match the dashboards and alerts you actually use. Decide early whether long-term metrics need a separate system and price that component separately. |
| Grafana high availability database | A single SQLite configuration suits small teams only. Production and high availability need MySQL or PostgreSQL, plus two or more active-active servers behind a load balancer. | Choose PostgreSQL or MySQL from the start if production use is planned. Ask the implementer to confirm alerting deduplication and Grafana Live limits in HA. |
| Staffing to run Prometheus and Grafana | Recurring labor usually outweighs infrastructure. Someone must own upgrades, Alertmanager clustering, on-call and capacity reviews. Prometheus and Grafana release on fixed cycles that need patching. | Name owners for each component before cutover. Ask a quote to separate one-time build effort from ongoing run effort, including upgrades and on-call. |
| Remaining DPS term | Dual-running telemetry during migration costs DPS consumption while the commitment continues. An early cutover may leave commitment unused, and a late cutover extends double running. | Map the end date of your agreement against the migration waves. Ask Dynatrace to explain how consumption accrues and whether shared SaaS and Managed usage can be reallocated. |
What usually goes wrong and how to prevent it
Most failed Dynatrace exits do not fail on the technology. They fail on coverage gaps, duplicated noise and dates set before the evidence exists. Each card below names one risk and the check that prevents it, so the pilot proves the replacement before the DPS commitment ends.
Losing automatic discovery and root cause
OneAgent discovers processes, dependencies and many failure paths without configuration, and Dynatrace's AI root-cause analysis works across that map. OpenTelemetry and Prometheus do not give you this. Before the pilot ends, list every service relationship and alert you relied on in Dynatrace, and assign each one a manual replacement such as a trace view, a service graph in Jaeger or a Grafana panel. Accept the gaps in writing.
Silent instrumentation gaps after cutover
A service can look healthy after its OneAgent is removed while its OpenTelemetry instrumentation drops spans, misses a database client or exports nothing for one endpoint. Nothing alerts on the absence of data by default. For each migrated service, compare request counts and error rates between Dynatrace and the new stack for at least one full business cycle, and add an alert that fires when a service stops reporting.
Duplicate alerts during dual running
While telemetry is sent to both Dynatrace and the new stack, each incident can page twice, once from each system. Teams then silence the wrong channel. Route alerts from the new stack through Alertmanager, use inhibition rules so a service-level alert suppresses its child symptoms, and send the pilot alerts to a test receiver until the rules match the Dynatrace problems they replace.
Treating Prometheus as exact billing data
Prometheus favors reliability over precision and is not suited to workloads that need 100% accuracy, such as per-request billing. Teams sometimes reuse dashboards built on Prometheus counters as the basis for chargeback or SLA credits. Keep Dynatrace or your own transaction ledger as the source for billing and contractual figures, and document where Prometheus values are approximate.
Grafana alerting duplicates in HA
Two or more active-active Grafana servers behind a load balancer can send the same alert notification twice unless alerting is configured for high availability. The Grafana HA docs also list limitations for Grafana Live. Before go-live, confirm the alerting HA settings in a test cluster, trigger a test alert, and count the notifications received at each receiver.
Setting the DPS cutover date before the pilot
Fixing the Dynatrace end date before a pilot has run is the most expensive mistake in this migration. DPS is consumption-based with a minimum annual commitment on a term that is typically 1 to 3 years, so the date that matters is the end of the commitment, not the day the new stack first receives data. Agree pilot exit criteria first, including coverage, alert parity and on-call sign-off, then pick the cutover date against your contract terms with your Dynatrace account team.
How the migration differs by environment and starting point
Dynatrace SaaS already runs outside your environment, so the migration work is almost entirely on your side of the boundary. OneAgent is replaced by OpenTelemetry instrumentation in each service, and the Collector is usually deployed as an agent next to workloads, with a gateway tier in front of the self-hosted backends. Dynatrace stays in place through the DPS commitment term, so you can dual-ship OTLP to both systems and compare results before cutting over.
- Collector topology: Agents on each host or pod forward to a gateway that writes metrics to Prometheus and traces to Jaeger.
- Who updates what: Dynatrace upgrades its own SaaS service, while your team owns the Collector, Prometheus, Jaeger and Grafana versions.
- Where the work concentrates: Instrumenting services and rebuilding dashboards and alerts in Grafana.
- Dual-shipping window: Dynatrace ingests OTLP, so the same telemetry can feed both backends during the commitment term.
- Data history: Telemetry already stored in Dynatrace mostly stays there, so plan for a new retention baseline.
Confirm with your Dynatrace account team which DPS capabilities are in scope for the commitment term and whether any export or egress terms apply.
Dynatrace Managed runs in your own environment, so the Collector and backends sit beside a system you already operate. Your platform team is probably already responsible for cluster capacity, networking and patching, which means the new stack should be planned against the same change windows and ownership model. Because DPS can be shared across SaaS and Managed deployments, licensing may not end when you stop using Managed for a given workload, so confirm the consumption terms before retiring any environment.
- Collector topology: Gateways are often placed on the same network segment as Managed to keep OTLP traffic local.
- Who updates what: Your team updates Dynatrace Managed and the open-source stack, so both upgrade calendars must be tracked together.
- Where the work concentrates: Operating Prometheus storage, retention and high availability alongside Managed cluster administration.
- Licensing overlap: Shared DPS terms can keep Managed consumption running even after workloads move.
- Capacity planning: Expect to size the new stack without Managed's built-in tooling.
Ask Dynatrace how DPS consumption is measured across SaaS and Managed before you scope the cutover, and confirm which Managed components you will keep running during the transition.
Isolated networks change the migration mainly through packaging and updates. Every Collector binary, Prometheus release, Jaeger image and Grafana package must be mirrored into the enclave, and the Collector release artifacts come with checksums and SBOM files that you should verify before import. Grafana provides packages and Docker images, and its upgrade cadence means you must plan repeated mirroring rather than one-time installs.
- Collector topology: Agents and a gateway run entirely inside the enclave, with no outbound export paths.
- Who updates what: Your team performs manual updates after reviewing mirrored releases and their checksums.
- Where the work concentrates: Artifact mirroring, verification and a documented update procedure.
- Authentication: Collector authenticator extensions and Grafana's identity options should be chosen to work without external identity calls, where your policy requires it.
- Support windows: Prometheus minor releases stop receiving fixes after six weeks, so the LTS line may suit enclaves.
Confirm with your security team which artifact sources are permitted and how long a mirrored release can stay in service under your policy. For a deeper treatment, see the sibling page on self-hosted Dynatrace alternatives for air-gapped networks.
Large clusters shift effort toward scale and ownership boundaries. OneAgent often covers many hosts and process groups at once, so replacing it means deciding where OpenTelemetry Collectors run, how many gateways are needed, and how Prometheus scrapes thousands of targets through service discovery. Prometheus stores data on a single-node local database and is not clustered, so long-term retention and high availability require remote write to external storage, which is a separate design decision.
- Collector topology: A DaemonSet of agents for node-level collection plus a gateway Deployment for processing and export.
- Who updates what: Platform teams manage Helm charts or operators, while application teams own instrumentation changes.
- Where the work concentrates: Scrape configuration, cardinality control and remote storage design.
- Grafana state: Production Grafana needs MySQL or PostgreSQL and at least two active-active servers behind a load balancer.
- Alert routing: Point Prometheus at every Alertmanager instance rather than a load balancer.
Ask your platform team to test cardinality and ingest volume in a non-production cluster before sizing storage, and confirm the Kubernetes distribution and operator versions your change process supports.
Small teams with a handful of services usually have a simpler path, but they carry the same obligations for patching and backups as larger ones. A single host running Prometheus, Jaeger and Grafana may be enough for early testing, though Grafana documents SQLite only for small setups and recommends MySQL or PostgreSQL for production. The main risk is that one or two people become the only operators of every component, so documentation and provisioning matter more than topology.
- Collector topology: One Collector deployed as an agent or a single gateway can receive traces and metrics from all services.
- Who updates what: The same people update Collector, Prometheus, Jaeger and Grafana, so write a single upgrade runbook.
- Where the work concentrates: Instrumenting each service and building a small, reviewed set of dashboards and alerts.
- Configuration as code: Grafana provisioning files keep data sources and dashboards reproducible.
- Retention: Prometheus defaults to 15 days of local retention, which may be enough for a small team to start.
Confirm the number of services, the expected sample rate and the people who will hold on-call duties before choosing between a single node and a high-availability design.
Questions buyers ask before moving off Dynatrace
How much does a migration from Dynatrace to OpenTelemetry, Prometheus and Grafana cost?
The software is free to license, so the cost is the work and the infrastructure. The main components are the engineering time to add OpenTelemetry instrumentation service by service, the dashboard and alert rebuild, the compute and storage for Prometheus, Jaeger and Grafana, and the people who run the stack afterward. Prometheus has no paid enterprise edition, so its costs come from infrastructure, storage, implementation and operations. Costs rise with the number of services, the telemetry volume, the retention you need and how many dashboards and alerts must be recreated. Ask any implementation partner for a fixed-scope quote that lists each component, what is one-time and what recurs, and which costs sit with your team. Ask your Dynatrace account team to confirm how the DPS commitment is billed during a parallel run.
How long does it take to move off Dynatrace?
The timeline depends mainly on the number of services and on when your DPS commitment term ends. Each service needs its instrumentation changed, tested and sent to both backends during a parallel run, so a large estate moves in waves rather than all at once. Your cutover date should be set against the end of the committed term, which your contract states, so you do not pay for capacity you no longer use. Ask Dynatrace to confirm the term end date and whether usage can be reduced at renewal. A written scope from an implementation partner should set the waves and milestones before work starts.
What does our team need to provide for the migration?
You need an inventory of services, hosts and the telemetry each one produces, plus named owners who can approve changes to production code and deployment pipelines. Your team should also provide the current Dynatrace dashboards, alerting rules, SLOs and on-call routing so they can be mapped to Grafana and Alertmanager. Access to Kubernetes clusters, container registries and a test environment is required, along with the network paths for OTLP and Prometheus scraping. Confirm with your security team how telemetry leaving application hosts will be authenticated and encrypted, since the OpenTelemetry Collector supports authenticator extensions for both incoming and outgoing connections.
Can our own engineers do the migration without a partner?
Yes, if your team has the skills to instrument applications, run Prometheus and Grafana, and operate a tracing backend. The work is more than installing software: you must decide sampling, label conventions, retention and alert design, and you must keep the stack patched. Prometheus supports only a current release line for a short window, with a long-term support line receiving fixes for one year, so someone must own upgrades. Grafana high availability also needs a MySQL or PostgreSQL database and extra alerting configuration. If these skills are thin, a fixed-scope engagement can cover the build and hand-over while your engineers keep ownership.
Does OpenTelemetry fully replace OneAgent?
No. OpenTelemetry covers traces, metrics and logs that your applications and services emit, but it does not reproduce everything OneAgent does. OneAgent provides automatic discovery, host and process monitoring, and AI-assisted root-cause analysis, and OpenTelemetry requires you to instrument each service and assemble the backend yourself. Trace SDK stability varies by language, and log SDK maturity varies more across languages, so check each runtime in your estate. Real user monitoring has no stable OpenTelemetry specification, so browser monitoring needs a separate tool. Use a gap assessment per service before committing to a cutover date.
What happens to our historical Dynatrace data?
Historical telemetry mostly stays in Dynatrace, and the data you can take out is limited. Dynatrace configuration can be exported as Monaco configuration-as-code files, and metrics and entities can be read through its API, but collected telemetry history is generally not moved into Prometheus or Jaeger. Plan to keep Dynatrace read access for the retention period your audit or incident process needs, and confirm with Dynatrace what export options your subscription includes. Prometheus keeps data for 15 days by default, so set retention and remote storage deliberately before you decommission the old source.
How do Grafana's AGPLv3 license and Prometheus support affect operations?
Grafana moved from Apache-2.0 to AGPLv3 on April 20, 2021, so legal teams should review whether their use, modifications and any offered network service trigger AGPL obligations. Grafana Enterprise is a non-AGPL commercial option, and Grafana Cloud pricing is separate. Prometheus is Apache-2.0 with no paid edition, but support comes from your own staff, a partner or a vendor you contract with. Prometheus minor releases stop receiving bug fixes six weeks after release, so plan to run an LTS line such as 3.13, which receives fixes for one year. Confirm your licensing position with your legal counsel and your upgrade calendar with your operations team.
How DeployOpen scopes, runs and supports the migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Dynatrace exit, that means the OpenTelemetry Collector, Prometheus, Alertmanager, Grafana and Jaeger run in environments your team controls, and the engagement covers the instrumentation waves, the dual-shipping period, the dashboard and alert rebuild and the cutover. DeployOpen does not resell Dynatrace or any other vendor and is not an official partner of any of them.
Engagements are fixed-scope. Before work starts, the parties agree in writing which Dynatrace environments, services, teams and dashboards are in scope, what each deliverable is, and the timeline for each phase. The written scope is also the basis for the quote, because DeployOpen does not publish a price list. To get a comparable quote, ask for the services in scope with their count and language, the number of Dynatrace environments and any Managed deployments, the Grafana and Prometheus hosting model, the retention targets, and whether the scope includes the parallel-run comparison and the decommissioning of OneAgent. Ask which items are one-time and which recur.
After cutover, ongoing support, platform upgrades and continuous security testing of the new stack can be arranged as retainers. This matters because Prometheus and Grafana release on fixed cycles, and the support line for each Prometheus LTS and Grafana minor release is limited, so someone must own upgrades after the project team leaves. Before you sign, confirm with DeployOpen which upgrade responsibilities, response expectations and handover documents the retainer includes, and ask who on the DeployOpen side would own the runbooks for Alertmanager, Grafana high availability and backup of Prometheus data.
