Rehost

Expanded Definition

Rehost is the most direct cloud migration path: you move an application, along with its existing runtime assumptions, onto cloud infrastructure without redesigning the code or reworking the architecture. It is commonly called lift and shift. The practical boundary is important, because rehosting changes where the workload runs, not how the workload itself is built, secured, or operated.

That means rehost is not the same as refactor, replatform, or replace. It preserves the application’s dependencies, deployment model, and many of its operational characteristics, which is why teams often choose it for speed, migration volume, or near-term data-centre exit goals. The trade-off is that any limitations in the original design, such as brittle scaling, legacy configuration, or weak observability, usually move with the workload into the new environment.

A common misunderstanding is to treat rehost as a cloud optimisation strategy. In practice, it is primarily a migration strategy, and cloud benefits only become material later if the organisation deliberately modernises the workload after landing it.

Examples and Use Cases

• A legacy internal application is moved from on-premises virtual machines to cloud VMs with the same operating system, middleware, and application binaries.
• A line-of-business system is rehosted to meet a datacentre exit deadline, while the team defers code changes until after the migration stabilises.
• Seasonal burst capacity is achieved by relocating an existing workload to cloud infrastructure, but the application still depends on the same database schema and batch schedule.
• A regulated environment uses rehost as an interim step, keeping the system familiar for operations and audit while planning later remediation of technical debt.
• A vendor-supported application is lifted into cloud infrastructure because the software cannot easily be modified, making infrastructure relocation the fastest viable path.

Rehost is often attractive when time, risk reduction, or contractual deadlines matter more than optimisation. The trade-off is that migration effort is lower up front, but the organisation may carry forward inefficiencies in cost, performance, and maintainability.

Security Implications

Rehosting can preserve security controls that already work, but it can also preserve weaknesses that cloud teams would otherwise have a chance to redesign. If the source workload was poorly segmented, heavily manual, or dependent on static configuration, those same patterns often survive the move. The result is a workload that is “in cloud” but not necessarily better protected.

This matters because cloud migration changes the operational environment even when the application code stays the same. Network exposure, identity integrations, logging paths, backup assumptions, and administrative access patterns may all need to be revalidated. If they are not, the migration can create hidden gaps between the application’s inherited trust model and the cloud provider’s shared-responsibility model.

For practical assessment, rehost should be treated as a security transition event, not just an infrastructure swap. Teams need to verify whether the moved system still has appropriate access boundaries, monitoring, recovery behaviour, and change control after landing in the new platform.

Security, Operational and Governance Implications

Rehost often succeeds operationally because it is fast, but governance quality depends on whether the organisation uses the move as a checkpoint or just as a relocation exercise. A lift-and-shift migration can be the right choice for scope, urgency, or dependency reasons, yet it should still trigger a review of ownership, control inheritance, and post-migration accountability.

The main governance risk is inertia: once a workload is moved, teams can assume it has also been modernised. In reality, rehost usually delivers an environment change first and a control improvement only if one is intentionally added later. That makes cloud landing zones, baseline hardening, monitoring, and exception handling more important than the migration label itself.

Practitioners should also watch for rehost being used as a permanent state. Without a follow-on modernisation plan, technical debt can become cloud debt, where the organisation pays for new infrastructure while still carrying old operational habits.