What an MT5 Grey Label Migration Quote Should Explain
A migration description should explain more than a move from one setup to another. When evaluating an MT5 grey label migration quote, identify the things being transferred, the things being rebuilt, and the things that need separate approval. Each category carries a different responsibility.
Inventory the starting point
List the existing systems, account categories, configurations, reports, and operational processes you need to preserve. Ask which data or records can actually be supplied by the current provider. Do not assume a new provider can access an environment or export information without the necessary permissions and cooperation.
Separate transfer from reconstruction
Some elements may be available as documented information; others may need to be configured again. Request a scope that names each task and its owner. Include website and CRM connections if they are part of the transition. A migration label should not imply those systems are automatically included in the quoted work.
Define what will be checked
Agree the records, settings, and workflows that should be compared before and after the transition. Identify test accounts, expected reporting, and the people who approve the results. Ask how discrepancies are recorded and resolved. A successful login does not demonstrate that every required business workflow has been preserved.
Agree the sequence and contingency
Discuss dependencies, the order of changes, communication responsibilities, and what happens if a required check fails. Any timing or interruption expectations must be agreed for the specific case. Avoid assuming a zero-downtime move from general marketing language. A sound quote makes the sequence and ownership clear enough for your team to coordinate the transition without guessing.
A migration quote template
A migration quote should list every activity, because each one costs time. Ask the new provider to fill the table and ask your current provider to confirm what it will supply.
| Activity | Done by | Included in quote? | Cost |
|---|---|---|---|
| Export of accounts and balances | Current provider | ||
| Export of trade history | Current provider | ||
| Rebuild of groups and symbols | New provider | ||
| Integration changes (CRM, payments) | New provider and vendors | ||
| Reconciliation checks | New provider and you | ||
| Client communication | You | ||
| Cut-over support | New provider | ||
| Parallel running period | Both |
An activity without an owner is the one that will cause a delay.
A worked example of a quote that missed a line
A buyer receives a migration quote that covers moving accounts and balances. It is silent on trade history, on re-pointing the payment integration and on a parallel running period. Closer reading shows that each of those would be billed at hourly rates once the project started.
The buyer sends the table above and asks the vendor to complete it. The revised quote is higher, but it is complete, and the buyer can now compare it with the quote from another provider. Without the table, the comparison would have been between a full price and a partial one.
Questions for the current provider
- What data can you export, in what format and by when?
- Do you charge for exports or for help during the transition?
- Is there a notice period, and what happens to my branding?
- Can you keep the service running during the cut-over?
- Who is the named contact for the migration?
Get the answers in writing before you sign with the new provider, because your negotiating position is stronger while you are still a customer.
Contingency and timing
Migrations rarely go exactly to plan. Ask the new provider to state a contingency, both in time and in cost, and to describe what they will do if a check fails. Plan the cut-over for a quiet period, and agree a freeze on changes in the days before it.
A modest contingency in the quote is a sign of experience, not of padding. See our migration roadmap for the sequence of steps.
Why migration quotes are often incomplete
Migration work sits between two providers, and each is more focused on its own part. The new provider quotes what it will build and often assumes that the old provider will supply the data and cooperate. The old provider may not be motivated to help. As a result, quotes tend to miss the awkward parts: exports in the right format, a parallel running period and the work of re-pointing integrations.
As the buyer, you are the only one who sees the whole picture, so you must assemble it. The table in this guide is your tool. Walk through it line by line with both providers.
Reconciliation as a priced line
Reconciliation means proving that the new environment matches the old one: account counts, balances, positions and history. It is a real piece of work with real hours, and it should appear in the quote as a line with an owner.
Ask the new provider how reconciliation is done and what evidence you will receive. A report that lists checks performed and results is a reasonable deliverable. Without it, you are asked to trust that the move went well.
Negotiating when you are leaving
Negotiating power is strongest before you sign with the new provider and while the old one still hopes to keep you. Ask the old provider for a written transition plan and fees. Ask the new provider whether migration is included in the first-year price as an incentive.
A buyer who negotiates both sides early often saves more than the migration itself costs.
A realistic view of what can go wrong
Typical migration problems include data in unexpected formats, accounts with unusual settings, integrations that point to old addresses, passwords that must be reset and reports that differ between systems. None of these is rare. A good migration plan expects them, assigns people to fix them and leaves time.
Ask the new provider to describe the three problems it sees most often and how it deals with them. The answer shows experience.
Keeping a migration log
During a migration, keep a log of each step: what was done, by whom, when and with what result. Include checks and discrepancies. After the move, review the log and capture lessons for the future.
The log is also evidence if a dispute arises with either provider.
Frequently asked questions
How much does a migration cost?
It depends on the number of accounts, the amount of history, the integrations and the effort of reconstruction. Ask for an itemised quote.
Can I migrate without downtime?
Sometimes a short cut-over window is unavoidable. Ask how the provider minimises it and how clients will be informed.
Who owns the data?
This should be stated in your contract. Confirm it before you start.
Should I run both systems in parallel?
A short parallel period can reduce risk but adds cost. Ask for the price and decide.