Rehost vs. replatform for cloud migration

There are several different strategies for migrating data and services to the cloud, each with its own advantages and disadvantages. Rehosting and replatforming are two of the most popular migration strategies.

Rehosting, sometimes referred to as a “lift and shift” migration, is the process of migrating an exact copy of an application or workload, together with its data store and operating system (OS), from on-premises infrastructure to a cloud environment. Because it involves no change to application architecture, and little or no change to application code, the lift and shift approach enables a faster, less labor-intensive migration, with lower upfront costs than other strategies. 

Replatforming is a modification of the rehosting strategy that makes targeted optimizations that leverage the move to a new platform—for example, taking advantage of cloud-native features such as containerization or managed SQL databases—without major changes to application code or core architecture. It constitutes a middle ground between rehosting and fully rearchitecting an environment.

An understanding of the general benefits of cloud computing is helpful to understanding the strengths and drawbacks of various cloud migration strategies.  These benefits include:

Cloud environments are generally easier and more cost-effective to scale than on-premises infrastructure, particularly for organizations with variable or unpredictable workloads. For example, imagine an ecommerce site that needs to prepare for holiday shopping season and the significant increase in traffic it can bring.

To reduce latency and the risk of downtime, more servers might be needed as traffic volumes swell. Upgrading server capacity in an on-premises stack can be expensive, time-consuming and require significant labor to set up. Cloud-based infrastructure, in contrast, can be automatically scaled based on real-time demand.

This flexible scalability helps organizations cut down on resourcing costs. Resources can be scaled to match demand, or provisioned for specific times of the year, a more cost-effective solution than maintaining excess capacity just to accommodate a few busy periods. In our ecommerce example, resources can be automatically scaled back down once the traffic spike subsides.

Cloud environments can accelerate innovation and business value by making it easier to integrate and scale emerging technologies that are offered as cloud-native managed services. Machine learning tools are a prominent current example.

Organizations can access many AI tools through APIs or as SaaS products regardless of whether their infrastructure is cloud-based or on-premises. The meaningful advantage of cloud migration lies in the depth of integration and scalability that these environments enable.

Cloud-native AI services are designed to integrate directly with cloud infrastructure, making deployment, scaling and maintenance far more straightforward than attempting equivalent integration with on-premises systems.

Cloud environments also reduce the time and cost of provisioning new resources for testing and deploying emerging technologies. Rather than procuring and configuring hardware for each new initiative, development teams can spin up new environments on demand. This accelerates the pace of experimentation and innovation in ways that on-premises infrastructure struggles to match.

Rehosting, often known as lift and shift, is a wholesale migration of data, applications and workloads from on-premises data centers to cloud environments. Essentially, an organization moves all these assets “as is” to a cloud environment. It’s a rapid, low-complexity strategy that enables an organization to quickly exit on-prem data centers. In 2025, according to a Mordor report, just over 38% of all cloud migration projects opted for a rehosting strategy.

Rehosting offers a tradeoff between speed and ease of migration and the opportunity to take full advantage of cloud computing benefits. An organization might choose a rehosting strategy when under a tight migration timeline if, for example, a current data center contract is due to expire soon or if there is an immediate need to reduce data center costs.

Rehosting can also be useful when an organization needs to migrate a monolithic app (an app with many different business functions that rely on a common codebase) without disruption. Because multiple services are dependent on a single codebase, it can be less complicated to migrate the entire UI, database and server-side application as a single unit.

This contrasts with microservices, which are more suitable for replatforming because a microservices architecture makes it easier to optimize individual services.

This monolithic app case ties into a broader driver of rehosting: risk aversion. Organizations with mission-critical applications that can’t afford extended downtime or the risk of introducing new bugs through code changes often choose rehosting precisely because it minimizes disruption.

Rehosting can (and often does) serve as a first step for more advanced optimization; rehosting moves the assets over to cloud and modernization and further optimizations can then happen at the organization’s leisure.

While rehosting is the simplest cloud migration strategy, it nonetheless brings notable advantages.

Without any changes to code or architecture, a simple lift and shift migration from one environment to another can be accomplished relatively quickly and with minimal complexity.

Rehosting efforts can be assisted and improved with machine learning and other AI tools. For example, discovery tools driven by machine learning can find and map out dependencies, servers and everything else to be moved, analyze precise capacity needs and flag changes that must be made, such as updating IP addresses.

Because rehosting does not entail significant changes to application code, underlying platforms, services, databases and workflows that were compliant with security and audit requirements before the migration often remain in compliance after the migration.

Other migration strategies (such as replatforming, refactoring or rearchitecting) require greater development and infrastructure work to optimize applications, platforms and workloads for cloud environments. In some cases, organizations might need to hire additional developers or migration specialists to assist in this effort. As a more straightforward transfer, rehosting can often be handled by internal IT teams, saving on some upfront costs.

There is a tradeoff for simplicity and the most crucial disadvantages of rehosting stem from the nature of the migration: Many cloud efficiency gains are design-dependent and rehosting doesn’t change the design but the location. This renders many of the most significant cloud efficiency gains inaccessible.

