Cloud & Delivery

Cloud Migration

Term 9 of 68 in the ERPStack technical glossary

What is Cloud Migration?

Cloud migration is the strategic process of moving an organization's digital assets, legacy database systems, servers, and business applications from on-premises hardware or legacy datacenters into a modern cloud hosting infrastructure.

Cloud Migration at a glance

Strategies: Rehost, replatform, refactor, repurchase, retire, retain — 6 options, rarely just 1
Sequencing: Move 1 workload at a time behind a routing facade, not 100% in a single weekend
Target shape: Private subnets in a Virtual Private Cloud, defined in Terraform, with 0 public database endpoints
Cost trap: Lift-and-shift of an always-on fleet, which reproduces on-premise spend with 2 bills instead of 1
Built with: AWS, Microsoft Azure or Vercel targets defined in Terraform, Docker and Kubernetes for portability, PostgreSQL 18 as the destination store, cutover run through GitHub Actions with Sentry watching
Numbers that matter: 6 strategies; 1 workload at a time; 2 bills during transition; 3 things to fix first — hostnames, shared file systems, credentials in config
Target platforms: AWS, Microsoft Azure and Vercel, with Docker or Kubernetes for portable workloads
Commonly paired with: Terraform, GitHub Actions, the Strangler Fig Migration Pattern, Docker and Kubernetes portability, PostgreSQL 18 replication, Sentry and FinOps cost tracking
Cutover mechanics: Logical replication from the legacy PostgreSQL database into the target, Redis warmed before the window, and Edge Caching / CDN in front of static assets; DNS time-to-live dropped to 60 seconds at least 24 hours ahead so a rollback propagates in 1 minute.
Hardest estates: Regulated workloads in healthcare, finance and government, where day 1 on the new platform has to produce the evidence day 0 produced. Keep the source system readable for 30 days after cutover rather than 0.

How Cloud Migration works in production

Migrating legacy systems to the cloud is a critical step in modernizing business operations. Many corporations run on old, physical servers located in their offices, which are expensive to maintain, vulnerable to physical damage, and difficult to scale. A cloud migration project involves data extraction, application modernization, and VPC network setup.

The ERPStack approach to Cloud Migration

We design and execute cloud migration pipelines, migrating legacy database systems to AWS or Vercel. We configure secure, private database subnets and implement auto-scaling server configurations to lower your running costs.

Related Resources

Frequently asked questions about Cloud Migration

What are the main Cloud Migration strategies?

Six, and most programmes use several. Rehosting moves a workload unchanged; replatforming makes targeted changes such as adopting a managed database; refactoring rebuilds for cloud-native operation; repurchasing replaces it with a product; retiring removes what nobody uses; retaining leaves it alone for now. A Cloud Migration plan that applies 1 strategy to everything is usually optimising for the plan rather than the estate.

Why does lift-and-shift often cost more than expected?

Because it moves the shape as well as the workload. A Cloud Migration that rehosts always-on servers pays hourly for capacity that was previously a sunk asset, and it inherits none of the elasticity that makes cloud economics work. The saving comes from workloads that scale down when idle, managed services that remove operational labour, and retiring machines nobody could decommission before.

How do you migrate a database with minimal downtime?

By replicating first and cutting over second. A Cloud Migration for a stateful system typically establishes continuous replication to the target, verifies data equivalence, then switches writes during a short window. The genuinely difficult part is not the copy — it is deciding what happens to in-flight work at the moment of cutover, and having a tested path back if verification fails afterwards.

What should be fixed before migrating rather than after?

Anything that gets harder once running in 2 places. Hard-coded hostnames, shared file-system assumptions, manual configuration steps and credentials in configuration files all become more painful mid-migration. A Cloud Migration also exposes network assumptions that were invisible when everything sat on 1 subnet, so mapping actual traffic between components is worth doing before the first workload moves.