From MT5 Grey Label to White Label: A Migration Plan With Cut-over and Rollback
A migration is a controlled change with a defined start, a verified end and a way back. Plan it as one: inventory, mapping, rehearsal, cut-over and rollback.
Trigger criteria
Document why you are moving: capacity limits, access, independence or integrations. Define the capabilities the target must provide. See the capacity guide.
Inventory and mapping
Inventory accounts, balances, positions, groups, symbols, integrations and credentials. Map each item to its target equivalent and note transformations. Define what will not migrate.
Target readiness
Build the target environment to the acceptance checklist in our readiness list, and test integrations on staging.
Rehearsal
Run the migration on a copy of the data. Reconcile balances, positions and history between source and target. Record timings and defects, then repeat until clean.
Cut-over
Choose a low-activity window, freeze changes, migrate, verify with reconciliation, switch integrations and monitor closely. Communicate with clients before and after.
Rollback
Define the point of no return, the rollback steps and who decides. Keep the source environment available for a defined period. Review after cut-over and update the runbooks. See the model comparison.
Reconciliation checks
- Account counts and logins match between source and target.
- Balances match per account and in total.
- Open positions match by symbol, volume and price.
- History counts match for the agreed period.
- Integration identifiers resolve correctly.
Sign off each check before cut-over and again afterwards.
Trigger criteria and business case
Define quantitative triggers for migration: share of client or group limit, unsupported requirement count, cost per client versus target, or incident rate attributable to limits. When a trigger fires, run a business case comparing stay, upgrade and migrate over a thirty-six month horizon with migration cost, parallel running and risk.
A documented trigger prevents both premature migration and drift into an emergency.
Mapping and rehearsal
| Object | Source | Target | Transform | Validation |
|---|---|---|---|---|
| Account | Login and profile | New login | Mapping table | Count and attributes |
| Balance | Balance and credit | Opening balance | Direct | Per account and total |
| Positions | Ticket, symbol, volume, price | Recreated positions | Mapping | Per ticket |
| History | Deals | Imported or archived | Format conversion | Count by period |
| Groups | Group settings | New groups | Manual mapping | Settings diff |
Rehearse at least twice with production-like data. Measure duration of each step and record defects. The second rehearsal should pass without manual intervention.
Cut-over and rollback
Write a minute-by-minute cut-over plan with owners and checkpoints: freeze, final snapshot, migrate, validate, switch integrations, open trading, monitor. Define rollback criteria (reconciliation failure, integration failure) and the point of no return. Prepare communication for each outcome.
Keep the source environment available and unmodified until validation is complete and the retention requirement is met.
Post-migration reconciliation
Run the validation checks again after cut-over and daily for a period: account counts, balances, positions, history, integration identifiers, report totals. Sign off each check. Hold a retrospective and update runbooks.
See our dependency guide for the inventory step.
Worked example: rehearsal findings
First rehearsal: counts match but 14 accounts have different leverage because group mapping used a default. Second finding: history import drops deals with a particular type. Third: an integration still points at the old address.
Each finding gets a fix and a retest. The second rehearsal passes. The cut-over plan is updated with measured durations, and the window is sized with margin.
Client-facing impact
List what clients will experience: server name changes, password resets, temporary unavailability, new statement formats. Prepare notices and support scripts, and verify them in rehearsal.
Track client contacts during the first days and adjust the FAQ.
Governance of the migration programme
Treat the migration as a programme with a sponsor, a lead, workstream owners and a decision log. Hold go and no-go reviews at defined gates with evidence, and record the decisions. Maintain a risk register with mitigations and triggers.
Clear governance prevents a technical project from becoming a series of informal agreements that nobody can reconstruct when something goes wrong.
Frequently asked questions
What triggers a migration?
Defined thresholds such as share of limit, unmet requirements or cost per client.
How many rehearsals are needed?
At least two, the second without manual intervention.
What is the point of no return?
The step after which rollback is no longer practical, defined in advance.
When can the old environment be retired?
After validation and when retention obligations are met.