Design the target and identify what changes
| Item | Question |
|---|---|
| Platform scope | Which components, versions and configuration are in the move? |
| External dependencies | Which feeds, routes, integrations and provider permissions must change? |
| Access | Who can administer the source and target, and by what approved path? |
| Data treatment | Which records move, which remain available and how are they checked? |
Document the present environment before building the target. Treat unknown dependencies as open decisions rather than assuming a file copy will recreate them.
Validate the target before the production switch
Demonstrate approved account and operator workflows, instrument configuration, market-data reception and relevant integration paths. Use an authorised test arrangement that cannot unintentionally conflict with live operation. Capture versions and results so the target can be compared with the baseline.
Prepare the configuration freeze or synchronisation process, final reconciliation responsibility and the precise steps for changing the required traffic or endpoints. The procedure must reflect the provider-supported platform arrangement.
Agree rollback as a business and data decision
Specify the observations that can stop the cutover and who has authority to make that call. Once new activity has occurred, returning to an earlier state may require reconciliation; do not describe rollback as a simple reversal without accounting for that activity.
Retain a cutover log and confirm the agreed workflows after the switch. Use the MT5 migration checklist to track readiness, or discuss an implementation and coordination scope if several technical parties need to act together. Keep recovery responsibilities documented after completion.