What Data Actually Has to Move When a Prop Firm Changes Software?
Customer names and emails are the easy part. A functioning migration must preserve the relationships and state that tell the new platform what each trader bought, where each account is in its lifecycle and what financial/compliance actions remain pending.
Customer identity
Customer ID, email, contact fields, locale, communication preferences, account creation time and relevant tags. Preserve stable identifiers or a mapping table.
Orders and transactions
Products purchased, prices, discounts, coupons, payment status, refunds/chargebacks and transaction IDs. These records support customer service and commercial reconciliation.
Trading accounts
Platform, login/account ID, account size, creation date, current lifecycle state and linkage to customer/order. Avoid assuming a customer-to-account one-to-one relationship.
Challenge state
Phase, applicable rule version, pass/fail state, reset/retry history and relevant evaluation timestamps. For active accounts, this is operational state—not merely history.
Trading/risk history
The required depth depends on the destination architecture. Determine whether full trade history, summarized metrics, breach events or current balance/equity references are needed to continue rule evaluation correctly.
Funded and payout state
Funded status, profit split, payout requests, approvals/rejections, paid history and pending eligibility. Manually review pending/high-value cases at cutover.
KYC
Verification status, provider reference, timestamps and manual-review state. Determine whether underlying documents need to move at all; minimizing sensitive-data replication can be preferable.
Affiliates
Affiliate ID, referral relationship, coupon/attribution, commission history and pending commission state. Broken attribution can create commercial disputes after migration.
Configuration
Products, rules, email templates, roles, payment settings and integration mappings may not export cleanly from the incumbent. Treat configuration reconstruction as its own workstream.
Audit history
Administrator actions, breach decisions and payout review history can matter for support/dispute reconstruction. Define retention needs before discovering the old system cannot export them.
Reconciliation matrix
| Object | Count check | State check | Sample deep check |
|---|---|---|---|
| Customers | Yes | Status | Identity/preferences |
| Active accounts | Yes | Critical | Rules/phase/platform |
| Payouts | Yes | Critical | Pending + history |
| KYC | Yes | Critical | Provider refs/manual review |
| Affiliates | Yes | Pending balances | Attribution sample |
Use the migration checklist, migration RFP and data ownership guide.
FAQ
Do I need all historical trades in the new CRM?
Not always. The required history depends on risk, support, reporting and audit needs. Define the destination use case before migrating unnecessary data.
Should KYC documents be copied?
Not automatically. Determine legal/operational need and whether status/provider references can be preserved without unnecessary sensitive-document duplication.