One of three starting positions. The others are linked below — read the one you are in rather than all three.
Forex CRM migration
Where you are
You have a live book on a stack you did not choose, or chose before you knew what you needed. Clients are trading on it right now, which is the whole difficulty: every option has to work while the current thing keeps running.
What you are actually deciding
Not whether the new stack is better. The decision is whether the cutover is survivable — what moves, what does not, what breaks if it goes wrong, and whether you can go back.
The one section that differs completely between these three pages.
What has to move.
- 01
Accounts, balances and open positions
The non-negotiable set. Open positions are the hard part: they carry entry price, swap accrual and margin state, and a position that arrives with the wrong entry is a client dispute on day one.
- 02
Closed trade history
Migrated. This is the field most vendors quietly drop, because it is large and because nobody notices until a client asks for a statement or a regulator asks for a record.
- 03
The IB tree
Levels, rates and history. The other commonly-dropped field, and the one that turns a technical migration into a commercial problem when it goes.
- 04
Your own reporting queries
Not automatically — but the schema is documented and exportable, so the reports you built against the old system can be rebuilt against this one rather than abandoned.
And what does not have to happen
- A trading halt. The new environment runs in parallel and accounts move in groups.
- A one-way door. The previous environment stays available until you sign off, and rollback is rehearsed rather than theorised.
- Discovering what did not migrate after the old system is switched off.
In what order.
Order and dependency, not duration. What blocks what is the part a plan can be honest about; how long each takes depends on a regulator, a bank and a counterparty, none of whom answer to us.
- 01
Inventory and export test
What you run, and — before anything is promised — an actual export from it. What the current vendor’s export contains sets the ceiling on what any migration can move.
blocked by: nothing — this can start today
- 02
Field-level mapping, agreed in writing
Every field, where it lands, and explicitly what has no destination. The list of what does NOT move is the part worth reading twice.
blocked by: The export test
- 03
Parallel build
The new environment stood up and loaded with real exported data while the current one keeps serving clients.
blocked by: The mapping
- 04
Reconciliation
Balances, open position count, margin and history totals compared between the two systems and signed off before any client moves. Disagreements are found here, not by a client.
blocked by: Parallel build
- 05
Rehearsed cutover, including rollback
The move practised end to end on a copy, and the rollback practised too. A rollback that has never been run is not a rollback.
blocked by: Reconciliation sign-off
- 06
Move in groups, with the old system live
A cohort at a time, reconciled after each. The previous environment stays available until you say otherwise.
blocked by: Rehearsal
Written from the ways this goes wrong, not the ways it goes right.
How this goes wrong.
Each of these has happened to someone in your position. They are listed because the ordering advice above only makes sense once you know what it is protecting you from.
- Open positions arrive wrong
- Entry price, swap accrual or margin state off by a little. It becomes a client dispute immediately and a trust problem permanently. Reconciling position state before anyone moves is the only defence.
- Closed history left behind
- Nobody notices during the migration. It surfaces when a client asks for a two-year statement or a regulator asks for records you no longer have access to.
- Cutover with no tested rollback
- The plan says roll back; nobody has run it. Under pressure at 2am it turns out the rollback needs data the cutover already overwrote.
- Old system switched off too early
- Usually to stop paying for it. It removes the only reference you have for reconciling anything that surfaces in the following weeks.
What carries the weight here.
The whole stack comes as one thing, so this is not a shopping list. It is which parts do the work in this situation, and why.
- ForgeCRM
- The migration is mostly this: accounts, balances, closed history and the IB tree. The reason there is no reconciliation afterwards is that the record your team edits and the account a client trades on are the same row.
- ForgeTerminal
- Your clients notice the terminal and nothing else. MQL expert advisors run unchanged and the order handling follows the conventions they already know, which is what keeps a migration from becoming a retraining project.
Questions that come up.
- Will clients experience downtime?
- No trading halt. Accounts move in groups while the current environment keeps serving everyone who has not moved. An individual account is briefly read-only during its own move.
- What does not migrate?
- Whatever your current vendor will not export, and anything with no equivalent field. Both are listed explicitly in the mapping before the work starts — the list of what does not move is the honest part of a migration plan.
- Can we roll back?
- Yes, and the rollback is rehearsed as part of the cutover rather than documented as a plan. It stays available until you sign off. A rollback nobody has run is not a rollback.
- How do we know the balances are right?
- Reconciliation before any client moves: balances, open position counts, margin and history totals compared across both systems and signed off by you. If they disagree, nobody moves.
- What if we want to leave you later?
- The same export we would ask of your current vendor is one you can run against us, on demand, in standard formats. See data ownership and exit — it is a page rather than a clause because it is the question we would ask too.
4open items on this page
- Which source platforms and CRMs we have migrated from in production. This is the most useful thing this page could say and it should only name ones we have actually done.
- A documented schema reference for rebuilding reports against, linked from the technical section.
- Pricing, which is a commercial decision that has not been made. No "from" figure appears here.
- Timelines beyond the documented three-day technical setup. Anything else would be a figure without a measurement.
See it before you decide.
The demo is the whole stack with your own credentials. For this situation in particular, the thing worth reading first is what happens if you want to leave again.