In week one, the operations team should be counting accounts, mapping fields and testing exports. By week six, a well-scoped migration may be moving its first live cohort, with balances reconciled and a rollback route agreed. Treating the change as a software switch rather than a transfer of active trading relationships is how firms create avoidable disputes.
Choose the migration shape before the date
There are three common approaches. A single cutover moves the whole funded book at once.
It keeps the old and new systems from running side by side for long, but concentrates operational risk into one window. A staged move transfers cohorts over several weeks. It limits the impact of defects, though teams must support two systems and explain why traders have different experiences during the transition.
A parallel run keeps existing accounts on the current provider while the new platform is tested with matched or newly issued accounts. It is useful for checking execution, reporting and risk rules under real operating conditions.
It can also create duplicated work, extra provider costs and confusion if traders are unsure which account is authoritative. Do not let traders trade the same strategy on both accounts unless the firm has controls for duplicate exposure.
| Approach | Typical preparation | Typical cutover or overlap | Best suited to |
|---|---|---|---|
| Single cutover | 3-6 weeks | 4-12 hours of restricted access, subject to testing | A smaller book with consistent account rules |
| Staged cohorts | 4-8 weeks | 1-3 days per cohort, often across 2-6 weeks | A larger book or accounts with different products and rules |
| Parallel run | 4-8 weeks | 2-6 weeks of controlled overlap | Testing workflows before moving active traders |
These are typical planning ranges, not service guarantees. Provider access, custom integrations and the number of account types can extend them. A useful starting point for comparing vendors and their migration capabilities is the PropFirm Provider marketplace.
Define what moves, and what stays behind
"Account migration" can mean a new login and platform, or a rebuild of each trader's commercial and risk state. Confirm in writing which records the incoming provider can import and which your team must recreate. Test the mapping with a small sample that includes edge cases, not only a clean account.
- Trader identity, account ID, account status and linked evaluation history.
- Starting balance, current equity, drawdown reference point, profit target and loss limits.
- Product permissions, use, contract specifications, commissions and trading sessions.
- Open positions, pending orders, payout status, rule breaches and support notes.
- Trading history and reports required for reconciliation, support or compliance processes.
Do not assume a displayed balance tells the whole story. A trailing drawdown may depend on a high-water mark or a daily reset time that is not visible in the headline figure.
Map the calculation method, timezone, rounding and treatment of fees. If the new system applies a different rule, record the agreed treatment for each affected account before issuing credentials.
Open positions need a separate policy. Trading accounts and execution environments generally cannot be treated as interchangeable just because the account number can be recreated. Decide whether positions will be closed before cutover, left to run on the legacy provider until flat, or handled under a tested transfer procedure. Never silently convert an open position into a new one at a different price.
Reconcile account state, not just record counts
Before moving production accounts, create a source-of-truth file with one row per account and a timestamped export. Compare the old platform's state with the new provider's imported state using agreed tolerances.
For balances and equity, set a zero-difference requirement where both systems use the same calculation. Where feeds, fees or reset times differ, document the expected variance and who approves it.
Run the checks twice: once in a test environment and again against the final pre-cutover export. Reconcile a sample manually, including accounts near a breach threshold, accounts with pending payouts and accounts with recent rule changes. A successful import of 1,000 account IDs is not proof that 1,000 risk profiles are correct.
Do not cut over on a clean dashboard alone. Reconcile the account states that determine whether a trader can breach or withdraw.
Keep a migration log with source values, imported values, exceptions, owner and resolution. Typical teams set a target of 100% matching for account identity and rule fields, then hold exceptions from migration until an operator signs them off. For a staged move, repeat the checks for every cohort rather than carrying forward the first batch's results.
Protect trading continuity and support capacity
Set a freeze window for changes to account rules and profile data. Communicate the exact time, timezone, access restriction and expected credential delivery. Avoid promising uninterrupted trading if the new provider has not confirmed the relevant platform, broker or risk integrations in a production-like test.
A practical cutover sequence is:
- Stop new account creation and lock edits to accounts in the cohort.
- Export the final account state, open-order list and pending payout queue.
- Import accounts, then run automated comparisons and manual exception checks.
- Issue credentials only after risk settings and product permissions pass sign-off.
- Monitor logins, orders, breaches, support tickets and payout records through the first trading sessions.
Keep the old system available in read-only mode where the contract and technical access allow it. Set an escalation owner for trading access, incorrect balances and risk-rule disputes. For a firm moving several cohorts, reserve extra support cover on each cutover day. Typical operational planning allows 1-2 additional support staff per active cohort, adjusted for account volume and expected contact rates.
Trader communication should distinguish platform access from account terms. State whether the balance, drawdown basis, payout eligibility and trading rules are unchanged.
If any term changes, describe it plainly and provide a route for the trader to query their own record. Silence can turn a recoverable configuration error into a trust and support problem.
Set acceptance criteria and a rollback point
Before selecting a provider or fixing a date, agree measurable acceptance criteria with product, risk, support and finance. Include account imports, rule calculations, order handling, reporting, payout records and access recovery.
Set thresholds for pausing the move. For example, any unexplained mismatch in balance or breach logic should block that account or cohort, not be filed for later review. Rollback is not always a button. If traders have placed orders on the new system, returning them to the old one may produce conflicting positions and histories.
Define the rollback point before cutover: the last moment when no trading activity has occurred on the new accounts, or a specific, approved procedure for accounts that have traded. Confirm who can stop the move and how traders will be told.
Ask each shortlisted provider to demonstrate the import and reconciliation process using anonymised records that reflect your account types. Record what is automated, what requires manual work, the evidence retained and the cost of keeping legacy access during transition. This week, build an account-level migration inventory with balances, rule fields, open positions and payout status, then use it as the test file for provider discussions.
Frequently Asked Questions
How long does a funded account migration take?
A typical migration needs 3-8 weeks of preparation, depending on integrations, account types and data quality. A single cutover may take hours, while staged cohorts or a parallel run can extend the transition across several weeks.
Can open trades move to a new prop firm platform?
Do not assume an open position can be transferred between providers or execution environments. Set a policy to close positions, leave legacy accounts active until positions are flat, or use a tested procedure approved by risk and operations.
Which account data should be checked during migration?
Check identity, balances, equity, drawdown basis, risk limits, product permissions, trading history, open orders and payout status. Prioritise fields that determine breaches or withdrawals, and document any expected differences between systems.
Is a staged migration safer than a single cutover?
A staged move limits the number of traders affected by a defect and lets teams learn from early cohorts. It also means supporting two systems for longer, so it is not automatically safer without clear ownership and reconciliation.
When should a prop firm pause a migration?
Pause a cohort if account identity, balance or breach logic has an unexplained mismatch, or if access and order handling have not passed agreed tests. Define the stop conditions and decision owner before the first production cutover.