Migrating Your Prop Firm to a New Trading Platform Without Losing Traders

Nobody migrates trading platforms because they want to. They migrate because a licence was revoked, a vendor raised prices, the platform could not scale, or support stopped answering.

The MetaQuotes licence crackdown forced a large part of the industry through this at once, and the difference between firms that came out fine and firms that lost half their book was almost entirely execution. The migration itself is not technically exotic. The ways it goes wrong are predictable — which means they’re avoidable.

Here’s the playbook.

First: are you sure?

Migration is expensive in ways that don’t show up on the vendor invoice. Before committing, be honest about which problem you’re solving.

Good reasons to migrate:

• Your licence is at risk or already gone. Not optional.
• The platform genuinely cannot handle your account volume.
• Your traders are actively leaving over platform quality.
• Costs have moved enough to change your unit economics materially.

Bad reasons:

• A competitor uses something newer.
• A feature you’d use occasionally.
• A vendor sold you well.

If it’s the second list, the migration will cost more than the problem. If it’s the first, keep reading.

One thing worth knowing before you start: you don’t necessarily have to pick one. Running two platforms in parallel is genuinely viable, and it’s often the right answer — new traders onboard to the new platform, existing funded traders finish out where they are. More on that below.

What actually breaks

The trading platform is the visible part. The integrations are what break.

Account provisioning. Every platform has its own API for creating accounts, setting leverage, applying groups. Your automated onboarding is coupled to it, and that coupling has to be rebuilt.

Risk engine feeds. This is the big one. Your risk engine consumes real-time equity and position data in the old platform’s format. Data shape, update frequency and — critically — how floating P&L is reported all differ between platforms. Breach logic that was correct against one feed can be subtly wrong against another. Subtly wrong breach logic means wrongly failed traders, which means refunds and public complaints.

Trade history. Historical trades in the old system, new trades in the new one, and traders expecting one continuous record. Somebody has to decide whether history is migrated, archived, or displayed from two sources.

Reporting. Every dashboard and metric that assumed one schema.

Trader-facing docs. Every tutorial, screenshot and support article referencing the old platform’s UI.

The rule of thumb: budget more time for the risk engine than for the platform itself. Firms consistently get this backwards.

Live funded accounts are the hard part

Evaluation accounts are relatively easy — worst case, you extend deadlines and let people finish. Funded accounts are where migrations become genuinely difficult, because real money and real obligations are attached.

The core problem: a funded trader has state that must survive the move. Current balance, high-water mark, drawdown level, payout eligibility, days traded. Lose any of it and you’ve either handed the trader an advantage or, far worse, breached them incorrectly.

Three approaches, in descending order of how much I’d recommend them:

1. Grandfather them. Keep the old platform running for existing funded accounts until they close naturally. New traders start on the new platform. Costs you two platform bills for a while; costs you zero trader goodwill. This is usually the right call, and firms routinely underestimate how quickly the old cohort winds down.

2. Migrate with state transfer. Move accounts, carrying balance, high-water mark and drawdown level across. Doable, but every value must be verified per-account, and you need a reconciliation report you’d be comfortable showing a trader who disputes their new drawdown level. Do not do this in bulk without account-level verification.

3. Reset and compensate. Move traders to fresh accounts at current balance, and compensate for anything lost. Simplest technically, most expensive in trust. Only sensible if the old platform is going away imminently and state transfer isn’t possible.

Whichever you pick, the trader must know before it happens, in specific terms. “We’re upgrading our platform” is not communication. “On 14 August your account moves to Match-Trader. Your balance of $107,400, your high-water mark of $112,000 and your drawdown level of $100,800 all carry over unchanged. Here’s a walkthrough of the new platform” — that’s communication.

The sequence that works

Weeks 1-2 — audit. List every integration touching the platform: provisioning, risk feeds, reporting, payouts, support tooling, marketing pages. The list is always longer than expected, and finding an integration mid-migration is what turns a two-week job into a two-month one.

Weeks 2-4 — parallel build. Stand up the new platform alongside the old. Rebuild integrations. Do not touch live traffic.

Weeks 4-5 — shadow the risk engine. Run the new risk engine against live data without acting on it, and compare its decisions to the old one. Every disagreement is a bug you’d otherwise have found by wrongly breaching a real trader. Do not skip this step. It is the single highest-value part of the whole migration and the one most often cut for time.

Week 5 — internal testing. Full lifecycle on the new platform: buy an evaluation, trade it, breach it, pass it, get funded, request a payout. End to end, with real money paths.

Week 6 — new traders only. Route new signups to the new platform. Existing traders untouched. You now have real usage and a real support signal with zero risk to your funded book.

Weeks 7+ — migrate or grandfather. Only once the new platform has demonstrably handled a full cycle.

Firms that compress this usually compress the shadow-running phase, and that’s precisely where the expensive mistakes hide.

Communication is most of the risk

Migrations damage firms through trust, not technology. Traders are already primed to suspect prop firms of changing rules to their disadvantage, and a platform migration looks exactly like that if handled badly.

• Announce early, in specifics. Dates, what changes, what doesn’t.
• Be explicit that rules aren’t changing — if they aren’t. If they are, say so separately and clearly, because bundling a rule change into a migration is how you get accused of hiding it.
• Ship tutorials before the switch, not after.
• Staff support heavily during the window. Ticket volume will spike whatever you do.
• Publish a rollback position. Knowing there’s a plan if things go wrong reassures people more than confidence does.

The firms that lost traders during the MetaQuotes migrations mostly did so through silence, not technical failure. Related: building prop firm brand trust.

Choosing the destination

If the migration is forced, the platform choice deserves its own analysis rather than picking whatever’s quickest. We compared the main options in cTrader vs Match-Trader vs TradeLocker, and there’s a neutral feature-by-feature breakdown on our platform comparison page.

Briefly:

• Match-Trader — platform, CRM and challenge engine in one stack. Fewest moving parts if you want a single vendor.
• cTrader — large existing trader base, strong mobile apps, premium positioning.
• TradeLocker — TradingView charting built in, modern interface, fast-growing adoption.
• DXtrade — heavily customisable, strong multi-asset support.

The right answer depends on where your traders already are. Migrating to a platform your audience doesn’t use solves your vendor problem and creates a retention one.

What to do first

If you’re migrating under time pressure — licence revoked, vendor exiting — the order that limits damage is:

1. Stop the bleeding. New signups go to the new platform immediately. Stop growing the population you’ll have to move.
2. Protect funded traders. Grandfather them if at all possible. They’re your revenue and your reputation.
3. Shadow-run the risk engine before it makes a single real decision.
4. Over-communicate at every step.

Migration is survivable. Firms do it and come out with a better platform and traders who barely noticed. What isn’t survivable is wrongly breaching a cohort of funded traders because the new risk feed reported floating P&L differently and nobody checked.

---

Facing a platform migration? PropFirmsTech supports MT5, cTrader, DXtrade, Match-Trader and TradeLocker on one risk engine and one CRM — which means switching platforms doesn’t mean rebuilding your stack. Book a call and we’ll map your migration, including the shadow-running phase.