A cloud migration rarely succeeds by accident: it relies on an accurate inventory, a written cutover plan and a tested rollback. This guide describes the method we apply to infrastructures supported by Open Vista, from the initial audit to the verification after cut-over.
1. Inventory what you run today
The audit starts with a complete map of the current estate:
- servers and virtual machines, their role, operating system and version;
- applications and their dependencies (database, queue, cache, shared storage);
- data volumes, growth rate and retention requirements;
- DNS names, records and time-to-live (TTL);
- TLS certificates, mailboxes, inbound and outbound flows;
- scheduled tasks, internal scripts and third-party integrations;
- existing backups and the date of the last restore test.
Collect real metrics (vCPU, memory, IOPS, bandwidth) over two to four weeks as well: those numbers size the target, not the original data sheets.
2. Write the migration plan
The plan is written before production is touched. It sets the split into successive waves, from the least critical workload to the most critical, and the dependency order between applications. For each service it also states an announced cut-over window, a recovery time objective and an acceptable data loss, a simple matrix of who executes, who checks and who decides, and explicit go/no-go criteria. A plan that the business teams have not validated is not a plan.
3. Prepare the target and rehearse
The target is provisioned and sized from the audit measurements. Before cut-over, the environment is rebuilt and tested outside production: data restore, certificate installation, replay of scheduled tasks, functional tests, performance measurement under realistic load. A pilot site, chosen for its low impact and its representativeness, validates the full procedure before it is rolled out.
4. Perform the cut-over
The cut-over runs inside a frozen change window. Lower the TTL of the DNS records 24 to 48 hours in advance so propagation stays short. After the final synchronisation, check at least:
dig +short www.example.com curl -sI https://www.example.com | head -1
Then verify authentication, mail sending and receiving, outbound webhooks, scheduled tasks, logging and integrations. Every check has an expected result and an owner; a failed check triggers the rollback.
5. Keep a usable rollback
Rollback is only credible when it is prepared and tested. Keep the old infrastructure running for the agreed observation period, keep the full backups taken just before cut-over, and keep a written procedure stating the return delay, the steps and who decides to use it. Decommission the former environment only after validation by users and by the operations team.
6. Stabilise after the move
The first four weeks are for observation: availability, response time, saturation, costs. You adjust resources, review alerts and backups, harden access and train the teams on the new habits. A short migration report records the gaps found, the decisions taken and the points to watch, so the next migration is shorter.
