How to export your data from Dynatrace before you leave
A renewal, a Dynatrace Platform Subscription commitment or a data residency concern is forcing an exit plan, and the first thing to know is what you can actually take with you. Your configuration can be downloaded as Monaco configuration-as-code files, and metrics and entities can be read through the Dynatrace APIs. Most of the telemetry history collected over time, meaning the stored traces, logs and long-range metric data, mostly stays behind and should not be planned as a migration asset.
In scope for this section: Monaco downloads of settings, classic configuration APIs, automations, buckets, documents, segments and SLO v2 configurations, plus API reads of metrics and entities. Out of scope: rebuilding those configurations elsewhere, cutover timing and dashboard rebuilds, which are covered in the migration and cost pages. This section covers only documented export paths. If a data type is not named in Dynatrace's documentation for download or API access, do not assume it can be extracted, and confirm it with Dynatrace before you rely on it.
Before you start, ask Dynatrace which of your DPS deployments (SaaS, Managed or both) hold the configuration you need, and confirm the Monaco version and API token scopes your team will use. Run a test download into a non-production location and check that the files are complete. Record the exported metric series and entity lists you need for historical comparison, because the stored telemetry itself is unlikely to be available in a form you can import into a new backend.
What Dynatrace exports and how each item leaves the platform
This table lists each Dynatrace data type that can leave the platform, the method used, the output format and what the export is for. Read it by asking which items are configuration you can rebuild elsewhere and which are live data that you must pull through the API. The main takeaway is that configuration exports well, while collected telemetry history mostly stays in Dynatrace.
| Data type | Export method | Format | Purpose and limits to confirm |
|---|---|---|---|
| Settings 2.0 objects | Monaco CLI download command | Monaco CLI configuration files | Backup, sharing across environments or templating UI-created settings. Confirm object coverage for your tenant version. |
| Classic configuration APIs | Monaco CLI download command | Monaco CLI configuration files | Covers configurations still served by the classic APIs. Some settings may need manual rebuilding in the target stack. |
| Automation configurations | Monaco CLI download command | Monaco CLI configuration files | Exports workflow-style automation definitions for review or redeployment. Check that connected credentials are excluded and re-entered. |
| Buckets | Monaco CLI download command | Monaco CLI configuration files | Exports bucket definitions that control log and event storage. Retained data inside buckets is not part of the configuration export. |
| Documents | Monaco CLI download command | Monaco CLI configuration files | Exports dashboards and other documents as configuration for reuse. Confirm how each document type is represented before relying on it. |
| Segments | Monaco CLI download command | Monaco CLI configuration files | Exports segment definitions used to filter data. Segments reference entities, so confirm their references still resolve after migration. |
| SLO v2 configurations | Monaco CLI download command | Monaco CLI configuration files | Exports service level objective definitions for backup or rebuilding in Grafana or another tool. Historical SLO results are not included. |
| Metrics and entities | Dynatrace API access (token-based calls) | API responses, typically JSON | Pulls current and historical metric values and entity records into your own store. Confirm API quotas and retention windows in your tenant. |
| Traces, logs and collected history | Limited through API queries | API responses for the queried window | Bulk history export is not covered by the researched facts. Plan to dual-ship OpenTelemetry data to a self-hosted backend to keep history. |
Why collected telemetry history mostly stays behind
Dynatrace keeps the traces, logs and metrics it collects inside its own platform, and the documented export paths cover configuration and API reads rather than a bulk download of telemetry history. The Monaco CLI download command pulls configuration (Settings 2.0 objects, classic configuration APIs, automations, buckets, documents, segments and SLO v2 configurations) into files you can version and reapply. API access returns metrics and entity data for queries, but that is not the same as an archive of every trace and log your teams collected. Before you plan around any historical data, confirm with Dynatrace what, if anything, can be retrieved from your SaaS or Managed environment, including retention limits and any cost of retrieval.
OpenTelemetry does not close that gap. It is a framework for generating, exporting and collecting telemetry, and it is not a storage backend, so it cannot reconstruct data that Dynatrace already holds. The only way to keep a continuous history across a migration is to run a parallel copy: send the same OTLP telemetry to a self-hosted backend such as Jaeger for traces or Prometheus for metrics from the point of instrumentation forward. Your history starts on the day that pipeline starts. Plan the overlap with your DPS commitment term in mind, and decide early which data you must retain for audit, incident review or contractual reasons.
Treat the Dynatrace export as a configuration and recovery asset, and the self-hosted backend as the new system of record for telemetry. Keep Monaco configuration files in version control so dashboards, alerting settings and SLOs can be rebuilt in Grafana or elsewhere, and record the exact retention windows Dynatrace applied to your environment so you know what history you are losing. Ask Dynatrace to confirm these points in writing before the cutover, because the answer depends on your deployment and contract rather than on the framework.
What does not export and the workaround for each gap
Configuration can be moved out of Dynatrace with Monaco, but most collected telemetry, learned models and usage history stay behind. Each card below names one gap, the workaround that closes it and the check to run before the commitment ends.
Historical traces, logs and metrics
Monaco exports configuration, not the telemetry Dynatrace has stored, so historical traces, logs and metrics do not move with it. Keep the old data for the retention you need by pulling what you can through the API before the commitment ends, and check how far back that API reaches for each data type. For continuity, dual-ship OpenTelemetry telemetry to a self-hosted backend such as Jaeger for traces or Prometheus for metrics while the DPS commitment runs, so new history builds up in your own store. Confirm retention limits with Dynatrace before you plan the cutover.
AI root-cause analysis models and baselines
Dynatrace builds learned baselines and root-cause models from the telemetry it observes, and those models are not exported as files. A Grafana or Prometheus stack starts with no baselines, so anomaly thresholds have to be set again by hand. Record the thresholds and alert conditions you rely on now, and treat dual-shipped telemetry as the period in which your own baselines are established. Expect a gap in automatic causal analysis and plan the on-call process around it.
Dashboards and alerting logic outside Monaco scope
Monaco covers several object types, including Settings 2.0 objects, classic configuration APIs, automations, documents and SLO v2 configurations, but it is not a guaranteed inventory of every dashboard and alert your teams built. Inventory the Dynatrace objects by hand, compare them with the Monaco download, and list anything not captured. Rebuild dashboards in Grafana and record each alert threshold from the exported configuration so the rules can be reproduced and reviewed.
User and access history
Audit trails of who changed configurations, logged in, or viewed data are operational records, and they are not part of a configuration download. Ask Dynatrace which audit and access logs can be retrieved, in what format and for what period. Export what is available to your own log store before the subscription ends, and map the roles in Dynatrace to the identity provider you will use with Grafana, since Grafana SAML and team sync are limited to Grafana Enterprise and Grafana Cloud.
RUM and session data
Real user monitoring sessions are browser-side records that OpenTelemetry does not standardize, so Dynatrace RUM history has no direct export path into an open-source stack. Decide whether you need old sessions at all, or only recent ones for comparison. Run a separate front-end tool for new sessions and confirm with Dynatrace whether any RUM data can be exported through its API. Check your privacy notices before keeping session data outside the vendor.
Subscription-side records and commitment usage
Usage reports, consumption history and contract terms under the Dynatrace Platform Subscription are commercial records, and they are not configuration. Under DPS, usage accrues against a minimum annual commitment on a per-capability rate card, so the figures you need for a cost review depend on what Dynatrace reports for your account. Ask for consumption history in writing before the renewal date, and keep a copy with the agreement, so the cost comparison is based on your actual usage.
Export sequence: from inventory to verified archive
This sequence turns a Dynatrace estate into a versioned, checked copy of its configuration and a documented record of metrics and entities, while OpenTelemetry dual-shipping starts building the telemetry history your new stack will hold. Each step ends with a check you can repeat before the commitment term or the environment changes.
Inventory every Dynatrace environment
Platform or operations owners list every Dynatrace environment in scope, including SaaS tenants and Dynatrace Managed deployments run in your own data centers or enclaves. For each one, record the environment URL, the owning team, the API token scopes that exist, and whether it is production, staging or a test tenant. Because Dynatrace Platform Subscription can be shared across SaaS and Managed deployments, also note which environments draw on the same subscription. The step is done when the inventory has one row per environment and someone other than the author has reviewed it against the account owner's list.
Download configuration with Monaco for each environment
An engineer with configuration rights runs the Monaco CLI download command against each environment, which pulls configurations as Monaco files for backup and reuse. Confirm the download covers each object type the Monaco reference lists for your deployment: Settings 2.0 objects, classic configuration APIs, automation configurations, buckets, documents, segments and SLO v2 configurations. Some objects may be missing or unsupported in your Monaco version, so compare the list of downloaded items with what the Dynatrace UI shows for each category. The step is done when the download log shows no failed items you have not explained in writing.
Store configuration files under version control
Commit the Monaco output to a Git repository that your organization controls, with one folder per environment and a commit per download run. Restrict write access to the platform team and read access to the people who need to review configuration, and enable branch protection so that changes are reviewed. Remove or rotate any secrets that appear in the files before the commit, because some configuration can reference credentials, and confirm the repository keeps the history you need. The step is done when a fresh clone contains every environment folder and the access list has been checked against your identity groups.
Export metrics and entity data through the API
Use the Dynatrace API with tokens scoped to read the metrics and entities you need to keep, and export them for the time window your audit, capacity or post-incident reviews require. Record the metric keys, dimensions, time range and query used for each export so the output can be repeated. Dynatrace retention limits apply to what the API can return, so treat exported data as a snapshot and not as a full history. The step is done when each export file has a manifest listing its query, time range, row count and checksum, and a second engineer has re-run one query and matched the result.
Start OpenTelemetry dual-shipping to the target stack
Instrument one service with OpenTelemetry and configure the OpenTelemetry Collector to export traces, metrics and logs to Dynatrace and to the self-hosted target, such as Jaeger for traces and Prometheus for metrics. Dynatrace ingests OpenTelemetry through its OTLP API, so the existing commitment can keep receiving the same data while the new stack starts collecting history. Keep Collector configuration in version control and use authenticator extensions for credentials rather than embedding them in files. The step is done when the same trace ID appears in both backends for a test request and the Collector's exporter metrics show no sustained send failures.
Verify the archive by re-importing or diffing
In a separate test environment, apply the archived Monaco files with the Monaco deploy command and compare the resulting configuration with the source environment, or diff the exported files between two download runs. Review the differences for each object type, and record any items that cannot be restored, such as objects that depend on environment-specific identifiers. Also replay one exported metric query against the archive to confirm the numbers match the saved output. The step is done when the diff has been reviewed, every difference is either explained or fixed, and the findings are filed with the archive so the next reviewer knows what the archive does not contain.
What to plan before the Dynatrace contract ends
Exporting configuration is the easy part. The harder decisions are timing, what history you must keep, and who will run the replacement. Each card below is a contract or staffing question to settle before the export starts, so that the archive, the cutover and the renewal decision line up.
Subscription term and minimum commitment
Dynatrace Platform Subscription is usually signed for one to three years with a minimum annual commitment, and usage draws down against it on a per-capability rate card. Ask Dynatrace or your account owner for the exact term, the commitment amount and whether unused commitment carries forward. Plan the cutover around that end date, not around the day your team is ready.
Notice and renewal terms
Read the notice period, auto-renewal clause and termination terms in your order form and master agreement. Many organizations miss the window to stop renewal and are locked into another term. Confirm in writing whether any data export or retention assistance is included at termination, and who to contact to request it.
SaaS or Managed deployment choice
Where DPS is shared across SaaS and Managed deployments, decide which environments you keep, which you retire and where the exported configuration will be applied. Managed runs in your own environment, which can change the data residency answer for the archive. Ask Dynatrace how a shared subscription is billed when one deployment is removed mid-term.
Retention window for audit
Telemetry history mostly stays in Dynatrace, so decide now which records your auditors, incident reviews and legal hold require, and for how long. Configuration exports keep settings, not the metrics or traces that showed what happened. Confirm the retention periods in your own policy and in the Dynatrace contract, then decide whether a separate archive covers the gap.
Target stack staffing
Running OpenTelemetry, Prometheus, Grafana and Jaeger means someone owns collectors, storage, upgrades and alert rules after the cutover. Name the engineers who will maintain the Collector pipelines and the Grafana instance, and confirm how much of their time is available during the dual-run period. Ask whether a support or implementation partner will cover that work under a written scope.
Data residency and archive access
The exported configuration and any telemetry you archive may hold hostnames, user identifiers and internal service names. Confirm where the archive will be stored, which regions and networks can reach it, and who approves access. Record the access review in your change log so that the archive can be produced for an assessor later.
Who runs the export in SaaS and Managed deployments
In a SaaS deployment, Dynatrace operates the environment and the tenant endpoints sit outside your network. The export runs from a machine you control, usually a CI runner, a jump host or an administrator workstation, that calls the tenant's API over the public internet or over a network path your provider has agreed to. The Monaco CLI authenticates with API tokens and platform credentials that you generate in the tenant, so the scopes on those tokens define what the download can read. Dynatrace operates the platform and its upgrades, so the export only needs to reach the tenant URL and keep up with Monaco releases that match the tenant.
- Network path: the export host needs outbound HTTPS to the tenant endpoint, and any proxy or egress filter in your network must allow it.
- Token ownership: tokens are created by a tenant administrator and are usually tied to a named service identity, so rotation and revocation stay with your team.
- Token scopes: read scopes for each configuration area are separate, so a download can fail for one object type while others succeed.
- Upgrade coupling: the Monaco version should be checked against the tenant before each run, since the supported object types change over time.
- Data location: the downloaded files land on your export host, so storage and access control for those files are your responsibility.
Before you run a full export, confirm the Monaco version, the token scopes and the object types covered with the Dynatrace documentation for your tenant.
In a Dynatrace Managed deployment, the platform runs in your environment and your team controls the hosts, the network segment and the cluster lifecycle. The export still uses the Monaco CLI and the environment API, but the endpoints resolve to infrastructure you operate. Access is therefore governed by your internal network, your identity provider and your change process rather than by a vendor-hosted endpoint. Because you hold the hosts, you also hold the duty to keep the cluster reachable and patched during the export window.
- Network path: the export host reaches the Managed cluster on internal addresses, so firewall rules and DNS for the cluster must be in place before the job runs.
- Token ownership: your administrators issue and store the tokens, which means the secret store and rotation policy belong to your security team.
- Cluster availability: a cluster under maintenance or in a degraded state can make a download partial, so schedule exports outside upgrade windows.
- Offline or restricted networks: if the cluster runs without outbound internet access, the export tooling must also be available inside that network.
- Audit trail: API calls made by the export account appear in your own logs, which helps evidence collection.
Confirm with Dynatrace documentation which Managed version supports your Monaco release and which token scopes the download requires in your cluster.
Token ownership is the control point that matters most in either model, because the same API token can read configuration that includes alerting logic, dashboards and automations. The question is not only who can run the export but who can create, store and revoke the token that runs it. A single shared administrator token is hard to audit and hard to rotate. A dedicated service identity with the narrowest read scopes that cover the object types you need is easier to justify to an auditor.
- Dedicated identity: create one export identity per environment so actions are traceable to a single purpose.
- Least scope: request only the read scopes for the configuration areas you intend to download.
- Secret storage: keep tokens in a vault or CI secret store, not in shell history or repository files.
- Rotation and expiry: set an expiry date and record who rotates the token and when.
- Revocation path: document how a compromised token is revoked in SaaS and in Managed, since the tenant admin role differs by deployment.
Ask your Dynatrace account team or review the product documentation to confirm the exact token types and scopes available for your tenant before you write the export runbook.
Responsibilities split between the vendor and your teams depending on the deployment, and the export job itself is usually owned by a platform or observability team. In SaaS, Dynatrace is responsible for the tenant's availability and platform behavior, while your team owns the export host, the token and the stored files. In Managed, your team also owns the cluster, so a failed export may come from the platform as well as the tooling. Clear ownership avoids the situation where each side assumes the other is checking that the export is complete.
- Platform team: owns the export host, Monaco version pinning and the scheduled run.
- Security team: approves token scopes, storage location and retention for the exported files.
- Dynatrace administrators: create tokens and confirm tenant or cluster settings.
- Application owners: verify that the configuration they rely on appears in the downloaded files.
- Change owners: approve the export window when a Managed cluster is in service.
Document these roles in a runbook and confirm each responsibility with your own change process.
Questions buyers ask before exporting from Dynatrace
How much effort does a full Dynatrace export take?
The effort depends mostly on how many environments you run, how many configurations were built by hand in the UI, and how many dashboards, automations and SLOs depend on them. The Monaco download command can pull Settings 2.0 objects, classic configuration APIs, automation configurations, buckets, documents, segments and SLO v2 configurations into files, so a single environment with mostly standard settings is quick to capture. Environments with heavy manual customization need more review, because downloaded files must be checked for environment-specific IDs, secrets and references before they are reused elsewhere. Ask any partner for a written inventory of your environments and configuration types before agreeing on scope.
Can our internal team export Dynatrace configuration without outside help?
Yes, a team with Dynatrace administration and command-line experience can run the Monaco download workflow itself, as the commands are documented by Dynatrace. The harder part is deciding what to keep, rewriting environment-specific values and proving that the exported files rebuild what you expect in a test environment. Internal teams often underestimate the review of alerting, automations and dashboards that reference other configuration. An outside partner is most useful when the inventory is large, when audit evidence of the export is needed, or when your staff are already committed to running production systems.
What does the export work require from our team?
Plan for four things before the export starts. First, API tokens with the scopes needed to read the configuration you intend to download, issued by someone who can revoke them afterward. Second, a Git repository where exported files are versioned, reviewed and stored with access controls. Third, a test environment that can accept the files so you can confirm they apply cleanly. Fourth, people who understand OpenTelemetry, because the archive is only useful if the replacement stack can later receive the same services' telemetry. Confirm token scopes and the exact Monaco version with Dynatrace documentation for your deployment.
How long should we keep the exported archive, and what drives that?
Retention is set by your own legal, contractual and audit obligations, not by the export tool. Keep configuration archives for as long as you may need to prove how monitoring was set up, typically through the DPS commitment term and any audit window your compliance team defines. Drivers include regulatory retention rules, contract terms with Dynatrace, incident review needs, and how often configuration changes. Store the archive in version control or immutable storage with access logs, and confirm the period with your compliance or legal team rather than with a default setting.
Can we recover historical telemetry from Dynatrace?
Usually not in a form you can fully rebuild elsewhere. The Monaco download covers configuration, not the metrics, traces and logs your environments collected. Dynatrace documents API access to metrics and entities, which lets you query and extract data, but that is a query path with its own limits and format, not a complete migration of stored history. Plan for historical telemetry to stay in Dynatrace for the retention period it offers, and export only the specific series or reports you need for audit or trend analysis. Confirm query limits and retention settings for your deployment with Dynatrace.
What does a fixed-scope DeployOpen engagement cover for this export?
A DeployOpen engagement is fixed-scope, so the environments, configuration types, deliverables and timelines are agreed in writing before work starts. A typical written scope for this work would cover the configuration inventory, running the Monaco download, reviewing and sanitizing the exported files in version control, rebuilding selected configuration in a test environment, documenting the process, and setting up the archive and access controls. DeployOpen does not issue audit reports or certifications, so evidence prepared for compliance assessments goes to independent auditors. Ongoing support and upgrades are available as retainers. Request a quote based on your written scope.
Should we export before or after deciding on a replacement stack?
Export before the decision is final, because configuration captured now protects you whatever you choose. The archive does not lock you into a replacement, and it helps compare options fairly. Dynatrace ingests OpenTelemetry through its OTLP API, so teams can send the same telemetry to a self-hosted stack in parallel while the DPS commitment runs. Use the archive as a reference for dashboards and alerts you must rebuild, and avoid treating exported Monaco files as a drop-in import into another vendor. Confirm which configuration types map to your chosen stack before cutover.
How to verify the archive is usable after the export
A file being present proves very little. The test that matters is whether someone can use the export without the original environment. For the Monaco configuration files, compare the downloaded set against a reference environment: deploy the files into a non-production Dynatrace environment, then check that the resulting settings, automations, documents, segments and SLO v2 configurations match what the source environment shows. Differences in environment-specific values such as tenant identifiers, owner references or credentials are expected and should be listed in the verification record, not silently accepted. Keep the downloaded files in version control so each diff is traceable to a commit.
For API extracts of metrics and entities, verification means completeness and record counts, not a successful HTTP status. Pick a fixed time window and metric selector, run the same query against the source environment and the extract, and compare counts, timestamps and sample values. Record the query text, the time range, the environment identifier and the time the extract ran, so the same check can be repeated later. Be clear with stakeholders that a Dynatrace API extract preserves what the API returns for the query you ran, and that collected telemetry history for other windows may not be covered by it.
Testing a restore is the step most teams skip. Load the Monaco files into a sandbox Dynatrace environment, and where you plan to rebuild dashboards in Grafana, import a representative set of exported data into a Grafana instance that you run yourself. Grafana provisioning files can be checked into Git and loaded at startup, which makes the rebuilt configuration reproducible. Document the evidence as you go: the verification plan, the run logs, the diff reports, sign-off by the owner of each configuration area, and any gaps accepted in writing. DeployOpen prepares these controls and evidence for your compliance assessment, but independent auditors issue any assessment opinion, so confirm with your auditor which artifacts they expect before you start.
How DeployOpen scopes and delivers a Dynatrace export and exit
DeployOpen starts by inventorying what your Dynatrace environment holds, separating configuration that can be downloaded as Monaco files from telemetry history that usually cannot. We then agree a written, fixed scope for the export, the rebuild on your own infrastructure and the handover, so your team knows exactly what is delivered before work starts.
How we scope
- We inventory Settings 2.0 objects, classic configuration APIs, automations, documents, segments and SLO v2 configurations in your environment.
- We record which dashboards, alerts and API integrations depend on Dynatrace and which can be rebuilt in Grafana and Prometheus.
- The written scope names the export outputs, the self-hosted target environment and the list of what is excluded, such as historical telemetry.
How we build
- We run Monaco download against the source environment and store the resulting configuration files under version control.
- We set up self-hosted Grafana with its provisioning files and a database backend suited to production in your own infrastructure.
- We script API-based extraction of metrics and entity data, then test the output against a sample of known values before cutover.
How we hand over
- We deliver the exported configuration archives, a mapping of each Dynatrace object to its replacement and a list of unrecoverable items.
- We document the restore and re-import steps so your team can repeat them without DeployOpen involved.
- We walk your engineers through the evidence of what was exported, what was rebuilt and what remains only in the old tenant.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing of the self-hosted stack are available as a retainer.
- We can confirm the exported data with your auditors or compliance leads, though independent auditors issue any formal attestations.
