How to export your data from Adobe Analytics before you leave
Before you leave Adobe Analytics, you can export three things: hourly or daily raw data feeds delivered as compressed files to Amazon S3, Google Cloud Platform or Azure, Data Warehouse report exports, and a historical raw hit-level export that Adobe can provide before deletion. Adobe states that data older than the retention policy, 25 months by default, may be deleted with no option for recovery, so anything you do not export in time may be gone. The clock that matters is the retention window on your report suites, not the end date of your contract. If your renewal or retention extension decision lands after data has already aged out, the history you wanted to keep may no longer exist, so confirm your retention setting with your Adobe account team now.
Start with the data feeds, because they are the only route that gives you hit-level detail you can replay into another platform. The column definitions are published in Adobe's data column reference, so your engineers can map the fields to the events and variables you use today. Data Warehouse is better for aggregated reports, with no row limit but a processing time of up to 72 hours. Only administrators can enable it, it works with global and child report suites, and it does not work with rollup report suites, so check your suite structure first. Confirm with Adobe whether the historical raw hit-level export covers every report suite you need and how long it takes to deliver.
Plan the export as a dated project with an owner. Inventory which report suites hold the history you need, confirm who in your organization has administrator access to enable Data Warehouse, pick the cloud storage account that will receive the feeds, and decide how long you need to keep the files after you leave. Set a deadline that is well ahead of the retention cutoff for each suite. The export files will become the input for any migration to self-hosted Matomo, so keep them in a store you control and record the schema version and date range of each batch.
Which Adobe Analytics data you can export and how
This table compares the three documented ways to take data out of Adobe Analytics: scheduled data feeds, Data Warehouse reports and the historical raw hit-level export. Read each row for its format, delivery method and limit, then check which path covers the report suites and years you need before retention runs out.
| Export path | Format and content | Delivery and limits |
|---|---|---|
| Data feeds (hourly or daily) | Compressed files with columns defined in Adobe's data column reference | Hourly batches at the end of each hour, or daily batches, delivered to Amazon S3, Google Cloud Platform or Azure |
| Data Warehouse reports | Report output with an unlimited number of rows | Emailed or sent to cloud storage; processing may take up to 72 hours |
| Data Warehouse email delivery | Same report output as Data Warehouse | Email attachments capped at 10 MB, so large reports need cloud storage delivery |
| Data Warehouse enablement | Requires an administrator-level user in Adobe Analytics | Works with global and child report suites; rollup report suites are not supported |
| Historical raw hit-level export | Hit-level data offered by Adobe before deletion | Available on request from Adobe; confirm scope, format and turnaround with your Adobe contact |
| Default retention window | Data beyond the retention policy may be deleted without recovery | 25 months by default; confirm your contract's retention setting, since it may differ |
What does not export cleanly and what to do about it
The documented export paths cover hit-level data and Data Warehouse reports, but several things an analytics team depends on either do not come out or come out in a different shape. Each card below names one of these gaps, the workaround that usually closes it, and what to confirm with Adobe for your own account before the retention clock becomes the deadline.
Calculated metrics and report configurations
Calculated metrics, virtual report suites, classifications and report layouts live in the Adobe interface and are not included in the hit-level data feed. The feed gives you the raw columns, so the logic that turns those columns into a KPI has to be written down by you. Export the definition of each calculated metric and each classification set, then record the formula in plain language next to the matching column names. Ask Adobe which configuration items, if any, it can provide for your report suites.
Analysis Workspace projects
Analysis Workspace projects, panels and their filter logic are saved inside Adobe and do not come out as data. Treat each project as a specification: list the panels, the metrics and dimensions used, the date ranges and the segments applied. Rebuild the important views from the feed or the Data Warehouse output rather than trying to copy the project file. Confirm with Adobe whether project definitions can be exported for your account and which of your teams own them.
Segments and their logic
Segments define audiences with nested conditions that depend on Adobe's processing, so a segment name tells you little about what it counted. Write each segment's rules out in full, including any sequence or container logic, and note which report suites use it. When you rebuild segments in another tool, test them against a known period in Adobe to confirm the counts match. Ask Adobe how segment definitions can be retrieved for your organization.
Alerts and scheduled dashboards
Alerts, scheduled reports and dashboards that teams rely on for operations are configuration, not data, and they stop when the license or access ends. Inventory every alert with its recipients, threshold and schedule, and check which ones feed other systems. Recreate the important ones from the exported data using your monitoring or BI stack, and confirm the alert history you need to keep before access changes. Ask Adobe which of these can be exported, if any.
Data past the retention policy
Adobe states that data beyond the retention policy, 25 months by default, may be deleted with no option for recovery. Older hits that you did not export are therefore at risk on a fixed schedule, not on the day you cancel. Ask Adobe in writing whether a historical raw hit-level export is available for your report suites, what format it uses and how long it takes to deliver. Start that request early, because the deadline is set by your retention policy.
The sequence for a complete export with verification
This sequence moves Adobe Analytics history out in a order that protects it from the retention deadline, then proves the exported files match what Adobe reports before the contract ends. Each step ends with an output you can check.
Confirm retention policy and data age
Ask your Adobe account team or a report suite administrator which retention policy applies to each report suite, and whether any extension has been bought. Adobe's default is 25 months, after which data may be deleted with no option for recovery. Record the oldest date you still hold for each report suite, and calculate the date by which each slice must be exported. This record sets the order of every later step. It is done when you have a dated table of report suites, policies and oldest data dates, signed off by the data owner.
Enable data feeds and Data Warehouse
Only an administrator-level user can enable Data Warehouse, so ask that person to turn it on for the report suites you need. Confirm that each report suite is a global or child suite, because Data Warehouse does not work with rollup report suites. Set up the data feed for hourly or daily batches and choose the cloud destination: Amazon S3, Google Cloud Platform or Azure. Done when a test batch lands in your bucket and the file opens with the expected compression and column layout.
Request the historical raw export before deletion
Ask Adobe in writing for the historical raw hit-level export for every report suite whose data is older than your retention window or close to it. Adobe states it can provide this before deletion, so the request should be filed early and tracked with a named contact. Request the delivery format and destination in the same ticket. Done when Adobe confirms the request in writing and you hold a delivery reference for each report suite.
Set up cloud storage delivery
Create a dedicated bucket or container with access limited to the engineers who run the export, and enable versioning and encryption according to your own security standards. Point the data feed and any Data Warehouse jobs at this location. Keep a copy of the column reference for the feed version you receive, so later checks compare against the right definitions. Done when every delivery source writes to the bucket and access logs show only approved identities.
Run a backfill window and store files
Run Data Warehouse exports and feed backfills for each report suite and date range, splitting large jobs into smaller windows so each file can be checked. Expect Data Warehouse reports to take up to 72 hours to process, and budget your calendar around that figure. Store files in a folder structure by report suite, date and job, and record the job identifier with each file. Done when every planned window has a job record and a file in storage, and no window is left unexplained.
Verify row counts and column definitions
Compare the number of rows in each file with the row counts Adobe reports for the same period and report suite. Check that the column headers and data types match Adobe's data column reference for the feed version you received, and flag any column that is missing or renamed. Keep a log of every mismatch and its cause. Done when each file has a recorded row count, a column check result and a list of exceptions with an owner for each.
Reconcile totals and store checksums
Generate a checksum for each file when it is stored, and keep the value in the same record as the job identifier. Then reconcile key totals such as visits, page views and revenue per day against the Adobe reports you can still access, and document any gap with its explanation. Repeat the checksum check on a sample of files after storage to confirm nothing changed. Done when every file has a checksum, the reconciliation table shows each total either matching or explained, and the sample re-check passes.
Sign off before the contract ends
Before the contract or retention extension expires, have the data owner, an analytics lead and the security or compliance contact sign a short record. The record should list each report suite, the exported date range, file counts, checksums, unresolved exceptions and where the data will be stored. Confirm with Adobe in writing that no further export is required from the platform. Done when the signed record is filed with the contract records and the exception list has an agreed owner and due step.
Why the 25-month retention deadline sets your timeline
The export clock runs from the oldest data you still hold, not from the day your Adobe contract ends. Adobe's default retention policy is 25 months, and Adobe states that data beyond that window may be deleted with no option for recovery. Each day you wait, the earliest month in your report suites moves closer to that boundary, so the first task is to find out how far back your data actually goes and which part of it is already at risk. Start by confirming your retention setting with your Adobe account team or administrator, because the default may not be what your organization has in place. Then list each report suite and record the earliest date with usable data, using the date range picker in Analysis Workspace as a practical check. Note which suites are global, child or rollup, since Data Warehouse exports do not work on rollup suites. Anything that predates the retention window is a loss you cannot reverse, so prioritize the oldest months first.
Any retention extension beyond the default is a commercial conversation with Adobe, and the terms, cost and duration should be confirmed in writing for your account rather than assumed from this page. Do not treat an extension as your migration plan. Plan the export on the assumption that the default window applies, and ask Adobe whether a historical raw hit-level export is available before deletion, since that option is the one most likely to protect data older than your current window. Build the export schedule from the oldest months forward, and keep a written record of what was exported, when and where it was stored.
What to plan before the Adobe Analytics renewal or termination
The export itself is the easy part. The decisions around it set how much history you keep, who can request and hold the files, and where they sit afterward. Work through these before the notice date, because the retention clock in your Adobe contract, not the migration project plan, sets the deadline.
How far back history must go
Decide which years of hit-level data you need for year-over-year comparisons, audits and regulatory records. Adobe's default retention is 25 months, and data beyond that policy may be deleted with no option for recovery. Ask Adobe whether your contract changes that default and whether a historical raw hit-level export is available before deletion. Confirm the exact scope and format with your account team in writing.
Which exports to request now
Choose between hourly or daily raw data feeds and Data Warehouse report exports. Feeds deliver compressed files with columns defined in Adobe's data column reference, to Amazon S3, Google Cloud Platform or Azure. Data Warehouse reports can be large and may take up to 72 hours to process. Request both where they differ, and start the longest-running export first.
Who holds administrator rights
Only administrator-level users can enable Data Warehouse, and that setup determines who can change report suites and exports. Name the individuals who will configure, approve and monitor exports before the notice date, and record who can grant or revoke access. Confirm that your report suite types are supported, because Data Warehouse works with global and child report suites but not rollup report suites.
Where exported files will live
Exported files contain visitor-level behavior, so they need the same controls as other personal data. Decide which cloud bucket or storage account receives them, who can read and delete objects, how access is logged, and how long copies are kept. Set retention and encryption rules on the storage location before the first export runs, not after.
Whether data residency is required
Check whether your data protection obligations limit where analytics data is stored or processed. Adobe feeds can land in S3, Google Cloud or Azure regions you select, while a self-hosted platform keeps data where you run it. Review the data transfer basis for any US-based processing with your privacy team. The EU-US Data Privacy Framework adequacy decision applies only to participating companies, so confirm participation with each vendor.
What happens to props, eVars and tags
Inventory the Adobe implementation before exporting: props, eVars, events, classifications, processing rules and the tags that send them. Column definitions in the feed tell you how each variable was recorded, which is the basis for mapping them to a new schema. Decide whether the replacement will be rebuilt from scratch or mapped, and document the tag manager changes that go with it.
Contract terms to confirm with Adobe
Notice periods, renewal mechanics, retention extensions and the cutoff for data access are set in your Adobe agreement, and this page cannot state them. Ask Adobe in writing for the notice date, the date after which data may be deleted, the export options included in your contract and any fees for extra export or retention. Build the project timeline backward from those answers.
Questions buyers ask before exporting Adobe Analytics data
How long does a full Adobe Analytics export take?
The duration depends mainly on how much history you need, how many report suites you export, and which delivery path you choose. Data feeds arrive as compressed files in hourly batches at the end of each hour or as daily batches, so a long history is a matter of how many batches Adobe must deliver and how quickly your storage and loading jobs can absorb them. Data Warehouse reports can include an unlimited number of rows, but they may take up to 72 hours to process, so plan for that lag before any report is usable. Ask Adobe in writing for the expected delivery window for your own report suites and volume, and confirm it against the retention date that applies to your account.
Can our own team export the data without a partner?
Often yes, but the work needs specific access and time from people who know the implementation. Only administrator-level users can enable Data Warehouse in Adobe Analytics, so confirm early who holds that role. Data Warehouse works with global and child report suites but not rollup report suites, so check which suites you use before you request exports. Your in-house analysts will also need time to validate row counts, decide which props, eVars and events to keep, and check results against reports they already trust. If that capacity is not available, a partner can take on part of the work under a written scope.
What do we need in place before the export starts?
You need three things: a cloud storage destination, a named owner, and a column mapping plan. Data feeds deliver to Amazon S3, Google Cloud Platform or Azure, so decide which provider your organization already governs and set up the bucket, access policies and retention on it. The named owner should approve who can read the files and who signs off on completeness. The column mapping plan links Adobe's data column reference to your target schema, so the team can see which columns become Matomo custom dimensions, goals or raw event fields. Without that mapping, the files arrive but cannot be replayed reliably.
Should we hire a partner to run the export, and what does that cover?
A partner is worth considering when your team lacks administrator access, analyst time or experience with raw hit-level data. DeployOpen works on fixed-scope engagements, where scope, deliverables and timelines are agreed in writing before work starts. In that scope, DeployOpen can plan the export, set up the storage destination, define the column mapping, run the transfer and document the result. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the deliverables, the acceptance checks for completeness, and what happens if Adobe's delivery takes longer than planned.
What does Adobe retention mean for our export deadline?
Adobe states that data beyond the retention policy, 25 months by default, may be deleted with no option for recovery. That makes the retention date the real deadline, not the date you decide to leave. Adobe also states it can provide a historical raw hit-level export before deletion, so ask whether that export is available for your report suites and how long it takes to deliver. Confirm your own retention setting in your contract or account, because a non-default policy changes the calculation. Start the export with the oldest data that would be lost first.
What should we ask Adobe to confirm in writing?
Ask Adobe to confirm, in writing, the retention period that applies to your organization, the report suites covered, and whether any suites are rollup suites that Data Warehouse cannot export. Request the historical raw hit-level export terms, including format, delivery method, size limits and the date after which it is no longer available. Ask which data feed columns are included, and where the data column reference applies to your implementation. Also confirm who at Adobe owns the request and how exceptions are handled. Keep the answers with your contract records so the migration plan rests on documented facts.
What breaks if we export only the aggregated reports?
Aggregated reports lose the hit-level detail that most analysis depends on. Data Warehouse reports can give you summarized tables, but they cannot recreate every segment, path or visitor view that Adobe users build in Analysis Workspace. If your team relies on segment logic, attribution or custom event sequences, export the raw data feeds as well, because they keep the hit-level records. Test a sample month early and compare totals with the reports your stakeholders already use. Mismatches found during the test are much cheaper to resolve before the full history is loaded.
What to do with the files once they are out
Exported Adobe Analytics feeds are raw hit-level files, not a ready-to-load history. Each row is one hit, and the columns follow Adobe's data column reference, so the first job is to map those columns to the fields your target platform expects. Page name, visit identifiers, timestamps and the variables that carried your props and eVars all need a decision: which columns become pageviews, which become custom dimensions or events, and how visits are reconstructed from hits. Treat that mapping as a document you own, and have an analyst sign off on it before any data is loaded.
Getting files out of Adobe and getting history into a self-hosted platform are separate steps. Replaying archived hits into Matomo, for example through its bulk Tracking API, is a project in its own right, with its own validation, deduplication and reconciliation against Adobe totals for the same period. The Google Analytics Importer and Plausible's GA4 import both bring in aggregated report data only, so Visitor Log, segmentation and other raw-event features will not work on that history. If you want those features across the past, the raw archives are the only basis for rebuilding it. Confirm with your analytics lead which reports and segments must survive the move before you decide how much history to replay. For the step-by-step path, see the migration guide in this hub, which covers replaying raw history and switching tags, along with the cost page that sets out who does this work and what recurs afterward. Keep the exported files in encrypted storage under your own control, record where each copy lives, and set a deletion date for working copies so that the archive does not become a second, unmanaged data store.
How DeployOpen scopes and delivers an Adobe Analytics data exit
DeployOpen plans and implements the export as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts. We set up the export pipeline inside your own cloud account or data center, then document and hand it over so your team can run it after the engagement ends.
How we scope
- We inventory the report suites, data feed or Data Warehouse jobs, and historical raw export you need before the retention deadline.
- We confirm which cloud target applies, Amazon S3, Google Cloud Platform or Azure, and who controls the storage account.
- The written scope names the export deliverables, the test criteria, and the handover items, with timelines agreed before work starts.
How we build
- We configure hourly or daily data feeds and Data Warehouse report schedules, with delivery paths that fit your storage and access rules.
- We validate exported files against Adobe's column reference and check row counts against reports in Analysis Workspace.
- We document the retention status, file layout and any gaps, so the migration team knows what history exists and what is missing.
How we hand over
- We deliver runbooks covering export schedules, storage locations, access roles and how to re-run a failed batch.
- We provide an evidence pack showing what was exported, when, and which checks passed, for your records and any compliance review.
- Your team receives a walkthrough of the pipeline, so administrators can operate it without depending on the original build.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work closes.
- Retainers can cover monitoring of recurring feed deliveries and fixes when Adobe changes column definitions or delivery behavior.
- Ask for the support terms, response expectations and retainer scope in the written quote before committing to the exit.
