How to rehost applications

Rehosting moves an application to new infrastructure with little or no change to the application code. It is often called lift and shift because the workload is lifted from its current environment and shifted to another one. A rehost might move virtual machines from a data center to cloud infrastructure, move workloads from one hosting provider to another, or rebuild old servers on newer operating system images while keeping the application largely intact.

Rehosting is attractive because it can be faster than rewriting or deeply modernizing an application. It can help teams leave aging hardware, exit a data center contract, improve backup and monitoring, or create a foundation for later migration. The tradeoff is simple: the application mostly remains the same. Its strengths move with it, but so do its weaknesses.

What rehosting changes

Rehosting changes the runtime location and surrounding infrastructure. Compute, storage, network routing, load balancing, DNS, firewall rules, backups, monitoring, and administrative access may all be rebuilt. The application code, database schema, business rules, and user-facing behavior usually stay as close as possible to the original state.

That distinction matters. A rehost is not a refactor. It does not untangle a fragile codebase. It is not necessarily a replatform either, although some small platform changes may be unavoidable. If the application depended on local disks, fixed IP addresses, old certificates, or a particular network layout, the target environment must either reproduce those assumptions or provide controlled replacements.

Discovery before the move

The quality of a rehost depends on discovery. Teams should inventory servers, operating systems, packages, runtimes, databases, file paths, scheduled jobs, queues, caches, certificates, DNS records, service accounts, secrets, firewall rules, outbound dependencies, monitoring hooks, and backup jobs. Static documentation is useful, but live evidence is better. Network flow logs, process lists, file access, cron entries, database connection records, and authentication logs often reveal dependencies nobody remembers.

Discovery should also include business context. Which flows are critical? Which users are affected by downtime? Which external partners rely on fixed source addresses or certificates? Which batch jobs run outside business hours? Which data has residency, retention, or audit requirements? A technically successful server migration can still fail if an overlooked job breaks settlement, reporting, or customer notifications.

Build the landing zone

The target environment should be ready before the application is moved. That includes network segmentation, inbound and outbound access rules, load balancers, DNS zones, certificates, patching baselines, image management, logging, monitoring, backups, time synchronization, and administrative access. If the target is public cloud, teams should also define account structure, tagging, cost controls, identity roles, and service limits.

Avoid copying the old environment blindly. Old firewall rules may be too broad. Old admin access may rely on shared accounts. Old backups may never have been restored. Rehosting is a chance to rebuild the infrastructure shell in a safer way while keeping application change limited. The application may remain old, but the environment around it should be observable, maintainable, and governed.

Test like the old environment will surprise you

Rehost testing should prove parity under realistic conditions. It is not enough for the application to start. Teams should test login, core user journeys, administrator functions, file uploads, email, payment calls, API integrations, batch jobs, reporting, cache behavior, database latency, error pages, log output, and backup restore. If the application handles public traffic, test traffic bursts, slow dependencies, and bot or abuse pressure where relevant.

Time and location differences often create subtle bugs. A database that was once one millisecond away may now be twenty milliseconds away. A scheduled job may run in a different time zone. An outbound API may reject traffic from a new source address. A legacy license server may only allow known hosts. A local file share may not exist in the new network. These are rehosting failures, not surprises to defer until cutover.

Cutover and rollback

Cutover planning should include a clear sequence, decision points, and a rollback path. DNS TTLs, load balancer changes, database replication, freeze windows, user communication, monitoring dashboards, and support coverage all need owners. If rollback requires restoring data, the team must know exactly what data can change during the migration window and how it will be reconciled.

Some teams use parallel runs, blue-green cutovers, or staged traffic shifts. Others require a single maintenance window. The right approach depends on data consistency, traffic volume, and risk tolerance. In every case, the migration should define what success looks like: acceptable error rates, latency thresholds, completed background jobs, clean logs, and confirmed external integrations.

Security work that still belongs

Minimal application change does not mean minimal security work. Rehosting should include patched base images where possible, hardened administrative access, central logging, secret rotation, network segmentation, backup encryption, vulnerability scanning, and review of exposed services. Broad service accounts and copied firewall rules should be questioned.

Application-level debt may remain after the move. Unsupported frameworks, weak authorization, missing audit logs, or vulnerable dependencies do not disappear because the server runs somewhere new. The migration plan should document residual risks and assign follow-up work. That makes rehosting a controlled modernization step rather than a way to relocate known problems.

Rehosting checklist

Before treating a rehost as production-ready, teams should be able to answer these questions:

Has live dependency discovery been compared with documented architecture?
Are DNS, certificates, firewall rules, secrets, and service accounts ready in the target environment?
Have critical user journeys and background jobs been tested end to end?
Are logs and metrics visible to the teams that will handle incidents?
Has backup restore been tested, not merely configured?
Is rollback practical if cutover exposes a compatibility problem?
Are residual security risks documented with owners and dates?

Rehosting works best when it is treated as an infrastructure migration with application consequences. It is not glamorous, but it can be valuable when speed, continuity, and risk control matter more than immediate redesign.

How to rehost applications