Home · About · Services · Industries · Projects · Products · Process · Blog · FAQ · Contact
Lift-and-shift vs re-platforming: choosing a cloud migration approach Rehost or replatform? How we decide, workload by workload, what each approach costs in effort and risk, and the small changes worth making during a move.
A team has a handful of applications on servers in a rack or with a hosting company. The contract is ending, so they need to be in AWS or Azure within a few months. Someone suggests copying the servers across as they are. Someone else says that wastes the move and the database should become a managed service at the same time. Both are right for some workloads. The useful question is which approach fits each one.
The short answer: lift-and-shift (rehosting) moves a workload to the cloud with no code or architecture changes, so it is fastest and lowest risk but keeps today's operating costs and chores. Re-platforming makes a few targeted changes, usually moving the database, storage or runtime to managed services, for lower running effort in exchange for more testing up front.
What each approach actually means The terms come from the "Rs" of migration: AWS describes seven, and Microsoft's Cloud Adoption Framework uses a similar set. Rehost and replatform are the two most teams choose between, but it helps to see the whole set, because some workloads should not be migrated at all.
Rehost (lift-and-shift): the same operating system, application and configuration, now on a cloud virtual machine. Tools such as AWS Application Migration Service and Azure Migrate replicate the server disks and let you cut over. Replatform (lift, tinker and shift): the application code stays largely the same, but parts of the platform change. Self-managed PostgreSQL becomes Amazon RDS or Azure Database for PostgreSQL, local file storage becomes S3 or Blob Storage, a hand-built server becomes a container. Refactor: the application is redesigned for the cloud, for example split into services or rewritten around serverless functions. This is a software project, not a migration. Repurchase, retain and retire: switch to a SaaS product, leave the workload where it is for now, or switch it off. Most inventories turn up at least one application nobody uses any more. Retiring it is the cheapest migration there is.
When lift-and-shift is the right call Rehosting gets an unfair reputation. It is the right choice more often than people expect, particularly when the deadline is driven by a lease, a hardware failure or a data centre exit.
There is a hard date and the main goal is to get out of the current location safely. The application is a vendor product or old codebase that nobody can change with confidence. It depends on things a managed service will not allow, such as specific OS packages, file system paths, or database extensions and superuser access. The workload is stable, small and rarely touched, so the savings from changing it would never repay the effort. The team wants to learn the new cloud on familiar ground before changing how things run. The trade-offs are real, though. You still patch the operating system, manage disk space, run the database and handle its backups. Servers sized for old hardware are often too big, so rehosted workloads frequently cost more than expected until someone right-sizes them. And anything fragile on-premises, such as a cron job only one person understands, arrives in the cloud equally fragile.
When re-platforming pays for itself Re-platforming makes sense when a small, well-understood change removes a large amount of ongoing work. The database is the usual candidate. A managed PostgreSQL or MySQL service handles minor version patching, automated backups with point-in-time restore, and optional standby replicas in another availability zone. Those are chores teams often do badly on their own servers.
The database is the riskiest part of the current setup: backups are untested, or failover is manual and undocumented. The application stores uploads on local disk, which blocks running more than one instance. Moving files to object storage fixes that and is usually a contained code change. The app already runs, or could easily run, in a container, so moving to a container platform such as Azure Container Apps or Amazon ECS is mostly packaging. Operating system end of life is close, so you would be rebuilding the server anyway. Nobody on the team wants to be on call for a database server. The cost is testing time and some lost control. Managed databases restrict extensions, superuser access and some configuration parameters, so check every extension and setting your application uses against the provider's supported list before committing. Also check connection limits, which on smaller managed instances can be lower than an application with a large connection pool expects.
A practical way to decide, workload by workload We rarely pick one approach for a whole estate. We list every application with its servers, databases, scheduled jobs, inbound and outbound connections and owner, then ask four questions of each:
Can anyone safely change this code? If not, rehost it or leave it where it is. What hurts most about running it today? If the answer is the database or file storage, replatform that piece. How much downtime can the cutover take? Long acceptable windows make database moves simple; short ones need replication. Is it worth keeping? If usage is low and a SaaS product covers it, repurchase or retire. A common outcome is a mix: the main business application is replatformed onto managed PostgreSQL and object storage, a legacy reporting tool is rehosted untouched, and two internal utilities are retired. It is also fine to rehost first and replatform later. That keeps each step small, as long as the second step is actually scheduled rather than left as a vague intention.
One rule we hold to: do not change the application and its platform in the same cutover unless you must. If a migration moves the database to a managed service and upgrades the framework at once, and something breaks, you do not know which change caused it.
What a small replatform looks like For a PostgreSQL database of a few tens of gigabytes where an evening maintenance window is acceptable, a dump and restore is the simplest reliable path. Managed services do not grant true superuser, so restore without ownership and privilege statements and recreate grants for the application role afterwards.
# A day or two before: lower the TTL on the app's DNS record
# and confirm resolvers see the new value
dig +noall +answer app.example.com
# In the window: stop the app, then dump in custom format
pg_dump -h old-db.internal -U postgres -Fc -f app.dump appdb
# Restore into the managed instance using parallel jobs
pg_restore -h appdb.xxxxxx.eu-west-1.rds.amazonaws.com \
-U appadmin -d appdb --no-owner --no-privileges -j 4 app.dump
# Refresh planner statistics, then compare row counts
psql -h appdb.xxxxxx.eu-west-1.rds.amazonaws.com -U appadmin -d appdb \
-c 'ANALYZE;' \
-c 'SELECT count(*) FROM orders;'Rehearse this against a copy first and time it. The rehearsal tells you whether the window is long enough. If it is not, use logical replication or a service such as AWS Database Migration Service or Azure Database Migration Service to keep the new database in sync, so the cutover itself takes minutes. Keep the source database untouched and read-only for an agreed period, because it is your rollback plan.
Make sure the target runs the same or a newer major PostgreSQL version, and run pg_dump and pg_restore from the client tools of the newer version. Check that the application's database driver supports it too. Then update the connection settings, which should already live in environment variables or a secrets store rather than in code. If they are hard-coded, that is the first small change of the replatform.
Costs and risks people underestimate Data transfer: moving data into the cloud is usually free, but traffic out of it and between regions or zones is charged, and chatty applications split across locations can surprise you. Right-sizing: copy the old server's size and you pay for its headroom. Measure CPU and memory for a few weeks after the move and resize. Licences: some commercial software licences are tied to hardware or cores and may not transfer to cloud VMs on the same terms. Check before the move, not after. Hidden dependencies: a nightly job that writes to a shared drive, an IP allow-list at a partner, an SMTP relay on the old network. The inventory is where these surface. Running both sides: for a few weeks you pay for old and new together. Plan for it. Before you choose Inventory every application, its data, jobs and connections, and name an owner for each. Mark candidates to retire or replace before migrating anything. Default to rehost for anything you cannot safely change or that has a hard deadline. Replatform the piece that causes the most operational pain, usually the database or file storage. Check managed service limits: extensions, versions, connection counts and parameters. Rehearse each cutover, time it, and keep the source intact as a rollback. Book a right-sizing and cost review a month after go-live. If the inventory shows tangled dependencies, a database you cannot take offline, or code nobody wants to touch, that is the point to bring in people who have done these moves before. A day spent on the plan is far cheaper than a weekend spent on a failed cutover.
Infigini IT Services · 11 Kanwali Road, Dehradun 248001, India · info@infigini.com · +91 95684 87789