MT5 Setup Migration: Map the Integration Dependencies
A change of MT5 setup can affect more than the platform login. Connected workflows may depend on account identifiers, group mappings, provider access, and reporting assumptions. Map these dependencies before you decide which parts of the existing operation can carry over unchanged.
Inventory the connections that exist today
List the website forms, CRM actions, reports, and staff processes that depend on the current platform arrangement. Include manual steps as well as automated ones. A spreadsheet used by operations can be just as important to the handover as a formal integration, even though it appears nowhere on an architecture diagram.
Confirm what can be transferred
Ask the current and proposed providers which information can be supplied and which configuration must be recreated. Identify permissions needed to obtain records or documentation. Do not assume an account relationship or integration setting will remain valid simply because the destination uses the same platform name.
Recheck the workflow assumptions
Review group mappings, manager roles, reporting definitions, and optional API permissions against the new scope. Mark anything that needs adaptation and ask who will perform it. These changes can affect the implementation effort and price, so they should be visible before the migration quote is treated as complete.
Agree a sequenced transition
Document prerequisites, the order of changes, test accounts, acceptance checks, and the person coordinating the switch. Discuss what happens if a required dependency is unavailable or a check does not pass. Any timing or continuity commitment must be specific to the agreed case. The aim is a transition plan that names the dependencies, not a promise that every connected process will automatically survive a platform change.
Dependency inventory
Before planning a migration, inventory every system and connection that touches the current environment: CRM, payment callbacks, reporting jobs, partner portals, risk tools, notification systems, scheduled exports and any scripts staff run by hand. For each, record the endpoint, credentials, data exchanged, frequency and owner.
The inventory is usually longer than anyone expects. Items discovered after the cut-over are the main source of migration incidents.
Dependency matrix
| Dependency | Points to | Change needed | Test | Owner |
|---|---|---|---|---|
| CRM provisioning | Old platform address | New address and credentials | Create and reconcile test account | Technical lead |
| Payment callback | CRM | None, but verify | Replay test callback | Payments |
| Reporting job | Old data source | Re-point and re-validate | Compare totals | Analyst |
| Partner portal | CRM data | Verify mapping | Compare commissions | Partner manager |
| Staff scripts | Old manager access | Replace or retire | Run in staging | Operations |
Each row becomes a task with a test. A dependency without a test is a risk.
What can be transferred, and what must be rebuilt
Separate data that can be exported and imported (accounts, balances, history) from configuration that must be recreated (groups, symbols, rules) and from integrations that must be rebuilt. For each, confirm the format, the owner of the export, the validation approach and the timing.
Where history cannot be moved, decide how it will be preserved and accessed, for example as an archive with a search interface.
Workflow assumption checks
Workflows may depend on behaviours of the old platform that are not documented: ordering of events, rounding, identifiers, time zones. Recheck each critical workflow in the new environment with test data. Differences in identifier formats or time zones are frequent causes of reconciliation errors after migration.
Write each assumption as a testable statement and run it before cut-over.
Sequenced transition
Sequence the work: build and configure the target, migrate a copy of the data, run integrations against the target in staging, rehearse the cut-over, execute with a freeze window, verify, then retire the old environment according to retention requirements. Define rollback criteria and a decision point.
See our migration roadmap for the full sequence.
Worked example: a forgotten report
Three days after cut-over, finance asks why the weekly partner statement is empty. The statement job was a script on an analyst’s laptop pointing at the old environment, and was missing from the inventory. The fix was quick, but it also affected one week of commissions and required manual correction.
Add a step to the inventory: interview each team about recurring tasks that touch trading data, and search schedulers, shared drives and mail rules for exports. People hold dependencies in their routines more than in documentation.
Communication dependencies
Clients, partners and vendors have dependencies too: server names in terminals, API endpoints in partner tools, allow-lists at payment providers. List each external party, what changes for them, when and who tells them.
Schedule notices with enough lead time, and confirm acknowledgement for critical parties such as payment providers and liquidity providers.
Freeze windows and change control
Migrations need a period during which non-essential changes are frozen on both source and target. Define the window, the exception process and who approves exceptions. Communicate it to every team that touches the systems, including marketing, which may otherwise launch a campaign that creates registrations in the middle of a cut-over.
During the freeze, track any approved change in a log with the reason. After cut-over, review the log to confirm that none of them invalidated the validation results, and re-run affected checks where necessary.
Frequently asked questions
Why inventory dependencies first?
Because undiscovered connections cause most post-migration incidents.
What must be rebuilt rather than moved?
Configuration and integrations are usually rebuilt, while accounts and history may be exported.
How do I test workflow assumptions?
Write each as a testable statement and run it in the new environment before cut-over.
When should I decide on rollback?
Define criteria and a decision point in advance.