Which fits: Dynatrace Managed or a self-hosted open-source observability stack
Dynatrace Managed fits when the priority is automatic discovery, AI-assisted root-cause analysis and as little in-house platform work as possible. Because Managed runs in your own environment, it can address data residency concerns, and it includes an offline mode for isolated networks. Under a Dynatrace Platform Subscription (DPS), usage accrues against a committed agreement, and the DPS documentation describes agreements that typically run one to three years with a minimum annual commitment. A team that has little capacity to run a metrics store, trace backend and dashboards itself will often value that bundled operation more than the flexibility of assembling components.
A self-hosted stack built on OpenTelemetry, Prometheus, Grafana and Jaeger fits when you need full control over where telemetry is stored, how long it is kept, and which components you upgrade and when. Each piece is open source: Prometheus is Apache-2.0, Jaeger is Apache-2.0, and the OpenTelemetry Collector is Apache-2.0, while Grafana is AGPL-3.0-only, which your legal team should review against your distribution plans. The trade-off is operating effort. Prometheus local storage is not clustered or replicated, so high availability, long-term storage and Grafana's database backend (MySQL or PostgreSQL for production) become your responsibility. This path suits organizations with engineers who already run Kubernetes-hosted services and who can own alerting, upgrades and backups.
The decision turns on four questions. First, the length of your DPS commitment and whether it can be shortened or shared with Managed deployments, since that sets the cost of a parallel run. Second, staffing: who will maintain the stack and cover on-call for it. Third, offline requirements: if the network is isolated, confirm with Dynatrace which Managed capabilities work in offline mode, then compare them with a stack you can mirror and update manually. Fourth, how much APM depth you need. Automatic code-level tracing and root-cause analysis are harder to reproduce with OpenTelemetry instrumentation alone, so inventory the services and workflows that depend on those features before choosing.
Which option fits which scenario
This table matches common situations to the option that usually fits better, with the reason tied to how Dynatrace Managed and a self-hosted OpenTelemetry, Prometheus and Grafana stack differ. Read each row against your own contract dates, network rules and staffing. The main takeaway is that a shared OTLP feed lets you test the open-source stack before any renewal decision, while automatic discovery and offline constraints are the points most likely to keep you on Dynatrace.
| Scenario | Better fit | Reason |
|---|---|---|
| DPS term ending soon | Self-hosted stack, trialed in parallel first | Dynatrace ingests OTLP, so the same telemetry can feed both stacks before the commitment ends. |
| Air-gapped enclave | Self-hosted stack inside the enclave | Confirm what the offline license supports. Collector releases ship SHA256 checksums and SBOM files to help verify mirrored artifacts. |
| Strong Kubernetes and SRE skills | Self-hosted stack | Your team can run Collectors, Prometheus and Grafana, including storage sizing, high availability and upgrades. |
| Dependence on automatic discovery | Dynatrace Managed or SaaS | The open-source stack is assembled from components, so OneAgent-style discovery must be rebuilt through instrumentation and dashboards. |
| Regulated data kept under your control | Self-hosted stack | Telemetry stays in your environment. SAML and team sync need Grafana Enterprise, so confirm your SSO requirements first. |
| Long-lived support requirement | Either, with an upgrade plan | Prometheus LTS 3.13 is supported until July 31, 2027. Grafana minor releases are supported for 9 months, so plan upgrades. |
| Small team without platform engineers | Dynatrace Managed or SaaS | A self-hosted stack adds recurring upgrades, backups and storage operations. Ask for a fixed scope and written runbooks first. |
Where the data lives and who controls the platform
Dynatrace Managed and a self-hosted stack both keep telemetry inside your boundary, but they split control differently. The cards below cover where data sits, how subscriptions and offline operation work, who applies updates, how identity is set up and which compliance work stays with your team and your auditors.
Managed deployment location
Dynatrace Managed runs in your own environment, so monitoring data is processed inside infrastructure you already govern. A self-hosted stack keeps that property but moves every component under your change control, including the collector, the metrics store and the dashboards. Prometheus keeps samples on the node that runs it and is not clustered or replicated, so its storage volume becomes a system you must back up and protect. Confirm with Dynatrace which Managed components, if any, still contact Dynatrace endpoints.
Shared subscription across deployments
Dynatrace Platform Subscription can be shared across SaaS and Managed deployments, so one commitment can cover both during a transition. That matters if some environments move to Managed while others stay on SaaS. DPS agreements are typically one to three years with a minimum annual commitment, and usage accrues against a per-capability rate card. Ask how Managed usage is metered and whether unused commitment carries over if scope shrinks. A self-hosted stack has no subscription, but you pay for compute, storage and staff directly.
Offline mode trade-offs
Offline mode lets Managed run on isolated networks, but it changes what the vendor can deliver to you. Treat Dynatrace's licensing and offline documentation as the authority, and get the offline feature list in writing before you depend on it. Ask which features need outbound connectivity, how updates reach the enclave and how license renewal works. In a self-hosted stack, offline operation is a design decision: mirror images and packages into the enclave, then apply updates by hand on a schedule you set. The air-gapped comparison page covers the mirroring steps in more detail.
Who applies each update
With Managed, you need to confirm who applies each update and when it reaches your environment, then schedule maintenance windows and test your integrations after each change. In a self-hosted stack, your team owns every upgrade path. Grafana's upgrade guidance says minor releases arrive about every other month, patch releases at least monthly, and each minor release is supported for 9 months. Prometheus starts a new minor release cycle every 6 weeks, and a minor release generally stops receiving bug fixes after that window. Plan a monthly patch routine and a process for moving between minor versions.
Identity and access in Grafana
Every Grafana edition supports LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT, which covers most directories used in regulated organizations. SAML and SCIM are Enterprise only, along with team sync and active sync, and Grafana Cloud also includes them. If your policy requires SAML or SCIM provisioning, confirm whether an OAuth-based route meets it or whether Grafana Enterprise is needed. Test group mapping and role assignment in a staging instance before cutover, and record which identity provider controls each Grafana user.
Compliance evidence and responsibility
Regulated teams need evidence that monitoring access, change control and data handling match their control set, whether the platform is Managed or self-hosted. DeployOpen plans, implements and documents the self-hosted stack and prepares controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Agree with your auditor, before migration starts, which artifacts they accept, such as configuration exports, access reviews and change records.
How DPS licensing changes the math on a Managed deployment
The first licensing question for a Managed deployment is not the unit price but the shape of the contract. Dynatrace Platform Subscription (DPS) is a consumption model: customers sign an agreement of typically 1 to 3 years with a minimum annual commitment, and usage accrues against that commitment on a per-capability rate card. Because DPS can be shared across SaaS and Managed deployments, a Managed environment does not have its own separate license line. Ask your account team to show, in writing, which capabilities and consumption metrics draw from the commitment, what happens when usage falls below or exceeds the commitment in a given year, and what the rate card charges for each capability you plan to keep. Those answers decide how much of the commitment you can shed when you move workloads.
A self-hosted stack has no license fee for the core components. OpenTelemetry, Prometheus (Apache-2.0), Jaeger (Apache-2.0) and the Grafana open-source edition carry no per-host or per-consumption charge. The costs move elsewhere and mostly recur: the servers or cloud capacity for collectors, Prometheus, trace storage and Grafana, the disk needed for retention, backup and high availability, and the staff who instrument services, maintain the stack and answer pages at night. Grafana Enterprise and Grafana Cloud are separate commercial options with their own terms, so confirm their pricing directly with Grafana before assuming either is free. The Grafana pricing page lists the Enterprise tier as having a minimum commitment of 25,000 US dollars per year, but any quote for your scope should come from Grafana.
Who updates, patches and operates each side
Dynatrace Managed runs inside your environment, but the product itself is still shipped and versioned by Dynatrace. Your team operates the cluster, hosts, networking, storage and backups, and applies the vendor's releases on the schedule your contract and support terms allow. Because the platform is licensed through Dynatrace Platform Subscription, update obligations, supported versions and any offline update process should be written into your agreement rather than assumed from the product name.
- Vendor releases: Dynatrace publishes the platform builds that your team installs into the environment.
- Infrastructure operations: Your staff keep the hosts, cluster nodes, certificates and storage healthy.
- Backups and recovery: Your team owns backup scheduling and restore testing for the environment.
- Offline updates: Confirm how packages reach an isolated network and who prepares them.
- Support windows: Confirm the versions Dynatrace supports and how long each stays eligible for fixes.
Before comparing options, ask Dynatrace for its written upgrade cadence, supported version policy and the process for patches between scheduled releases.
In a self-hosted stack, the OpenTelemetry Collector sits between your applications and every backend, so its version affects every signal you collect. The Collector project is Apache-2.0 licensed and ships the contrib distribution with signed artifacts, SHA256 checksums and SBOM files. Your team chooses when to take each release, builds or pins the distribution it uses, and tests configuration changes against its component stability levels, which vary and are documented in each component's README.
- Release pace: Releases v0.161.0 (September 16, 2026), v0.162.0 (September 29, 2026) and v0.163.0 (October 16, 2026) arrived 13 and 17 days apart.
- Verification: Check checksums and SBOMs before you deploy a new build.
- Component stability: Review each receiver, processor and exporter README before enabling it in production.
- Configuration security: Apply authenticator extensions and the vendor-neutral security guidance to receivers and exporters.
- Fleet changes: Agent and gateway tiers must be upgraded in a planned order.
Confirm with your security and platform leads how often you will move the Collector forward, and who signs off each change, before you start the migration.
Prometheus and Jaeger are the storage and query layer of the stack, and each has its own support clock. Prometheus starts a new minor release cycle every 6 weeks, and a minor release generally stops receiving bug fixes after those 6 weeks, so most teams move to the long-term support line. The current LTS line is 3.13, released July 1, 2026 and supported until July 31, 2027. Local Prometheus storage is single-node and is not clustered or replicated, so your team owns its sizing, retention and recovery plan.
- Release cadence: A new minor release arrives every 6 weeks.
- LTS support: The 3.13 line receives bug fixes until July 31, 2027, and LTS 3.5 reached end of life on July 31, 2026.
- Latest builds: LTS patch v3.13.4 was published October 2, 2026, and v3.15.0 on September 25, 2026.
- Alerting HA: Alertmanager clustering requires its own configuration and monitoring.
- Jaeger upgrades: Jaeger v2 is built on OpenTelemetry Collector components, so plan its upgrades alongside the Collector.
Ask your team to map each Prometheus and Jaeger version to a dated end of support, and to schedule upgrades before any line reaches end of life.
Grafana gives the clearest public upgrade guidance of the stack, and it sets the rhythm for dashboard and alerting work. Major releases come once a year in April or May, minor releases every other month and patch releases at least monthly. Each minor release is supported for 9 months, and the last minor release of a major version for 15 months. Your team also owns the database behind Grafana, which must be MySQL 8.0 or later or PostgreSQL 12 or later for production and high availability.
- Major releases: One arrives each year in April or May.
- Minor and patch cadence: Minor releases come every other month and patches at least monthly.
- Support windows: A minor release is supported for 9 months, and the last minor of a major version for 15 months.
- Recent builds: Grafana 13.2.0 was released August 18, 2026, and patches 13.2.4, 13.1.8 and 13.0.11 arrived October 13, 2026.
- Hardening: Reapply your security configuration after each upgrade and review the metrics endpoint settings.
Before you commit, confirm with your team how much monthly patch effort it can absorb, and whether it can test dashboards and alerts against each minor release.
What running the open-source stack offline involves
This sequence shows how an isolated network gets OpenTelemetry, Prometheus and Grafana running with packages, images and charts mirrored in, and where the single-node and HA limits sit.
Inventory every component and its dependencies
The platform team lists each OpenTelemetry Collector, Prometheus server, Alertmanager instance, Grafana server, database and exporter the design needs, along with the operating system packages, container images and Helm charts each one pulls in. Owners are named for each item. The output is a bill of materials that both the mirroring team and the security reviewers sign off on before any transfer into the enclave begins.
Mirror packages, images and charts into the enclave
Operators pull the approved versions outside the enclave, verify checksums and signatures where the publisher provides them, and transfer them through the approved media process. Inside the enclave they are loaded into an internal package repository, a private container registry and a chart repository. The check that closes this step is a test install from internal sources only, with outbound connections blocked and logged.
Deploy the Collector and metrics path
The team installs the OpenTelemetry Collector as an agent beside services or as a gateway, then configures Prometheus to scrape targets through static configuration or service discovery. Prometheus local storage is a single node that is not clustered or replicated, so the team treats it like any other single-node database and plans backups of its data directory. Remote write to a long-term store is an option to confirm with the design owner.
Configure Alertmanager and its clustering
Alertmanager receives alerts from Prometheus for grouping, inhibition and silences. For high availability, the team runs more than one instance using the cluster flags and points Prometheus at every Alertmanager instance rather than a load balancer. The output is a test alert that reaches the internal notification channel once and only once.
Stand up Grafana with a production database
Grafana is installed from internal packages or the internal container image. SQLite is the default configuration store, but the installation documentation says it does not scale for production, so the team points Grafana at MySQL 8.0 or later or PostgreSQL 12 or later. For high availability, two or more active-active Grafana servers sit behind a load balancer on that shared database, and alerting is configured to avoid duplicate notifications. The check is a failover test with one server stopped.
Provision dashboards and access as code
Data sources, dashboards and alerting resources are defined in YAML or JSON files loaded at startup, so the environment can be rebuilt from the same source. Authentication is set up against the internal identity provider. The team notes that SAML, team sync and SCIM are limited to Grafana Enterprise and Grafana Cloud, which should be confirmed against the identity requirements before the design is fixed.
Run the manual update cycle
Updates arrive as new packages and images on the vendor side, so each one is tested in a staging enclave, approved, then transferred through the same mirroring process. Prometheus minor releases stop receiving bug fixes after six weeks, so the team tracks the long-term support line and its end-of-life date. The output is a dated change record for every component version running in production.
The operating effort each side asks for
Dynatrace takes over discovery and root-cause analysis, while the open-source stack hands those jobs to your team. With Dynatrace Managed, OneAgent discovers processes and dependencies and its analysis runs inside the product, so the operators you need are mostly platform administrators who manage the cluster, upgrades and access. With a self-hosted stack, the work is spread across roles: someone owns OpenTelemetry Collector pipelines (receivers, processors and exporters, plus the instrumentation in each service), someone owns Prometheus storage and retention, someone runs the Grafana database, authentication and alerting, and someone runs the trace storage behind Jaeger. Confirm which of these roles already exist in your platform or SRE group before you estimate headcount, because the gap is usually in the skills rather than the hours.
Prometheus needs the most careful handling of the four. Its documentation says it values reliability over precision and is not a good fit where 100 percent accuracy is required, so teams that bill or audit from metric counts need to plan for that before they build reports on it. Its local storage is not clustered or replicated and should be managed like any single-node database, which means backups, disk capacity planning and a tested restore procedure are your responsibility. Retention defaults to 15 days, so any longer history requires a remote storage system, and that choice adds another component to run.
Grafana's installation docs size a small deployment at under 25 concurrent users on 2 cores and 2 to 4 GB of RAM. Treat that as a starting point for a pilot, not a production sizing: production use needs MySQL or PostgreSQL for configuration instead of SQLite, and high availability needs two or more active-active servers behind a load balancer, with extra alerting configuration to avoid duplicate notifications. Ask your implementation partner to document the upgrade cadence as well, since Grafana ships patch releases at least monthly and each minor release is supported for 9 months, which makes upgrades a recurring task on the calendar.
Cost components on each side, one-time and recurring
Dynatrace Managed costs sit in a committed subscription plus the infrastructure and people to run Managed, while a self-hosted stack moves most spending into compute, storage and staff. Each card below separates one-time work from recurring spend and names the drivers and quote items to ask for.
Dynatrace DPS commitment and rate card
Under Dynatrace Platform Subscription, you sign an agreement of typically 1 to 3 years with a minimum annual commitment, and usage draws against it on a per-capability rate card. The commitment is recurring for the term, and overage or unused capacity is what changes the bill. Ask how Managed and SaaS usage share one commitment, what happens to unused balance at renewal, and which capabilities are metered separately. Your exit date for the commitment drives when a migration can save money.
Dynatrace Managed infrastructure and upkeep
Managed runs in your own environment, so you pay for the servers, storage, network and virtualization it occupies, plus the time to apply Dynatrace-released updates in your change windows. Infrastructure is recurring, while sizing and initial installation are one-time. Costs rise with monitored host count, retention settings and the number of environments such as production and test. Ask the vendor for current sizing guidance and the hardware and upgrade process for your version.
Open-source software licensing
Prometheus, Jaeger and the OpenTelemetry Collector carry no license fee, because Prometheus is Apache-2.0 and has no paid enterprise edition of its own. Grafana is AGPL-3.0-only for the open-source edition, so the license fee is zero but your obligations change if you modify and offer it as a network service. Grafana Enterprise is a separate paid option. Confirm the license terms with your legal team before you decide which Grafana edition to deploy.
Compute, storage and retention
Prometheus stores data on local disk in two-hour blocks, with a default retention of 15 days, and local storage is not clustered or replicated. Longer retention needs more disk, and high availability or long-term metrics adds components such as remote storage. Compute and storage are recurring, and sizing is one-time. Costs rise with active series, scrape frequency, trace volume and retention length. Ask your team to model these four drivers against your current Dynatrace usage before you commit to hardware.
Grafana Enterprise or Grafana Cloud if chosen
If you choose a paid Grafana option, it becomes a recurring cost. Grafana Cloud's Pro tier starts with a 19 US dollar monthly platform fee plus usage, and its Enterprise tier has a minimum commitment of 25,000 US dollars per year, according to the Grafana pricing page. Grafana Enterprise adds SAML, team sync and SCIM, which the open-source edition does not include. Ask for the feature list and whether the subscription includes support, and remember that a hosted option moves data outside your environment.
Implementation, rebuild and staff
Instrumentation with OpenTelemetry, rebuilding dashboards and alerts in Grafana, and setting up the Prometheus and Jaeger pipeline are mostly one-time work. Running the stack afterward needs people who manage upgrades, backups, on-call alerting and capacity, which is recurring. Staff time is usually the largest cost in a self-hosted stack. Ask for a fixed-scope estimate that lists each service to instrument, each dashboard to rebuild and who owns the runbooks after handover.
What a move from Dynatrace Managed involves
The sequence turns Managed-hosted monitoring into a self-hosted OpenTelemetry, Prometheus, Jaeger and Grafana stack, with telemetry running in parallel until each signal is validated and the cutover is timed against the DPS commitment end date.
Inventory services and export Managed configuration
The platform owner lists every monitored host, application, service and dashboard, and records which Dynatrace capabilities each team depends on, such as alerting profiles, SLOs and automations. Configuration can be downloaded as Monaco configuration-as-code files, which gives a versioned record of what exists today. The step is complete when the inventory names an owner for each service and the exported configuration is stored in version control. Ask your Dynatrace account team which settings fall outside Monaco export before you assume the export is complete.
Instrument services with OpenTelemetry
Application teams replace or supplement OneAgent with OpenTelemetry SDKs and auto-instrumentation, and deploy the OpenTelemetry Collector as an agent or gateway in your environment. The Collector receives, processes and exports traces, metrics and logs, so the backends can change later without touching application code. Done means each service emits traces and metrics to the Collector, and log SDK maturity for each language has been checked against the OpenTelemetry status page.
Dual-ship telemetry over OTLP during the DPS term
The Collector exports the same telemetry to Dynatrace over OTLP and to the self-hosted backends in parallel, which Dynatrace's OTLP ingestion allows. Traces go to Jaeger, metrics go to Prometheus, and logs go to the log store you select. Because Dynatrace keeps billing under the committed consumption agreement while this runs, the team should track ingestion volume against the rate card. Done means both destinations receive matching data for each service, confirmed by sampling.
Set Prometheus and Jaeger storage
Platform engineers size storage for Prometheus, which uses a local time series database with a default retention of 15 days, and decide whether remote write to long-term storage such as Grafana Mimir is needed. Local Prometheus storage is not clustered or replicated, so backups and node recovery must be designed in. Jaeger storage and retention are set separately for traces. Done means retention, backup and restore have been tested on a non-production node.
Rebuild dashboards and alerts in Grafana
Engineers recreate Dynatrace dashboards as Grafana dashboards backed by Prometheus and Jaeger data sources, and rebuild each problem detection rule as a Prometheus alerting rule routed through Alertmanager. Provisioning files keep data sources and dashboards in version control. Grafana's production guidance calls for MySQL or PostgreSQL rather than SQLite, so that database is provisioned before go-live. Done means every dashboard and alert from the inventory has an owner, a rebuilt equivalent or a documented decision to retire it.
Validate parity and document the gaps
Teams compare alert behavior and dashboard values against Dynatrace for a representative period, and log the differences. Expect gaps in automatic discovery, AI-assisted root-cause analysis and real user monitoring, which OpenTelemetry does not cover with a stable specification. Those gaps are closed by runbooks, service maps built by hand, and separate front-end tooling where needed. Done means a signed-off gap register that the operations and security owners have reviewed.
Plan cutover against the commitment end date
The team compares the DPS agreement end date, which is typically 1 to 3 years with a minimum annual commitment, with the validation results, and sets the date when Dynatrace stops being the system of record. Confirm the exact term, notice requirements and any early-exit terms in your contract, because they determine when the commitment stops driving dual-shipping cost. Done means a written cutover plan approved by the budget owner, with a rollback path that keeps Dynatrace data access available until the agreed end.
Questions buyers ask before choosing or switching
What does a self-hosted OpenTelemetry, Prometheus and Grafana stack cost to run?
The software is free under its open-source licenses, so the cost is infrastructure, storage, implementation and the people who run the stack. Infrastructure covers compute for collectors, Prometheus servers, Grafana and the trace backend, plus storage for metrics, traces and logs. Storage and retention are the largest variables, because Prometheus keeps local data for 15 days by default and longer retention needs remote storage such as Grafana Mimir. Staff time is the recurring cost: someone must patch components, watch capacity, rotate credentials and maintain dashboards and alert rules. Ask any partner for a quote that separates one-time implementation from recurring operations, and for the retention period and data volume it assumes.
Who runs the stack after it goes live?
Your platform or observability team runs it, or a partner runs it under a retainer. Each component has its own upgrade rhythm: Prometheus minor releases arrive every 6 weeks and generally stop receiving fixes after that window, so teams often choose the long-term support line instead, and Grafana ships patch releases at least monthly. Dynatrace Managed, by contrast, is updated by Dynatrace on its release cycle while you run the cluster. In a self-hosted stack, every upgrade, backup and certificate renewal is your task, so assign named owners for each component before cutover.
How long does a migration from Dynatrace take?
The duration depends on the number of services, languages, dashboards and alert rules, and on how many teams must sign off on each change. Set the timeline from the written scope of your migration, not from a general estimate. Plan it in phases: first a pilot service, then groups of services, with telemetry sent to both platforms during the overlap. Align the final cutover with your DPS commitment term, because the annual minimum applies whether or not you still use the platform. Ask for milestones and acceptance criteria in the written scope.
Can our team migrate without outside help, and what does that take?
A capable platform team can do it internally, but the work needs people with experience in OpenTelemetry instrumentation, Prometheus scrape and retention design, Grafana administration and Linux operations. The hardest parts are usually rebuilding alert rules so they fire on the same conditions, sizing storage and reviewing access controls. Grafana recommends MySQL or PostgreSQL for production, and high availability needs two or more active-active servers behind a load balancer, so budget time for that setup. An outside partner can take fixed-scope work such as instrumentation, dashboards and hardening while your team keeps ownership of operations.
Can the offline Dynatrace Managed mode be replaced with open-source tools?
Yes, the stack can run fully inside an isolated network if you mirror packages and container images before the cut and apply updates by hand. OpenTelemetry Collector releases ship signed artifacts, SHA256 checksums and SBOM files, which help with verification during transfer. Prometheus, Grafana and Jaeger all install from packages or images that can be staged in the enclave. You would own every update and vulnerability review that Dynatrace performs for you in Managed, so set a patch cadence that matches your risk policy. A separate page covers the air-gapped case in detail.
Which Dynatrace features do we lose when we move?
The main losses are automatic discovery, the AI-assisted root-cause analysis, and OneAgent-based instrumentation that needs no code changes. Open-source tools give you metrics, traces and logs, but you assemble them from separate components and maintain the correlation yourself. Real user monitoring is a further gap, because OpenTelemetry has no stable real user monitoring specification, so browser monitoring needs its own tool. Check each Dynatrace capability your teams use against the migration scope before committing to a cutover date.
Is our OpenTelemetry instrumentation portable between backends?
Yes, OpenTelemetry is vendor-neutral and is not a backend, so the instrumentation in your applications is not tied to Dynatrace. Trace APIs and SDKs are stable in most languages, including Go, Java, Python and .NET, while log SDK maturity varies by language, so check your stack before relying on logs. Dynatrace, New Relic and Datadog all accept OTLP, which lets you send the same data to a commercial backend and a self-hosted one during migration. Collector configuration then decides where data goes, so keep exporter settings in version-controlled files.
What does a fixed-scope engagement cover?
A fixed-scope engagement covers the work named in a written scope, such as designing the architecture, deploying the Collector, Prometheus, Grafana and Jaeger, instrumenting agreed services, building dashboards and alerts, hardening the systems, setting up backups and documenting the result. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure. It prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that scope. Ongoing support and upgrades are available as a retainer.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so an OpenTelemetry, Prometheus and Grafana stack can run beside or in place of Dynatrace Managed. We start with the question your renewal or offline requirement actually raises, then build and hand over only what that scope agrees.
How we scope
- We confirm which Dynatrace Managed capabilities your teams depend on, such as OneAgent host data, APM traces and dashboards.
- We agree the telemetry sources, retention targets and target environment, including whether the stack must run in an offline enclave.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We instrument services with OpenTelemetry and configure Collector pipelines that can dual-ship telemetry during a parallel run.
- We deploy Prometheus, Grafana and a trace backend such as Jaeger in your environment, with authentication, provisioning and security hardening.
- We rebuild priority dashboards and alert rules and test them against your existing signals before any cutover decision.
How we hand over
- You receive configuration as code, deployment documentation, runbooks and a list of Dynatrace features that are not covered by the new stack.
- We document backup, upgrade and retention procedures for Prometheus storage and Grafana databases so your own team can operate them.
- We walk your operators through alerting, incident response and the evidence needed for internal or external compliance assessments.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We can plan component upgrades against the release cycles of Prometheus and Grafana, so your team is not caught on an unsupported version.
- DeployOpen prepares systems and evidence for compliance assessments, while independent auditors and certification bodies issue any reports.
