Cloud Migration is the process of moving applications, data, infrastructure, workloads or technology capabilities from an existing environment into a cloud environment. The source may be an on-premises data centre, colocation facility, another cloud provider, a hosted platform or a legacy application environment. Migration can involve simple relocation or substantial redesign.
A common classification uses approaches such as rehosting, in which workloads are moved with relatively little modification; replatforming, in which selected components are changed to take advantage of cloud capabilities; refactoring or rearchitecting, in which applications are substantially redesigned; repurchasing, in which an existing capability is replaced by a cloud-delivered product; retaining, in which a workload remains in its existing environment; and retiring, in which unnecessary systems are removed. These approaches are often discussed as migration strategies because moving the workload is only one part of the broader transformation.
Cloud Migration typically begins with discovery and assessment. Organisations need an inventory of applications, servers, databases, storage systems, network connections, users, interfaces, licences and dependencies. Dependency mapping is especially important because applications rarely operate independently. A server may depend on a database, authentication service, file share, DNS system, external API or scheduled processing system located elsewhere. Performance baselines can establish current CPU, memory, storage, network and transaction requirements.
Business information such as criticality, recovery objectives, regulatory classification and maintenance windows is also relevant. Without sufficient discovery, migrations can fail because hidden dependencies are discovered only after a workload has been moved. Automated discovery tools can help, but human knowledge from application owners and operations teams remains important.
Rehosting, often called lift and shift, moves a workload to cloud infrastructure with relatively few application changes. It can accelerate migration and reduce immediate redevelopment effort, particularly for applications that already operate effectively on virtual machines. Replatforming makes targeted changes without fundamentally redesigning the application, such as moving a self-managed database to a managed database service or changing storage mechanisms. Refactoring involves redesigning application components to exploit cloud-native characteristics such as independent scaling, managed services or event-driven processing. Repurchasing may replace a custom application with a Software as a Service product, while retiring removes workloads that no longer provide sufficient value. Retaining is equally important because not every application should be migrated immediately or at all.
Data migration presents distinct technical challenges. Large datasets can take considerable time to transfer, and continuous services may continue changing data while the initial migration is underway. Techniques such as bulk transfer followed by incremental replication can reduce downtime. Database migration may require schema conversion, compatibility testing, replication, change-data capture or application modifications. Storage migration must account for permissions, metadata, file paths, object identifiers and consistency requirements. Encryption and access controls must remain effective during transfer and after arrival. Data integrity validation is essential because a migration that completes technically but produces incomplete or inconsistent data can create serious operational consequences. Recovery copies and rollback plans should be established before destructive changes are made to the source environment.
Application migration also requires testing beyond basic functionality. Functional testing confirms that application features continue to work, while performance testing determines whether the migrated environment provides acceptable latency and throughput. Security testing can identify changed permissions, exposed interfaces or incorrect network controls. Resilience testing evaluates behaviour during infrastructure or service failures. Compatibility testing may be required where applications depend on operating-system versions, drivers, libraries, database engines or proprietary hardware. User acceptance testing provides evidence that business processes continue to function. Cutover plans should specify sequencing, responsibilities, validation checks and rollback criteria. A migration is therefore an operational change programme rather than merely a file-transfer exercise.
Migration can provide opportunities for modernisation, but the two concepts should remain distinct. An organisation can migrate a workload without modernising it, and it can modernise components before or after migration. Combining migration with redesign can produce greater long-term benefits but usually increases project complexity and risk. A staged approach can reduce risk by first establishing a stable cloud baseline and then modernising selected components. Conversely, migrating obsolete systems without addressing fundamental architectural problems can preserve technical debt in a new environment. Migration planning should therefore consider the workload's expected lifespan, strategic importance, operational problems and potential replacement options before choosing how much engineering effort to invest.
Cloud Migration has financial dimensions as well as technical ones. Organisations must account for migration tooling, temporary duplicated infrastructure, data-transfer charges, professional services, staff time, application redevelopment and ongoing cloud consumption. During transition, both source and target environments may need to operate simultaneously, increasing costs. After migration, costs can differ substantially from forecasts if workload utilisation, storage growth or network traffic was underestimated. A sound business case therefore compares total cost of ownership rather than only infrastructure purchase costs. Cost monitoring should continue after migration because actual usage provides better evidence than initial estimates and can reveal opportunities for rightsizing, scheduling or architectural optimisation.
Successful Cloud Migration normally depends on governance, clear ownership and staged execution. Migration waves can group workloads according to dependency relationships, business criticality or technical similarity. Pilot migrations can reveal process weaknesses before large-scale execution. Automated infrastructure provisioning and repeatable deployment procedures reduce variation between environments. Detailed rollback procedures protect against failed cutovers. Post-migration validation should confirm application functionality, data integrity, security controls, monitoring, backups and operational ownership. Cloud Migration is therefore best regarded as a controlled transformation of workload location and operating model. The technical act of moving resources is only one element of a broader process involving discovery, planning, dependency management, testing, cutover, optimisation and eventual decommissioning of obsolete infrastructure.
