OnlyFans CRM migration checklist

Name why you are moving and what must be true for the move to count as successful. "Use the new CRM" is not an acceptance test. "Every active chatter can reach only their assigned fans, managers can inspect authorship, current rate terms agree, and no open conversation disappears" is.

• One migration owner with authority to pause the cutover.
• A source-system owner, destination-system owner and security reviewer. They may be the same person in a small agency, but the responsibilities still need names.
• The creator accounts in scope, explicitly excluding any account that is not ready.
• A source freeze time, timezone and final delta window for records created after the first export.
• Pass, fail and rollback criteria for data, access, messages, vault, money and staff workflows.
• A retention and deletion decision for the old CRM after acceptance—not on day one.

The migration inventory is the control document. Give every row an owner, source, available format, approximate size, oldest and newest date, sensitivity, destination and acceptance test. If the vendor cannot export a class, mark it archive-only or rebuild-required before anybody promises a complete move.

1. 1Read the vendor's export boundaryAsk which datasets, fields, date ranges and formats are included; whether media bytes are included or only links; and whether deleted, withdrawn or archived records appear. Get the answer in writing.
2. 2Take raw and readable copiesKeep the machine-readable export for mapping and a human-readable snapshot for disputes. A perfect JSON archive is useless to the manager who needs to answer a creator today.
3. 3Create a manifestRecord file name, dataset, row count or honest unknown, export time, account scope, oldest/newest record and file hash. Empty data needs a reason, not an unexplained zero-row file.
4. 4Capture the final deltaExport or list records created and changed after the initial snapshot. Otherwise the cleanest migration in the world still drops the final shift.
5. 5Protect the bundleFan messages, spend, identities and staff data should not live in an unencrypted shared drive or an agency group chat. Limit access, log custody and set a deletion date for working copies.

Do not export browser passwords, session cookies or signing material into the bundle. Rebuild the destination connection through its approved onboarding path, then rotate or revoke old credentials after acceptance. Moving a live session file between vendors is not migration; it is copying the keys to the account.

Two columns called revenue can describe gross fan payments, Creator Earnings after OnlyFans' fee, visible chat spend, reconciled statement money or commission-eligible value. A syntactically successful import can still be commercially wrong. Build a field map with source definition, destination definition, conversion, null handling and proof sample.

• Preserve stable source IDs alongside new destination IDs. Without both, a later delta import cannot deduplicate safely.
• Distinguish null, zero, false and not measured. A missing purchase state must not become an unopened PPV; unknown spend must not become a zero-value fan.
• Normalise timezone and currency explicitly. Store the original value where a conversion occurs.
• Document status mappings. Sent, queued, failed, withdrawn and mirrored are not interchangeable message states.
• Keep authorship and approval separate. The person who drafted, approved, sent or withdrew a message may not be the same actor.
• Carry truncation and as-of metadata into the destination or archive. Removing a coverage warning makes partial history look complete.

Choose a representative account—not the tidiest one and not the account currently on fire. It should have multiple chatters, PPV history, vault media, a rate change and at least one exception such as a refund or withdrawn message. Keep the source available and the destination read-only while validating historical data.

Migration is an access review disguised as a software project. NIST's current Cybersecurity Framework puts identity, access and data protection inside the core control set; the ICO's current security guidance likewise expects appropriate access control and protection of personal data. Do not clone broad legacy roles just because that is what the old tool allowed.

1. 1Start with no seatsCreate role templates and account scope first. Add current people from the approved roster, not from a blind user-table import.
2. 2Test the denied pathsA chatter must fail when requesting credentials, exports, peer pay, creator identity and out-of-scope fans. A hidden navigation item proves nothing.
3. 3Rotate integrationsIssue destination-specific API keys and connection material, then revoke the source credentials after rollback expires. Never reuse a shared key to save an hour.
4. 4Account for local stateSaved filters, browser notes and local split settings may not exist in a server export. Either document and recreate them or deliberately retire them.

1. 1Close the final source shiftStop new work at the declared time, capture the delta and reconcile open conversations. Tell the team exactly when the destination becomes authoritative.
2. 2Enable one write pathMove the pilot or roster to send-active only after access and state checks pass. Keep the old system read-only for investigation.
3. 3Watch the first operating cycleMonitor missing fans, duplicate messages, stale inboxes, wrong PPV media, permission denials and unexplained money differences. Give chatters one place to report a migration defect.
4. 4Invoke rollback on evidencePause writes and return to the agreed source workflow if a stop criterion is met. Do not delete destination records; preserve them for comparison and incident review.
5. 5Retire deliberatelyAfter acceptance, export the final audit record, revoke old seats and integrations, confirm the vendor's retention/deletion process, then cancel. Keep only the archive your legal and operating needs justify.

FanHelm does not currently offer an automated migration that ingests another CRM and recreates the whole agency. Do not buy it on that promise. Its current inbox and vault surfaces build real, account-scoped views from the connected OnlyFans account, while source-CRM exports may need to remain a reference archive or be mapped through a separately agreed migration scope.

FanHelm does have an entitlement-gated export bundle for data already stored in FanHelm: fans, conversations, messages, transactions, vault metadata and organisation members in CSV and spreadsheet-readable form, with an as-of manifest and explicit missing-data notes. That is portability out of FanHelm. It is not proof of one-click import into FanHelm.