Planning a Cloud Migration: Questions to Answer First

Mapping the current application estate

The starting point of any migration is an accurate inventory of what the organisation runs today. This includes applications, databases, integrations, scheduled jobs, and the infrastructure that supports them. Many estates have grown over years, and some components are poorly documented or no longer used. Recording each system with its owner, purpose, hosting location, and approximate resource profile creates the baseline against which every later decision can be tested.

Discovery is most useful when it combines tooling with conversation. Automated scans can reveal running servers and network connections, while interviews with the people who maintain each system reveal informal arrangements and undocumented behaviour. Comparing the two sources often exposes gaps in both. The resulting inventory should be treated as a living document, because estates continue to change while the migration is being planned.

A useful output of this step is a simple catalogue that classifies each system by its role and its condition. Retired applications can be identified for decommissioning rather than migration. Systems that are heavily customised or tied to older platforms can be flagged for closer review. This classification does not yet decide the approach for any system, but it narrows the field so that later analysis concentrates on the components that genuinely require it.

Deciding which workloads move first

Not every workload should move at the same time, or in the same order. Early candidates are often systems with fewer external dependencies, modest data volumes, and a well-understood operating profile. Moving such systems first gives the migration team practical experience with tooling, networking, and governance before more complex workloads are attempted. The selection should reflect business priorities as well as technical readiness.

Sequencing also depends on the business calendar. Systems that support seasonal activity, regulatory reporting, or critical operations may need to be scheduled around periods when change carries less risk. Conversely, some workloads may gain immediate benefit from relocation, such as those whose capacity needs are variable. Documenting the reasons for each position in the order helps stakeholders understand trade-offs and reduces later disagreement.

Wave planning is a common way to group workloads. Each wave collects systems that share dependencies or can be moved with a similar method, and each wave has explicit entry and exit conditions. Grouping in this way limits the number of simultaneous changes and makes it easier to isolate problems when they occur. The order of waves should be revisited as earlier results become known.

• Business criticality and tolerance for disruption
• Number and strength of dependencies on other systems
• Data volume and the effort required to transfer it
• Current platform age and support status
• Availability of skilled staff who understand the system

Assessing dependencies and data sensitivity

Applications seldom operate in isolation. They call other services, read shared databases, depend on directory systems, and rely on network paths that may not be obvious from their configuration. Mapping these dependencies before migration reveals which systems must move together and which can be separated safely. Missing a dependency is one of the more common causes of unexpected failure after a move, so this mapping deserves careful attention.

Data sensitivity shapes both the destination and the controls that must accompany it. Information may be subject to contractual obligations, personal data rules, sector regulation, or internal classification policies. These requirements can determine which regions may host the data, which encryption and access controls are needed, and how audit records are kept. Identifying the sensitivity of each dataset early prevents costly redesign once the migration is under way.

The assessment should also consider data residency, retention periods, and the legal basis for processing where relevant. Teams often discover that copies of sensitive data exist in places that were not anticipated, such as test environments or exported reports. Recording where data is held, who may access it, and how long it must be retained gives the migration a defensible foundation. Reviewing these findings with legal and security colleagues is generally more effective than resolving them after transfer.

Choosing a migration approach for each system

Once the estate is mapped and priorities are set, the next question is how each system should reach the cloud. Rehosting, often called lift and shift, moves a workload with minimal change and is usually the fastest path, though it rarely captures the full benefits of cloud-native services. Replatforming makes limited adjustments, such as moving a database to a managed service, while keeping the core application intact. Refactoring or rearchitecting requires deeper change but can improve scalability and operating cost over time.

Retiring and replacing are also valid outcomes. Some systems no longer justify their running cost, and a SaaS application may serve the same purpose with less effort to maintain. Retaining a system on premises for the time being can be a deliberate decision, for example where a dependency or regulatory constraint is still being resolved. Each choice should be recorded with its reasoning so that later reviews can revisit it.

The approach selected for one system often affects its neighbours, so decisions should be checked against the dependency map from earlier planning. A rehosted application that depends on a retained database may face new latency, and that effect should be understood before cutover rather than discovered afterwards. Treating the approach as a per-system decision, supported by a clear rationale, keeps the overall migration coherent.

• Rehost: move with minimal change, fastest path
• Replatform: make limited adjustments to use managed services
• Refactor: redesign for cloud-native scalability and efficiency
• Replace: adopt a SaaS application in place of the system
• Retire: decommission systems that no longer have a clear purpose
• Retain: keep on premises for a defined period with a stated reason

Setting rollback and testing criteria

Before any workload is switched over, the team needs agreed criteria for two outcomes: when to reverse the move, and when the migrated system is considered accepted. Rollback criteria should name measurable conditions, such as error rates, response times or data reconciliation results, along with the person authorised to trigger the reversal. Without these thresholds agreed in advance, decisions made under pressure during a cutover tend to be inconsistent and slow.

Testing criteria should cover functional behaviour, performance under realistic load, security controls, and recovery procedures. Data validation deserves particular attention, since a migration can succeed in terms of uptime while silently altering or losing records. Test runs in a non-production environment give the team a chance to measure timing, including how long a rollback would take, which is often underestimated.

Documenting these criteria alongside the cutover plan makes the migration auditable and repeatable. Each criterion should have an owner, a method of verification and a point in the schedule at which it is checked. This record also becomes a reference for later changes, so that future releases can be assessed against the same standards.

Defining ownership after the move

A migration does not end at cutover, and the question of who operates each service afterwards is easy to leave unresolved. Responsibilities for patching, monitoring, access management, cost review and incident response should be assigned to named roles rather than to a general team. Where the organisation uses a cloud provider's shared responsibility model, the division between provider and customer tasks should be written down for each service.

Ownership also covers the decisions that continue after the move, such as scaling thresholds, backup schedules and retention policies. Clear ownership of these items prevents gaps in which every party assumes another is responsible. Regular reviews, scheduled at intervals the team agrees on, help confirm that the assignments still match how the systems are used.

The handover is most reliable when it is planned as a process rather than an event. Runbooks, contact paths and escalation routes should be tested with the people who will use them, and any unresolved ownership questions should be closed before the migration is declared complete. A system with a known owner is far easier to improve, secure and retire when the time comes.