A migration proposal can look complete when it lists servers and a destination. The harder questions concern the work those servers support. Can staff continue processing orders? When does a scheduled export run? Who checks the records after transfer? A cloud migration plan should connect infrastructure decisions to these everyday activities. Use the following sequence to turn a broad move into work that can be reviewed.
On this page
Define the operational improvement
Replace “move to the cloud” with a reason that can be assessed. Perhaps releases depend on one manually configured server, or a busy period requires capacity the current setup cannot provide. Record the present behaviour before specifying the future environment. Without that baseline, it is difficult to tell whether the move solved the original problem or simply changed where it happens.
- Name the affected workflow and its owner.
- Describe an observable improvement, such as a repeatable deployment process.
- List constraints that the move must respect.
Map the connections around each workload
For each application, list its database, file storage, scheduled jobs, external services and access requirements. Ask the people who operate it to review the map. An overnight report or a supplier connection can be easy to miss in a server inventory. Mark which dependencies need to move together and which connections can remain in place during a staged transition.
Choose a migration approach per application
Illustrative decision: a customer portal uses a supported runtime but shares a database with an older accounts application. Moving the portal first may be reasonable only if the remaining database connection meets the agreed access and performance requirements. Otherwise, move the connected workloads together or resolve the dependency first. Compare a direct move, targeted changes and redevelopment against this application’s needs; the whole estate does not need one approach.
Design how the new environment will run
Assign ownership for access, deployments, alerts, backups and spending reviews. Estimate demand using available usage information, including quieter periods and peaks. Ask how the estimate changes when storage grows or data moves between services. A useful cost discussion explains its assumptions and what will be monitored after launch, rather than treating the first estimate as a fixed operating bill.
- Who can change production settings?
- Who responds when a job fails?
- How will backup restoration be checked?
Set a rollback decision before cutover
For the illustrative portal, agree how the team will verify login, order submission and record counts before opening the new environment. Define which failures stop the transition and who makes that decision. If users can create new records after cutover, returning traffic to the old server is insufficient: those records need an agreed handling plan. Rehearse the sequence, including the point beyond which rollback needs additional data work.
Close the migration through operating checks
After the move, review the workflows, scheduled tasks, alerts and usage patterns against the agreed baseline. Give unresolved issues an owner. Retire the old environment only after the team has completed its transition checks and decided which data or configuration must be retained. Keep the application map and recovery instructions available to whoever will maintain the service.