Begin with the business change, not the destination
A cloud migration is not complete when a virtual machine starts in a new location. It is complete when the intended business service works, authorised users can reach it, data is protected, operations can support it and the cost model is understood. Start by writing the outcome in plain language. Is the organisation seeking faster environment provisioning, less dependence on ageing hardware, improved recovery options, support for a distributed workforce or a route to application modernisation? Each objective produces a different sequence and target design.
Identify the decision owner, technical owner, application owner and people who will accept the migrated service. Agree what is outside the first phase. A bounded migration wave is easier to validate than an instruction to move everything. It also gives the team evidence about network behaviour, identity integration, backup, monitoring and support before business-critical workloads are scheduled.
- What business constraint or opportunity is driving the move?
- Which measurable service conditions must be preserved or improved?
- Who can accept the design, cutover and post-migration support model?
- What must remain on-premises or be deferred, and why?
Do we understand the workload and its dependencies?
An inventory should describe services, not just servers. A customer portal might depend on identity, DNS, certificates, a database, file shares, batch integrations, outbound email, third-party allowlists and an overnight reporting job. Moving one component without the others can create latency, security or availability problems even when the migrated server itself appears healthy.
For each workload, record operating system and version, data volume and growth, CPU and memory profile, peak periods, inbound and outbound connections, privileged access, licensing constraints, backup and recovery needs, maintenance windows and business criticality. Use monitoring and stakeholder interviews together: utilisation graphs show technical patterns, while users reveal month-end peaks, manual dependencies and service expectations that dashboards may miss.
- Which systems call this workload, and which systems does it call?
- Are IP addresses, host names, certificates, service accounts or hardware identifiers embedded in its configuration?
- Does the software vendor support the proposed cloud architecture and operating-system version?
- How much downtime and data loss can the business process tolerate?
Where should each workload run?
Cloud is a set of placement choices rather than one architecture. A workload might be rehosted on virtual machines, moved to a managed database, rebuilt around platform services, replaced by software as a service or retained where it is. The quickest technical move is not always the lowest-risk or most economical lifecycle choice. Rehosting can preserve familiar operations but also preserve patching, capacity and architectural debt.
Compare Azure, AWS or another approved platform only after the organisation has stated its constraints. Consider service availability in the required region, data location, skills, network integration, identity, vendor support, exit options and the effect of managed services on application change. Document the reason for each placement decision so it can be revisited when the workload or platform changes.
Are identity, security and data controls designed?
Decide how workforce and workload identities will authenticate, how privileged access will be separated and how emergency access will be controlled. Multi-factor authentication, role-based permissions and central logging are strongest when designed before resources multiply. Service accounts, automation identities and secrets need owners, rotation methods and a secure store; copying credentials from an existing server is not a migration strategy.
Classify the data, identify applicable retention and location requirements, and map encryption, key ownership and access logging. Design network boundaries and private connectivity where required. Cloud platforms provide security capabilities, but the customer still configures identities, data access, workloads and many monitoring controls. Record that shared-responsibility boundary in the operating model rather than leaving it implicit.
- Which users, administrators, applications and third parties require access?
- Who approves privileges, and how are they reviewed and removed?
- Which data sets are sensitive, regulated, retained or subject to deletion requirements?
- Where will security events go, and who will investigate them?
Can connectivity, continuity and cutover be proven?
Model normal and peak traffic between users, offices, the internet, retained systems and the cloud. Check bandwidth, latency, name resolution, routing, address overlap, firewall policy and redundant paths. A workload can have ample cloud compute and still feel slow because each user transaction repeatedly crosses a constrained connection to a database that stayed behind.
Define a cutover runbook with prerequisites, data synchronisation, change freeze, validation, communication, decision points and rollback criteria. Backup should cover the new location from the start, but backup alone does not create a recovery plan. Specify recovery time and recovery point objectives, restore dependencies and the people authorised to declare or end a recovery event. Rehearse with representative data before the live move.
Who will operate and pay for the environment?
A migration changes daily work. Name owners for patching, backup, monitoring, incident response, cost review, access administration and platform changes. Set alert thresholds and escalation routes that the team can realistically support. If ongoing managed support is required, define its scope, hours, response commitments and exclusions separately from the migration project.
Estimate cost from the proposed architecture and realistic usage: compute schedules, storage tiers and growth, snapshots, backup, outbound data transfer, security services, support and connectivity. Tag resources to an owner and service, establish budgets and review reservations or commitments only after demand is understood. Validate a pilot against technical, security, recovery, user-experience and cost criteria. The best migration plan is one the organisation can explain, test and operate—not merely one that can be deployed.
- Create an owner, purpose, environment and cost-centre tagging standard.
- Define acceptance tests before the pilot begins.
- Capture runbooks, diagrams, configuration decisions and known limitations during delivery.
- Schedule a post-migration review after usage patterns stabilise.