What Is Cloud Migration

What Is Cloud Migration?

Cloud migration is the process of moving applications, data, infrastructure, or operational processes from one environment into cloud services. That environment might be an on-premises data centre, a hosted server, a private cloud, or another public cloud. A migration can be small, such as moving a static asset library to object storage, or large, such as shifting a business-critical application and its databases to a new cloud platform.

The word "migration" can make the work sound like a simple move. In practice, it is a controlled change to architecture, ownership, security boundaries, cost models, performance behaviour, and incident response. A server may be easier to copy than an operating model. Successful migrations define what must move, what should be redesigned, what can be retired, and what evidence proves the new environment is safe enough to use.

What actually moves?

Most cloud migrations involve more than compute. Teams need to account for:

• Application code, runtime versions, dependencies, build pipelines, and deployment processes.
• Databases, storage buckets, file shares, backups, queues, caches, and search indexes.
• Network paths, DNS records, TLS certificates, load balancers, firewalls, and routing policies.
• Identity providers, service accounts, secrets, keys, administrator roles, and access reviews.
• Logs, metrics, traces, alerts, dashboards, runbooks, and incident escalation paths.
• Compliance evidence, data residency requirements, retention rules, and audit trails.

A migration plan should map these dependencies before any cutover. If a team only maps the main application server, it may miss a background job, an external payment callback, a legacy admin interface, or a reporting export that still depends on the old environment.

Common migration approaches

The simplest approach is rehosting, often called "lift and shift". The application is moved with limited redesign. This can reduce data centre dependence quickly, but it may carry old inefficiencies and security assumptions into the cloud.

Replatforming changes parts of the stack without changing the core application. A team might move from self-managed databases to managed databases, or from local storage to cloud object storage. Replatforming can improve reliability and operations, but it requires careful testing because managed services behave differently under load, failure, backup, and restore.

Refactoring redesigns the application for cloud-native patterns. This can mean splitting services, adopting containers, changing authentication flows, or moving workloads to event-driven platforms. Refactoring can produce the strongest long-term result, but it carries more delivery risk and should be staged with clear rollback points.

Retaining and retiring are also migration decisions. Some systems should stay where they are until a dependency changes. Others should be shut down rather than moved. Not migrating a system is sometimes the correct security and cost decision.

Planning the traffic path

Public-facing migrations are often won or lost at the traffic layer. DNS records, TLS certificate coverage, CDN or edge routing, origin hostnames, health checks, firewall rules, and cache policy all need to line up. A small mismatch can create user-visible downtime, broken logins, stale content, or exposed origin servers.

Before cutover, teams should test the new route with realistic traffic. That includes authenticated journeys, API calls, file uploads, checkout or booking flows, webhooks, search engines, mobile clients, and automated jobs. Testing should cover response headers, redirects, cache behaviour, request body limits, timeouts, and error handling. If the application sits behind an edge or reverse proxy, origin access should be restricted so attackers cannot bypass the intended controls.

Security work during migration

Cloud migration changes the shared responsibility model. The cloud provider operates part of the infrastructure, but the customer still owns configuration, identity, data protection, application security, and monitoring. Many incidents in migrated environments come from assumptions that were true in the old environment but false in the new one.

Important security checks include least-privilege access, private-by-default storage, encryption for data in transit and at rest, secure secret storage, multi-factor access for administrators, logging on control-plane and application events, and backup restore testing. Teams should also review Internet exposure. A database or management interface that was protected by a physical network may become reachable through a misconfigured cloud security group or public endpoint.

Application-layer security should be validated as well. A migration can change source IP visibility, header trust, TLS termination, rate limiting, bot controls, session cookies, and API gateway behaviour. If security rules depend on request metadata, verify that the metadata is still present and trustworthy after the new routing path is in place.

Cutover and validation

A safe cutover has an explicit sequence, owners, health checks, and rollback conditions. Blue-green deployments, phased DNS changes, weighted routing, and canary releases can reduce risk. For data-heavy systems, teams also need a strategy for replication lag, dual writes, read-only windows, or final synchronisation.

Validation should use both technical and business signals. Technical checks include error rates, latency, cache hit rates, database health, queue depth, TLS errors, WAF or firewall events, and origin load. Business checks include successful logins, orders, bookings, content updates, support tickets, and customer-visible transaction rates. A migration is not complete when traffic starts flowing. It is complete when the new environment is stable, observable, secured, documented, and supported.

Common failure modes

The most common failure is incomplete dependency mapping. A forgotten integration may only fail after a partner posts a webhook, a batch export runs, or a seasonal traffic spike arrives. Another failure is treating migration as purely technical. If ownership, alerts, runbooks, and access reviews are not updated, responders may not know who can fix the system during an incident.

Cost surprises are also common. Cloud pricing depends on compute size, storage class, data transfer, logging volume, managed service options, and support patterns. A design that is technically correct can still be expensive if data moves between regions, cache policy is weak, or logs are retained without a purpose.

Finally, teams sometimes skip decommissioning. Old servers, DNS records, certificates, backups, credentials, and firewall exceptions should be removed or formally retained. Leaving the old environment half-alive creates cost, confusion, and attack surface.

The operational takeaway

Cloud migration is not just moving workloads. It is a chance to make the system more observable, more resilient, and easier to secure. The best migrations keep a clear inventory, test the real user path, preserve rollback options, and use evidence rather than hope to decide when the new environment is ready.