Capture the estate before moving it
Record platform and component versions, permitted access, configured groups and symbols, connected services and scheduled jobs. Identify which information the brokerage can export and which tasks require the current provider. A migration plan cannot rely on access that has not been confirmed.
Create a dependency diagram for data feeds, bridges, CRM, reporting and administrative users. Check where credentials, network restrictions or file locations are tied to the existing machine or provider. An apparently simple host replacement can expose a long-standing undocumented dependency.
Use a workload and recovery baseline
| Baseline | Observe | Use the result to decide |
|---|---|---|
| Client workflow | Login, data access and relevant account operations | Which checks must pass on the replacement |
| Resource behaviour | CPU, memory, storage and network during representative activity | Whether the constraint is hosting or another dependency |
| Background jobs | Reports, exports and maintenance timing | Which tasks need isolation or rescheduling |
| Recovery state | Available data, configuration and restoration evidence | What can actually be restored after a failure |
The baseline should represent the brokerage’s own workflow. Avoid interpreting one synthetic benchmark as a complete acceptance test for an MT4 environment.
Rehearse the move
- Confirm the rights, access and cooperation needed from all providers.
- Build an isolated replacement environment and validate the available configuration.
- Test the connected services using representative accounts and symbols.
- Agree the cutover checks, decision owner and criteria for returning to the previous environment.
If the existing service remains available during validation, define how configuration changes are tracked so the replacement does not become stale before release. Do not treat a successful startup as proof of correct integrations or complete reporting.
Keep the handover useful after launch
Document the active hosting boundary, monitoring coverage, authorised support contacts and maintenance procedure. The brokerage should receive enough information to understand an incident and the expected recovery steps without depending on a single undocumented account.
Review the MT4 White Label scope when platform access and hosting are part of the same arrangement. Keep the existing dependency inventory even if no migration happens immediately; it is also useful for a later MT4 to MT5 assessment.