---
id: "revenuecat-support/common-tickets/export-data-or-migrate-away"
title: "Export data or migrate away from RevenueCat"
description: "RevenueCat provides self-service exports for transaction history, Customer state, and chart results. Migrating subscriptions to another provider usually requires a separate, Support-prepared export with store identifiers that aren't available in self-service exports."
permalink: "/docs/revenuecat-support/common-tickets/export-data-or-migrate-away"
slug: "export-data-or-migrate-away"
version: "current"
original_source: "docs/revenuecat-support/common-tickets/export-data-or-migrate-away.mdx"
---

> **AI agents:** This is the Markdown version of a RevenueCat documentation page. For the complete documentation index, see [llms.txt](https://www.revenuecat.com/docs/llms.txt).

RevenueCat provides self-service exports for transaction history, Customer state, and chart results. Migrating subscriptions to another provider usually requires a separate, Support-prepared export with store identifiers that aren't available in self-service exports.

Confirm the destination provider's import requirements before requesting migration data. A report that works for analysis may not contain the identifiers needed to continue validating and tracking subscriptions.

## Choose an export

### Transaction-level reporting

Use [Scheduled Data Exports](https://www.revenuecat.com/docs/integrations/scheduled-data-exports) when you need transaction-level data in your own storage or analytics system. The Transactions feed includes fields for revenue, Products, stores, App User IDs, subscription periods, refunds, and store transaction identifiers such as Google Play order IDs.

Scheduled Data Exports can run repeatedly and send new or updated transaction rows. Use this option for an ongoing data pipeline or a detailed transaction archive.

Scheduled Data Exports don't include raw Google Play purchase tokens. If your destination needs purchase tokens or another store-specific value that isn't in the Transactions feed, request a migration export from RevenueCat Support.

### Customer-level state

Use an [Audience export](https://www.revenuecat.com/docs/dashboard-and-metrics/audiences#exporting-data) when you need one row per Customer with their current purchase and Entitlement state. Audience exports can include App User IDs, active Products, Entitlements, subscription status, total spent, and Customer Attributes.

Audience exports are useful for customer segmentation, account records, and operational handoffs. They don't replace a complete transaction history or a store-identifier export.

Export Customer Attributes through Scheduled Data Exports or an Audience export when your destination needs them. A Support-prepared store migration file doesn't automatically include reserved or custom Customer Attributes.

### Aggregated chart results

Use a [Chart CSV export](https://www.revenuecat.com/docs/dashboard-and-metrics/charts#exporting-data) when you need the aggregated values behind a specific chart view. The export reflects the chart's selected date range, measure, resolution, filters, and segments.

To retrieve chart results programmatically, use the [Charts and Metrics endpoints in Developer API v2](https://www.revenuecat.com/api-v2). The API supports chart-specific date ranges, resolutions, filters, and segments.

Chart exports are useful for analysis and reconciliation. They don't contain the receipt or purchase-token data required to migrate active subscriptions.

### Subscription migration data

Migrating subscriptions to another provider may require Apple original transaction identifiers, Google Play purchase tokens and Product identifiers, Stripe subscription identifiers, or another provider-specific field. The required columns depend on the destination provider and store.

For example, a destination may require these mappings:

- **App Store:** App User ID and Apple original transaction identifier
- **Google Play:** App User ID, raw Google Play purchase token, and Google Play Product identifier

Before requesting migration data:

- Ask the destination provider for its current import schema, required identifiers, and exact column names.
- Identify every RevenueCat project, app, and store included in the migration.
- Specify whether you need production data only or sandbox data too.
- Specify whether you need all available history or a date range.
- List any additional data, such as Customer Attributes, that must remain mapped to each App User ID.
- Ask the RevenueCat project owner to submit or approve the request. Support may require owner confirmation before sharing sensitive data with another collaborator.

[Contact RevenueCat Support](https://app.revenuecat.com/settings/support) to request the migration export. Include the project IDs, apps, stores, destination provider, import documentation, required columns, environments, and date range. Support typically shares these files through an access-controlled location with time-limited access.

:::info[Store purchase data is sensitive]

Treat receipts, purchase tokens, and transaction identifiers as sensitive customer data. Store and share migration files only through access-controlled systems.

:::

:::danger[Export and validate before deleting]

Don't delete a RevenueCat project or account before Support delivers the migration files and the destination provider validates them. Project deletion is irreversible and may prevent RevenueCat from preparing or correcting the export.

:::

## Prepare for an external migration

Keep RevenueCat connected until the destination provider can validate imported subscriptions and your released app uses the new system. Stopping RevenueCat first can create a gap where neither system receives current subscription updates.

Test the migration with a representative sample from each store before processing the full dataset. Validate the App User ID mapping and confirm that the destination provider recognizes active, expired, trial, billing-issue, and canceled subscriptions as expected.

After the destination is ready:

- Release the app changes required by the new provider.
- Stop backend receipt or purchase-token submissions to RevenueCat.
- Disconnect store notifications and other purchase-ingestion paths when appropriate.
- Follow [Stop tracking revenue](https://www.revenuecat.com/docs/revenuecat-support/common-tickets/stop-tracking-revenue) if you want to preserve your RevenueCat project without recording new purchases.

:::warning[Older app versions may still rely on RevenueCat]

Removing RevenueCat from a new release doesn't update versions already installed on Customer devices. Before disconnecting or deleting the project, account for older versions that may still use RevenueCat to check Entitlements, make purchases, or restore purchases.

:::

If you're moving purchases into another RevenueCat project, follow [Merging RevenueCat Projects](https://www.revenuecat.com/docs/revenuecat-support/common-tickets/merging-projects) instead.

## Next steps

- Review [Scheduled Data Exports](https://www.revenuecat.com/docs/integrations/scheduled-data-exports)
- Review [Audience exports](https://www.revenuecat.com/docs/dashboard-and-metrics/audiences#exporting-data)
- Learn how to [stop tracking revenue](https://www.revenuecat.com/docs/revenuecat-support/common-tickets/stop-tracking-revenue)
