From MT5 Grey Label to White Label: A Broker’s Growth and Migration Roadmap

Published 2 Aug 2026 · 5 min read · Technology information, not financial advice

Many brokers start on a grey label and later want more control. The move to a white label is a migration project with technical, commercial and client-communication parts. This roadmap shows the signs that it is time, and how to plan the move so clients barely notice.

Image placeholderblog-mt5-grey-label-to-white-label-migration-roadmap-hero.webp · 1600 × 900

Signs you may have outgrown a grey label

Common signs include reaching listed client or group limits, needing deeper administrative access, wanting your own server environment, requiring integrations the setup cannot support and wanting more independence in your commercial terms.

Check the limits in our capacity guide and compare the models in grey versus white label.

Define what you want from the white label

Write down the capabilities you are missing, the budget you can support and the date by which you need them. Ask providers for scope, costs and timelines, using the list in our white label cost breakdown.

Plan the migration

Plan the target environment, the configuration you will copy, the accounts and balances to move, the integrations to reconnect and the cut-over date. Identify what can run in parallel.

The component view in MT5 white label turnkey helps you list what must exist before the move.

Communicate with clients

Tell clients early, explain what will change and what will not, and give clear instructions for any new login or terminal. Prepare support staff with answers and a help page. Most migration complaints come from silence, not from the technical work itself.

Test and rehearse

Test the new environment with a small group before the cut-over. Reconcile balances and positions between old and new systems, and rehearse the cut-over steps, including how to roll back if something fails.

Cut over and review

Choose a quiet window, follow the rehearsed steps and monitor closely afterwards. Review issues daily at first. Keep the old environment available for a defined period if your agreement allows. After a few weeks, record what you learned and update your runbooks.

A migration roadmap table

Migration is easier to manage when each phase has outputs and an owner.

Treat each phase as a gate: do not start the next until the outputs exist.

A worked example of reconciliation

On cut-over weekend a broker moves several hundred accounts. Before the move the team records account counts, balances per account and in total, open positions by symbol, volume and price, and the history count for an agreed period.

After the move, they run the same checks on the new environment. Any difference is investigated before clients are told the migration is complete. Because the checks were defined in advance, the team can sign off in a few hours rather than arguing about what to measure.

Communicating with clients

Clients dislike surprises. Tell them early what is changing, when, what they need to do (if anything) and how to reach support. Use plain language and short messages. Reassure them about their funds and open positions, and share what will be unavailable during the cut-over.

After the move, send a short confirmation and invite questions. Staff should have a script and a list of likely issues. Clear communication often matters more to clients than the technical details.

Risks to plan for

• Open positions during the cut-over.
• Integrations that point to the old environment.
• Credentials and passwords that need to be reset.
• Reports that differ between systems.
• Third parties, such as payment providers, that need the new details.

For each risk, name an owner and a mitigation. See the grey versus white label comparison to confirm that a white label is the right destination.

Deciding whether to migrate at all

Migration is a significant project. Before starting, write down the specific problems it solves and the cost of living with them. If the problem is a limit that can be raised, an upgrade may be cheaper. If the problem is control or independence, migration may be justified.

Compare three options: stay, upgrade within the current model, or migrate. Estimate cost, effort and risk for each over the next two to three years. Present the comparison to decision makers with the assumptions visible.

A cut-over day plan

1. Announce the maintenance window in advance.
2. Freeze changes on the source environment.
3. Take a final snapshot of accounts, balances and positions.
4. Move accounts and verify counts.
5. Run reconciliation checks and compare with the snapshot.
6. Switch integrations, payment details and communications to the new environment.
7. Open trading and monitor closely.
8. Review at the end of the day and record issues.

Assign a named person to each step and keep a live log. A calm cut-over is the product of preparation, not luck.

After the move: the first two weeks

Expect questions and small issues. Staff the support team generously, publish a short FAQ and monitor payments, reports and integrations daily. Hold a review after one week and again after two. Collect lessons learned and update your runbooks.

Once the new environment is stable, decommission the old one according to your agreement, making sure data retention and deletion obligations are met.

A risk register for migration

Review the register in each weekly meeting and add anything new that appears.

Frequently asked questions

When should I move from grey label to white label?

When limits, control or independence become constraints on your plans, and the benefits outweigh the cost and effort.

Can client accounts be migrated?

Often yes, but it depends on both environments and the agreement. Plan how accounts, balances, positions and history will be moved and verified.

How long does migration take?

It depends on scale and complexity. Plan, rehearse and allow time for reconciliation.

Will clients notice?

They may, if passwords, server names or interfaces change. Communicate clearly and offer support.