How to export data from Datadog before your contract ends
If your Datadog renewal, pricing change or residency review is coming up, know now what can leave the platform. Logs can be archived as compressed JSON to your own Amazon S3, Azure Storage or Google Cloud Storage bucket through Log Archives. Dashboard definitions can be exported as JSON through the API. Metrics and traces have no documented bulk export, so plan to rebuild or re-ingest those rather than expect a file from Datadog.
Log Archives forward all ingested logs, whether indexed or not, to a bucket you own. Datadog writes them as zstd (.json.zst) by default or gzip (.json.gz), in date-based paths of the form /prefix/dt=YYYYMMDD/hour=HH/. Creating or changing an archive requires the logs_write_archive permission, so confirm which role your team holds before the review starts. Check the bucket's storage class, lifecycle rules and retention with your cloud team, because archived history will accrue storage charges for as long as you keep it. Read the Datadog Log Archives documentation before you configure anything, and confirm the current behavior for your site.
Plan the export as a dated inventory: list every dashboard, archive, monitor and integration, record which are exported and which must be rebuilt, and set a cutoff date. Ask Datadog's account team in writing what they will provide in bulk and at what cost, so the answer is on file before the contract decision. Run a test archive and a dashboard export into your own storage well before the end date, because the metrics and traces you cannot export will need a parallel pipeline such as OpenTelemetry running alongside Datadog.
Which Datadog data you can export and how
This table compares each Datadog data type against the export route, output format and documented requirements. Read it to separate what you can pull out in bulk today from what needs a rebuild or a parallel collection path. The main takeaway is that log archives and dashboard JSON can leave Datadog, while metrics and traces have no equivalent bulk export and must be recreated from your own instrumentation.
| Data type | Export method | Format and layout | Requirements and what to confirm |
|---|---|---|---|
| Ingested logs (indexed or not) | Log Archives to your own Amazon S3, Azure Storage or Google Cloud Storage bucket | Compressed JSON, zstd (.json.zst) by default or gzip (.json.gz), in /prefix/dt=YYYYMMDD/hour=HH/ paths | Archives forward all ingested logs to your bucket; confirm with Datadog how archive coverage applies to your plan and retention |
| Log archive configuration | Created and edited in Datadog Log Configuration | Archive settings in the Datadog account | Requires the logs_write_archive permission; assign it only to administrators who manage archives |
| Dashboard definitions | Datadog API export of dashboard JSON | JSON definition per dashboard | Useful as a reference for rebuilding in Grafana; confirm the API keys and scopes your organization needs |
| Monitors and alert definitions | Datadog API export of monitor configuration | JSON definition per monitor | Translate thresholds and query logic by hand into alert rules; confirm the exact API endpoints and fields for your account |
| Infrastructure metrics | No documented bulk export of raw metric history | Not provided as a bulk file | Plan a parallel OpenTelemetry or Prometheus collection path and accept a history gap unless you query and store points yourself |
| APM traces | No documented bulk export of trace data | Not provided as a bulk file | Start OpenTelemetry tracing into Jaeger or another backend in parallel; historical traces stay in Datadog until retention ends |
| Archived logs after export | Your own object storage | Compressed JSON files you own | Loki and other backends need a separate load step; confirm the ingest path and schema with the target platform before cutover |
What Datadog does not export in bulk, and the workarounds
Log Archives and dashboard JSON give you a partial copy of your Datadog estate, not a full one. Metrics, traces, the backend itself and several configuration objects have no documented bulk export, so each gap needs a workaround and a question to put to Datadog before you set a cutover date.
Metrics have no bulk export
The sources do not document a bulk export of metric time series out of Datadog. Your historical data stays in Datadog until its retention window ends, so the practical choice is to keep the commercial account active through an overlap window while the new Prometheus or OpenTelemetry metrics build their own history. Ask Datadog whether it offers any supported way to pull raw series at scale, what query limits apply to API reads, and how long metrics stay queryable after you stop sending data.
Traces have no bulk export
Distributed traces are not included in Log Archives and the sources do not document a bulk trace export. Plan for dual-shipping OpenTelemetry traces to Jaeger or SigNoz from the cutover date forward, and accept that the historical traces you need for incident reviews stay in Datadog. Confirm with Datadog which trace data can be retrieved through its API, how far back it is queryable, and whether any archive option is planned.
Backend and UI are closed
The Datadog Agent is open source, but the Datadog backend and UI are not. You cannot export the data model, query engine or user interface, so anything you want to keep must leave as data through Log Archives, API responses or your own telemetry pipeline. Treat the backend as a service you consume until cutover, and confirm the contractual terms for data return and deletion at the end of your subscription.
Monitors and notebooks
The sources do not document a bulk export for monitors or notebooks. Monitor definitions are available through the API on a per-object basis, so export them one at a time into version control, then rebuild each as a Prometheus or Grafana alert rule and check it against the Datadog evaluation history. Notebooks usually need manual rebuilding from documentation, and you should confirm with Datadog which notebook content the API returns.
Saved views and pipelines
Log saved views, facets and log pipeline processors are configuration, not archived events, so Log Archives do not carry them. Export the definitions you still rely on through the API, record each facet and parser rule in your own configuration, and recreate them in Loki or your log platform. Ask Datadog for the exact API endpoints available for your account and whether any saved view state is recoverable after you disable a feature.
Access control and user data
Role assignments, team membership, API key metadata and audit history are not in the log archive and are not documented for bulk export. Record who owns each dashboard and monitor before cutover, because this information will not travel with the data. Confirm with Datadog which audit and access records you can retrieve and for how long they remain available.
How each export path works in practice
Log Archives are the documented route for keeping Datadog log history. They forward all ingested logs, whether indexed or not, to a storage bucket you own, so the archive is a copy of what the platform received rather than a view limited to indexed logs. Setup starts with the destination: you choose Amazon S3, Azure Storage or Google Cloud Storage, and whoever creates or changes the archive configuration needs the logs_write_archive permission in Datadog.
- Destination permissions: Datadog must be allowed to write to the bucket you name, so confirm the cloud role or identity it uses and who approves that grant.
- Date-based layout: Files land under your prefix in paths of the form
/prefix/dt=YYYYMMDD/hour=HH/, which makes date-range restores and lifecycle rules straightforward to define. - Compression format: Output is compressed JSON, zstd (
.json.zst) by default or gzip (.json.gz), so confirm your replay tooling reads the format you choose. - What the archive contains: Each file holds the full structured log events, including attributes and tags, which is what you need to reload history into a new store.
- Retention outside Datadog: The bucket's lifecycle rules, not Datadog, now govern how long history is kept and what it costs to store.
Before cutover, confirm with your own team that the archive captures the fields your queries and compliance evidence depend on, and test one restore end to end.
Dashboard definitions can be read through the Datadog API as JSON. This export does not move data, only the layout, queries, widget types and template variables that describe each dashboard. Treat the JSON as a specification for rebuilding views in the new stack rather than as an importable file, because the query language and panel model differ between platforms.
- Bulk retrieval: Pull every dashboard definition through the API with a credential scoped to read dashboards, and store the JSON under version control.
- Reference for rebuilds: Map each widget's queries to PromQL or LogQL, then recreate the panel in Grafana.
- Provisioning in Grafana: Once rebuilt, dashboards and data sources can be defined in YAML or JSON files loaded at startup, so the new layout is reproducible across environments.
- Variables and links: Template variables, drill-down links and dashboard-to-dashboard references usually need manual rework.
- Ownership check: Ask each dashboard owner which views they rely on in incidents, since the exported JSON does not show how people actually used them.
Confirm with your team which dashboards are still in use before exporting, so you rebuild the working set and archive the rest.
Datadog offers no bulk export for metrics or traces. You cannot download a full history of time series or spans and load it into Prometheus or another backend, so the history you keep is whatever your new platform collects from the cutover date onward, plus any data you took from Datadog's own query results. Plan for this loss explicitly rather than assuming the archive covers it.
- History loss: Metric and trace history stays in Datadog's retention window, so define how long you need Datadog access to answer questions about past incidents.
- Overlap window: Run OpenTelemetry instrumentation or a Collector pipeline to both Datadog and the new backend in parallel, so alerts can be compared before the switch.
- Query snapshots: For compliance or capacity baselines, export specific query results on a schedule through the API while the subscription is active.
- Cutover timing: Agree with stakeholders how long the overlap should run, and keep the Datadog account active until you have confirmed the new alerts behave as expected.
- Contract review: Ask Datadog in writing what data access remains after you stop paying, including any export or read-only options.
Before committing to a cutover date, confirm the overlap length, the snapshot scope and the contractual access terms with the vendor.
The export sequence and how to verify each step
This sequence turns Datadog data into a set you hold: an inventory of what matters, archived logs in your own bucket, dashboard definitions as JSON, and a parallel telemetry feed to the replacement. Each step closes with a check you can repeat before cutover.
Inventory data sources and assign owners
Before exporting anything, list the Datadog data your teams depend on: log indexes and pipelines, dashboards, monitors, APM services, custom metrics and synthetic tests. Assign a named owner to each item and note whether it is needed for history, for live alerting or for both. Confirm the list with the service owners, not only the platform team. The step is done when every item has an owner, a retention need and a target replacement or a documented decision to retire it.
Confirm the Datadog site and permission holder
Record which Datadog site the organization uses, such as US1, EU1 or another listed regional site, because each site is independent and data cannot be shared across sites. Identify the account holder who has the logs_write_archive permission, since creating or modifying log archive configurations requires it. Check the site in the Datadog URL or account settings and confirm the permission in the role configuration. The step is done when the site and the named permission holder are written into the migration record.
Create the log archive in your own bucket
Using the permitted account, create a Log Archive that points to a bucket you control in Amazon S3, Azure Storage or Google Cloud Storage. Set the storage access so that only the designated archive and reader roles can write or read, and choose the compression format, zstd (.json.zst) by default or gzip (.json.gz). Confirm that the bucket has versioning or object protection that your policy requires. The step is done when a test day of archived logs appears in the bucket and the access policy has been reviewed by the security owner.
Export dashboard definitions as JSON
Use the Datadog API to retrieve each dashboard definition in scope and store the JSON in version control, using the inventory from the first step as the list. Keep the exports as a reference for rebuilding panels in Grafana, not as a direct import, because queries and widget types must be translated by hand. Note any dashboards that depend on Datadog-only functions. The step is done when every dashboard in the inventory has a stored JSON file and a row in the tracking sheet marked as exported or retired.
Start dual-shipping telemetry to the replacement
Instrument or reconfigure services with OpenTelemetry so the same traces, metrics and logs can flow to Datadog and to the self-hosted backend in parallel. Datadog accepts OTLP through the Agent, a standard OpenTelemetry Collector pipeline or direct ingestion, so the Collector is usually the simplest split point. Metrics and traces have no bulk export from Datadog, so the parallel feed is the only way to build their history on the new side. The step is done when both destinations show the same services and the difference in volume is explained.
Check archive completeness against expected paths
Compare the archived objects with the expected date-based paths of the form /prefix/dt=YYYYMMDD/hour=HH/ for each day and hour in the archive window. List any gaps, then compare the event counts in a sample of archived files with the counts in Datadog for the same time range. Investigate missing hours before accepting the archive as complete. The step is done when every expected hour is present or the gap has a documented cause and an owner.
Store the migration evidence
Collect the evidence that the export and cutover steps happened as recorded: the archive configuration, the permission holder, the bucket access policy, the dashboard JSON files, the completeness report and the dual-shipping configuration. Store these in a restricted, version-controlled location with the approval record. Ask your auditor or compliance lead which evidence they will request, because DeployOpen prepares evidence but independent auditors and certification bodies decide what is sufficient. The step is done when an outside reviewer can trace each claim in the migration record to a stored artifact.
Verifying that archived logs are complete and readable
Before you treat a Log Archive as your copy of record, check that every expected partition exists. Datadog writes archives into date-based paths of the form /prefix/dt=YYYYMMDD/hour=HH/, so list the bucket for each day in the retention window and compare the dt and hour folders against the window you expect logs to have been ingested. A missing hour is the most common sign of a gap, and it is worth checking it against the time range of your ingestion outages, deployments and agent upgrades. Confirm the archive's destination, prefix and storage account in the Log Archives configuration, because a misconfigured prefix can make a healthy archive look empty to the team reading it.
Next, confirm that the files decompress cleanly. Datadog writes zstd (`.json.zst`) by default and gzip (.json.gz) as the alternative, so run the decompressor that matches the file extension on a sample of objects from several days and from both the start and end of a day. Then sample records and check that they are valid JSON, one event per line, and that the fields your dashboards and queries depend on, such as timestamp, service, host and status, are present and populated. Record the checks and their results in a runbook, because auditors and incident reviewers will ask how you established completeness.
Finally, test the read path into the store you plan to use. Loading archived JSON into a target platform is a separate project with its own schema mapping, indexing and cost, so a successful decompression test does not prove that the data can be queried. Ask the team to confirm whether the archives cover logs ingested before the archive configuration was created, since Log Archives forward logs from the point the archive is set up and history before that point may need a different source. Document that answer with the retention period you need, so the gap is known rather than discovered during an investigation.
What to plan before the Datadog renewal or termination
Exporting from Datadog is mostly a scheduling and ownership problem. Log archives, dashboard JSON and the target store each need lead time, and the contract sets the window you have to use them. The cards below cover the items to settle before the renewal date or the termination notice.
Archive setup lead time
Configure the Log Archive and confirm that objects land in your bucket before you rely on it. Start this early enough that you can compare a few days of archived output against what you expect in Datadog. Check that the archive covers every index and source you need, because history that was never archived cannot be recovered from Datadog later. Ask Datadog to confirm what is included before the overlap window begins.
Overlap window before contract end
Plan a period in which Datadog and the target stack both receive the same telemetry. Keep that window open until dashboards, monitors and alert routing have been checked in the new system. Agree the exact end date with Datadog in writing, since access to the console and the archive may stop with the subscription. Treat the overlap as a recurring cost in your budget, not a one-time item.
Bucket retention you will own
Once logs are archived, you pay for storage, lifecycle rules and deletion in your own cloud account. Decide how long each prefix must be kept based on your legal and internal retention rules, then set lifecycle policies on the bucket to match. Confirm who can read, replicate or delete archived objects, and that encryption and access logging meet your standards. Archived JSON is only useful if it is still there when someone needs it.
Target log store retention setting
Loki keeps logs indefinitely until retention is enabled, so a new deployment can grow without limit if you skip this step. Set retention_enabled on the compactor and define retention globally, per tenant or per stream selector, keeping in mind that each stream rule must be at least 24 hours. Decide whether you will load archived history into the new store or keep it only in the bucket, since that choice changes storage sizing.
Target deployment mode and its limits
Loki offers monolithic, simple scalable and microservices modes, and the monolithic mode is documented for up to about 20 GB of logs per day. Simple scalable mode is being deprecated and will be removed with Loki 4.0, so a new build should be planned around the microservices mode or a supported successor. Size your daily ingest from the Datadog usage reports before choosing a mode, and confirm the current guidance with Grafana Labs before committing.
Who holds the archive permission
Creating or changing a log archive requires the logs_write_archive permission in Datadog. Identify which named administrators hold it, and make sure the person who sets up the export is not the only one who can change it. Record who has access to the cloud account, the bucket policy and the Loki tenant configuration, so that an export can be repaired without waiting for a single person. Review these grants again before termination.
Contract terms on data return
Before signing a renewal or serving notice, ask Datadog in writing what data it returns, in what format, within what period and at whose cost. Confirm whether metrics, traces and dashboard definitions can be exported beyond what the product exposes, since bulk export of metrics and traces is not available in the same way as logs. Also confirm the Datadog site where your data is held, because each regional site is independent and data cannot be shared across sites. Have counsel review the answers.
Questions teams ask before exporting from Datadog
How long does a full export from Datadog take?
The duration depends mainly on how much history you need and how you move it, so no single timeline applies to every account. Log Archives write continuously once configured, which means logs only start landing in your bucket from the point the archive is set up. Dashboard definitions are small JSON files and can be exported quickly through the API. The main drivers are the volume of archived logs, the number of dashboards and monitors to rebuild, and how many people review the output. Ask any partner to base its timeline on a sample of your own accounts and to state the assumptions in writing.
Can our own team export from Datadog without outside help?
Yes, a team with cloud and Datadog administration skills can configure Log Archives and export dashboard JSON on its own. The configuration itself is a bounded task, but the surrounding work is not: creating archive destinations, setting IAM permissions, and checking that files land in the expected paths. Creating or modifying log archive configurations requires the logs_write_archive permission, so confirm that the people doing the work hold it. Many teams keep the export in-house and bring in help only for rebuilding alerts and dashboards on the new platform.
What access and staff time does the export need from our cloud accounts?
You need someone who can create a bucket in Amazon S3, Azure Storage or Google Cloud Storage, grant Datadog the write access the archive requires, and manage retention and encryption settings for that storage. Datadog writes compressed JSON, zstd (.json.zst) by default or gzip (.json.gz), into date-based paths of the form /prefix/dt=YYYYMMDD/hour=HH/. Your security team should review who can read that bucket, since archived logs can contain sensitive data. Confirm the bucket location, encryption, access logging and lifecycle rules before the first archive is written.
Can we recover historical metrics and traces from Datadog?
Log history can be recovered because Log Archives forward all ingested logs, whether indexed or not, to storage you own. Metrics and traces have no bulk export path in the documented Datadog features, so historical values generally stay in Datadog. Dashboard and monitor definitions can be exported as JSON, which preserves the design but not the underlying data. If you need long-term metric history on the new platform, plan a dual-running period and confirm with Datadog what export options your contract includes. Start the Log Archive early, because logs cannot be backfilled from before it was configured.
What does a consultant or implementation partner do, and what should be in a written quote?
A partner typically plans the export, configures the archive and bucket, scripts the dashboard JSON export, and rebuilds monitors and dashboards on the new platform. DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts, and it does not publish a price list. Ask for the list of systems in scope, the archives and dashboards included, the validation steps, what is handed over, and which items are excluded, such as metric history. A quote should also name the assumptions about your environment and who performs each task.
What costs recur in the storage bucket and the target platform after the export?
Two cost lines continue after the export finishes: the object storage that holds archived logs and the platform that receives new telemetry. Storage charges accrue for as long as you keep the files, so retention rules matter most. On the target side, Loki stores compressed chunks and its index in object storage and applies retention only when it is enabled, so logs are kept indefinitely until you set it. Compute and staff time for upgrades and backups also recur. Ask for a model that separates one-time migration work from monthly storage, compute and support costs, and confirm your retention periods before you size either one.
Which files should we check first to confirm the export is complete?
Check that date-based folders are present for every day in your retention window, that the compression format matches your setting, and that file counts and sizes look consistent from one hour to the next. Compare a sample of archived events with the same time window in Datadog. Then confirm that dashboard JSON exports parse and match the number of dashboards you expect. Write these checks into the handover so that someone other than the author can repeat them later.
How DeployOpen scopes and delivers a Datadog data export
DeployOpen approaches a Datadog data export as a fixed-scope engagement: we first confirm which data your organization needs to keep, then build the archive path, verify the output and hand over documented runbooks. The work runs inside your own cloud accounts or data centers, so the exported logs, dashboard definitions and reference files stay under your control.
How we scope
- Inventory the Log Archive destinations, log indexes and retention needs you expect to keep after leaving Datadog.
- Confirm which bucket provider (Amazon S3, Azure Storage or Google Cloud Storage) and which regions your data policy allows.
- Agree in writing which dashboard JSON, monitor definitions and metric or trace references are in scope, and which are excluded.
How we build
- Configure log archives with the logs_write_archive permission held by a named, approved administrator.
- Set up the destination storage with access controls, encryption and lifecycle rules agreed with your security team.
- Test restores of a sample archive partition, checking zstd or gzip decompression and the dt=YYYYMMDD and hour=HH path layout.
How we hand over
- Deliver a runbook covering archive configuration, bucket permissions, folder structure and how to read the compressed JSON.
- Provide an export inventory listing every dashboard JSON file, its source Datadog site and the date it was pulled through the API.
- Document known gaps, including metrics and traces that have no bulk export, so your team can plan rebuilds separately.
How we support
- Ongoing support, upgrades and periodic export checks are available as a retainer after the handover.
- Re-verify archive delivery and storage access when your Datadog site, cloud account or retention policy changes.
- Confirm with your compliance lead which evidence of the export your auditors will need, since DeployOpen prepares records but does not issue audit reports.
