Quasa
Use QUASA App
Join the pioneer of Web3 crypto freelancing today!
Open
Creator Tools & Economy

Export Your Paying Audience Before Moving Platforms—CSV Is Only Step One

|Author: QUASA Editorial Team|5 min read| 6
Export Your Paying Audience Before Moving Platforms—CSV Is Only Step One

Before moving a paying audience, export the complete subscriber list, preserve the original file, and create separate working segments for active, canceled, payment-exception and suppressed contacts. Map each record’s access, billing and communication status before importing anything into the new platform.

A successful CSV download is only the first step. It does not prove that the destination can interpret every source status, preserve consent evidence, exclude unsubscribed contacts or reproduce the correct access and billing outcome.

1. Capture the source data before changing it

Patreon and Substack audience exports preserved as a master file and status-specific snapshots.

Take the final exports as close as practical to a migration freeze, after pausing avoidable changes to subscriptions and campaigns. Keep each original file unchanged in a restricted archive, and record its export time, applied filters and selected columns.

On Patreon, open Creator studio, select Audience and use Relationship Manager. Patreon’s export instructions allow creators to filter contacts by criteria including paid or free membership, active or canceled status and declined payments; the resulting CSV contains all contacts matching the applied filters.

Export an unfiltered master file first, then any filtered snapshots needed for reconciliation. On Substack, open Subscribers, find All subscribers and select Export from the menu above the table; Substack’s subscriber guidance offers a CSV containing either all columns or only the visible columns. Choose all columns for the archival copy, even if the destination accepts fewer fields.

2. Build one canonical migration table

Never clean or transform the only copy of an export. Duplicate it, assign a migration batch ID and build one canonical table in which every source column is mapped, deliberately excluded or retained for audit.

The available fields differ by platform, but the working table should account for:

  • a stable source contact or membership ID and a normalized email address;
  • the original paid, free, active, canceled, declined, refunded or other status;
  • tier or plan, amount, currency and billing frequency where supplied;
  • join, cancellation and access-end dates, plus relevant charge dates;
  • the source, date and scope of communication permission when recorded;
  • unsubscribe, objection, deletion or other suppression state;
  • the destination contact ID and final import outcome.

Retain the original status in its own column and add a separate mapped-status column. That keeps the transformation reviewable and prevents an unfamiliar or blank source value from silently becoming an active subscription.

3. Keep access, billing and communication status separate

Canceled, renewing, failed-payment and refunded memberships mapped to separate access and billing states.

A subscriber’s right to paid content, next billing action and eligibility to receive marketing are different questions. A single field called “subscriber status” cannot safely answer all three.

The distinction matters when memberships are canceled or payments fail. Patreon’s Relationship Manager definitions say a canceled member keeps access until the current billing period ends and appears as Canceled from the date that access expires; the same page distinguishes active, retrying, failed, refunded and fraudulent payment states.

Create operational segments such as active and renewing, canceled with access remaining, canceled and expired, payment retrying, payment failed, refunded and free. For each segment, specify whether the destination should grant access, create or schedule billing, import the person without a paid entitlement, hold the record for review or exclude it.

4. Preserve consent evidence and suppression records

Do not assume that an address appearing in a billing or membership export can automatically enter every re-engagement campaign. Requirements vary by jurisdiction, message and channel, so retain the evidence supporting the intended contact and obtain legal advice where the basis is unclear.

Maintain a suppression file outside the promotional import and compare every permitted batch against it. The UK Information Commissioner’s Office advises placing people who object or opt out on a minimal suppression or do-not-contact list rather than simply deleting their details, so they are not contacted again by mistake.

If consent is the basis for a message, preserve who consented, when and how they did so, what they were told and exactly what the permission covered. The ICO’s direct-marketing checklist also calls for the organization relying on consent and the relevant communication methods to be identifiable.

Divide possible re-engagement records into three queues: documented permission compatible with the planned message, records requiring legal or operational review, and suppressed contacts. Keep the third queue out of the active marketing audience instead of uploading it first and applying a tag afterward.

5. Test the import before the full migration

Subscriber import results reconciled against the canonical migration table with every record assigned an outcome.

Import a small batch containing representative records from every permitted segment. Use controlled addresses where possible, then verify field mapping, access level, billing behavior, automated welcome messages, unsubscribe handling and any dates or statuses changed during ingestion.

Save pre-import control totals for each segment. After the full run, compare the canonical table with the destination’s accepted-and-rejected report and its visible audience or membership view.

  1. Give every source row an outcome: imported, suppressed, rejected or intentionally excluded.
  2. Investigate duplicate emails, missing identifiers, malformed dates and unsupported plan values instead of dropping them silently.
  3. Compare active paid records by tier, currency and billing frequency.
  4. Review canceled, failed and refunded records individually when an incorrect mapping could grant access or initiate billing.
  5. Screen the destination audience against the suppression file again before sending a campaign.

Keep the old platform available in read-only form, if its settings and retention terms allow, until payment records, access states and contact outcomes reconcile. The migration is complete when every exported record has a documented destination state—not merely when the CSV upload reports success.

Also read:

Share:

Subscribe to our newsletter

Get the latest Web3, AI, and crypto news delivered straight to your inbox.

0