While rehosting can reduce upfront migration costs, the long-term cost picture is less favorable. On-premises infrastructure is typically sized for peak demand and rehosting carries that static capacity assumption into a cloud billing model. This means that the organization pays on-demand cloud rates without taking advantage of rightsizing opportunities like autoscaling, spot instances or reserved pricing.

Rehosting also foregoes broader cloud-native efficiencies such as serverless computing and managed services, which can significantly reduce operational costs for optimized workloads.

The lack of redesign also drives technical debt, which contributes to costs and other drawbacks like security and performance issues. Rehosting defers rather than resolves underlying architectural inefficiencies—legacy code, brittle configurations and system incompatibilities move with the application unchanged. Other migration strategies like replatforming and rearchitecting present opportunities to address these issues directly; rehosting does not.

Over time this becomes increasingly costly. As cloud providers evolve their services and capabilities, the gap between a rehosted application’s architecture and available cloud-native tools widens, requiring growing workarounds to maintain compatibility. Eventually many organizations end up rearchitecting anyway, effectively paying for two migrations.

Replatforming presents a middle ground between the lift-and-shift philosophy of rehosting and a more transformational migration such as refactoring or rearchitecting, which involve substantial code or architectural changes. In this strategy, application code remains largely the same and changes are primarily made to the infrastructure and configuration layers.

Replatforming often involves database changes, containerization, middleware and runtime updates, and configuration and connectivity changes. These are targeted, compatibility-driven updates that leave the application code and underlying logic much as it was prior to migration.

Replatforming provides a strategic balance between speed and optimization. It is faster and less complex than fully rearchitecting an environment but still can enable an organization to take better advantage of cloud benefits such as improved scalability at the infrastructure level and more efficient resource utilization.

Smaller organizations might not have the resources or the need for a full rebuild, in which case replatforming can address some of the disadvantages of rehosting without introducing too many new ones.

A classic example is the swapping of a self-managed database for a cloud provider’s managed database service (from a self-hosting MySQL instance to Amazon RDS or Azure SQL, for example). The change here is in how the database is provisioned and managed. There are no changes in how the application interacts with the data, and the business logic, data model and app architecture remain unaltered, while providing better performance.

Replatforming brings a unique compromise to the cloud migration strategy spectrum. When executed well, it can blend the simplicity of a rehosting migration with key optimizations of more onerous strategies like rearchitecting.

Replatforming gives organizations the ability to swap self-managed components (such as databases and message queues) for provider-managed equivalents, which can provide cost and operational benefits.

Replatforming involves targeted changes and optimizations to help ensure compatibility with the new platform, which requires an upfront investment. However, the total cost of ownership over the long run often ends up lower than a comparable lifecycle using a rehosted strategy.

Replatforming enables organizations to take advantage of cost efficiency features like autoscaling, in which resource capacity is automatically adjusted to meet real-time demand.

Managed services typically come with service level agreements (SLAs) that provide performance and uptime guarantees that exceed what the organization achieved internally.

Replatforming delivers meaningful cloud benefits in a shorter time frame than rearchitecting, making it particularly valuable when there is competitive or organizational pressure to modernize quickly.

Replatforming also carries less risk than rearchitecting. Because core application code remains unchanged, there is less of a risk of introducing new bugs or breaking existing functionality.

Replatforming enables organizations to extend the useful life of legacy applications by modernizing their infrastructure layer without requiring a complete rewrite. This is particularly relevant for organizations running stable, business-critical applications that would be too risky or expensive to rearchitect but are becoming costly to maintain on-premises.

Migrating from commercial software to cloud-managed open-source equivalents can eliminate expensive licensing fees.

While replatforming provides benefits in and of itself, it can also serve as a step towards a more comprehensive migration strategy, such as refactoring or rearchitecting.

While replatforming can provide a satisfactory middle ground between rehosting and rearchitecting, it has its own disadvantages.

Replatforming’s ease and speed are also limiting factors. Because core application architecture remains unchanged, replatforming cannot deliver the deeper cloud benefits that rearchitecting makes possible, such as independent service scaling, serverless economics and the resilience of a fully cloud-native design. For organizations with long-term cloud optimization goals, replatforming often addresses immediate needs while leaving significant potential unrealized.

The process of adapting a company’s applications to be compatible with a new cloud provider platform isn’t always smooth. For example, existing code might include proprietary or platform-specific dependencies that the new platform doesn’t understand. Or it might require the use of deprecated libraries. IP addresses might also have been hard-coded, which can cause issues with a cloud-based platform that assigns dynamic IP addresses.

An audit of the existing platform can help organizations identify and address such compatibility issues early in (or before) the migration.

There is no firm definition of “replatforming,” in terms of precisely what is optimized during the migration. This means that a replatforming strategy can tend to slowly accumulate new tasks and sub-tasks. A careful pre-migration evaluation can help mitigate this risk.

Making targeted infrastructure changes can have cascading effects across dependent systems and service. For example, a database migration affecting connection pooling, which affects application response times, which affects dependent services. Because replatforming makes more changes than rehosting (albeit far less than rearchitecting) it requires more extensive testing, which comes at a higher cost.