A planned migration and an unexpected recovery have different triggers, but both benefit from a clear inventory, usable recovery material and agreed validation checks.
Understand the environment
List the affected servers, platform components, configurations and external connections. Record the access available to your team and any provider restrictions that affect the work.
Keep a useful timeline
For an incident, note when the issue started, what symptoms appeared and which changes preceded it. For a migration, document the starting state and the intended destination. Keep observations separate from assumptions.
Review the available material
Identify the backups, configuration records and other restoration inputs that are actually available. Confirm what they contain and whether their condition can be checked. A backup name alone is not evidence of a complete recovery path.
Agree the sequence and checks
- Prioritise the components and workflows that need attention.
- Define an isolated validation stage where practical.
- Agree the maintenance window and communication owner.
- Document rollback steps for a planned migration.
- List the checks required before normal operations resume.
Capture the result
Record what was restored or moved, the checks performed and any open issues. Review monitoring and backup arrangements after the work so the operating plan reflects the new environment.
Start with a recovery assessment or discuss a planned move through the server infrastructure service.
Choose the appropriate technical starting point
For a planned move, start with a server infrastructure and migration assessment. For an incident, use the MT4 and MT5 recovery assessment. Both discussions should identify the environment, the available material and the checks required before normal operations resume.