Rehost and replatform: two opposing strategies on the migration-transformation continuum Rehost and replatform sit at the two ends of a migration spectrum within the 6R framework. Rehost, also called lift-and-shift, consists of moving an application as-is from on-premises infrastructure to AWS without functional or architectural modification. You install the operating system, the dependencies, and the application on an AWS EC2 instance (or container), staying as close as possible to the source configuration. Replatform, often called lift-and-optimize or light overhaul, goes one step further: you migrate the application, but you prepare it for the cloud by removing certain dependencies, adapting it to AWS managed services (for example, replacing a self-hosted database with Amazon RDS, or a home-grown queue with SQS), and lightly optimizing the architecture to reduce operating costs over time. Rehost favors speed and immediate risk reduction; replatform adds an optimization phase that reduces technical debt and the AWS bill in the long run, but it takes more time and involves software changes. Neither one entails a major rewrite (that is the role of refactor) nor a change of product (repurchase); they stay within the philosophy of "keep what we have and adapt it to the cloud."
Rehost: migrate in two weeks, accept the cloud bill to come The rehost model is the fastest and least risky in the short term. An on-premises monolithic application can be migrated to an EC2 instance in a few days to a few weeks, depending on its size and its external dependencies. No code change is needed; you simply reproduce the runtime environment in the cloud. The short timelines mean that ROI appears immediately: you stop paying for the physical server, you quickly amortize the AWS spend, and the technical team can move on to the next projects. The risk of functional regression is minimal, since nothing changes on the application side. This advantage is valuable for emergency migrations (the end of a maintenance contract on aging infrastructure, the forced decommissioning of a data center) where time takes priority over architectural perfection. However, rehost optimizes nothing for AWS. An application migrated by lift-and-shift will often continue to consume generous resources (processors, memory, storage) comparable to what it used on-premises, where the marginal cost of an extra resource was diluted in a fixed capex budget. On AWS, this excess translates into an inflated monthly bill, with little leverage to reduce it without a software overhaul. As an example, a self-hosted database on a physical server, even overprovisioned, only costs the electricity and the maintenance of the server; moved as-is onto a compute-optimized EC2 instance (instead of an RDS service) on AWS, it keeps consuming identically, without benefiting from the cost reductions or the high availability that RDS would have brought for a reasonably low adaptation effort. Rehost should therefore be chosen when timing is critical, when the application in question is not a heavy resource consumer, or when the technical team is too overloaded to consider an overhaul, even a light one.
Replatform: three to four weeks to cut costs by 30 to 50 percent over time Replatform goes beyond lift-and-shift by adding a light overhaul phase adapted to the AWS cloud. Instead of simply moving the application, you take the opportunity to identify and replace the components that AWS can manage more efficiently. Self-hosted databases become RDS or DynamoDB depending on the schema; home-grown queueing systems become SQS or Kinesis; frozen application servers move to ECR-ECS containers for better scalability. These adaptations are generally low-risk because they do not touch the application's business logic, only its technical infrastructure. This approach costs more engineering time upfront (an extra week or two of testing), but it produces three benefits within the week following deployment: an immediate reduction in the AWS bill (a database engine optimized by RDS can cost 40 to 50 percent less than an EC2 instance running the same engine around the clock), a reduced operational burden of technical administration (AWS handles patches, backups, failover), and a healthy foundation for future optimizations (auto scaling, reserved instances to reduce variable costs, and so on). Replatform is therefore the model of choice for "normal" migrations where time is not entirely lacking, but where you want to avoid a major rewrite that would have a less clear ROI and higher regression risk. It is particularly well suited to 10 to 20 year old monolithic applications that have accumulated technical debt on-premises but whose business core remains solid and useful. A bank migrating a loan management application written in Java 15 years ago on an on-premises server will typically go through replatform: it will adapt the self-hosted Oracle database into an RDS Oracle instance, but will not add microservices or REST APIs since that was not the core of the project.
Criteria for choosing rehost or replatform based on the application profile The choice between rehost and replatform depends on four main criteria: the urgency of the migration, the resource consumption profile, the level of architectural technical debt, and the available engineering capacity. First, if the migration must be completed in less than four weeks (the urgent end of a data center contract, the end of support for an old database), rehost is the obvious choice. Second, if the application is light on resources (a static website, a small internal admin portal, a nightly batch that consumes little), the AWS overhead of lift-and-shift will remain marginal, and rehost can be acceptable. Third, if the application includes technically heavy components that are inefficient to maintain (a home-grown cache system written in C in the 1990s, a self-replicated database without automatic failover, an n-tier architecture with too many network hops), replatform will pay off: adapting these components to AWS managed services will quickly pay for the extra week of engineering. Fourth, if your tech team is saturated and can only free up three developers for three weeks, rehost will be more realistic than a replatform that would demand more bandwidth. Conversely, if you have some calendar breathing room, an application that consumes heavily on compute or storage, and a team able to spend two or three weeks on optimization, replatform will deliver a better total cost of ownership after six months. A simple matrix helps arbitrate: if the urgency score is 9 or 10 out of 10 and the app's monthly cost is under 5,000 euros, rehost; if urgency is 5 or less and the monthly cost exceeds 10,000 euros with components identifiable as inefficient, replatform.
Common pitfalls and how to avoid them when choosing rehost vs replatform The most frequent pitfall is choosing rehost for lack of initial time, then suffering an AWS bill much heavier than expected for a year, which forces a retroactive overhaul that is harder than an upfront optimization. An application that could have gone through replatform in two additional weeks then has to be revisited while it is in production and while the connections with other systems have hardened. The cost of this late overhaul is often higher than the opportunity cost of optimizing right away. To avoid this pitfall, assess upfront the estimated monthly AWS cost in a rehost scenario (ask AWS for a quote or simulate it on the pricing calculator) and compare it to your cloud cost targets. If the annual projection exceeds your budgets by 50 percent, the investment in replatform will be more worthwhile. A second pitfall is neglecting external dependencies when opting for rehost. An on-premises application may rely on synchronous connections to other systems, LDAP authentication specific to the data center, or predictable network paths with very low latency. Moved by lift-and-shift to AWS, it may suffer unexpected latencies or timeouts if these dependencies have not been refactored. Replatform forces you to revisit these dependencies (adapting authentication to Cognito or OAuth, decoupling synchronous calls into message queues), which reduces the risk of a nasty post-migration surprise. A final pitfall: confusion between replatform and refactor. Replatform means adapting the application to AWS managed services without touching the business logic. Refactor means rewriting portions of the application to fully take advantage of the cloud (microservices, serverless, and so on). If your sponsors or your backlog promise a "cloud overhaul," that is not replatform, it is refactor, and it goes beyond the scope and timelines of a simple 6R migration.
Concrete use cases: when rehost wins and when replatform wins Let us take three concrete examples to illustrate the choice. Case 1: a small fintech startup has a portfolio management application written in Python, running on an on-premises server rented for 800 euros per month. Medium urgency (the contract renews in two months), a team of two engineers. Rehost estimate: two weeks for the audit and the migration, estimated AWS cost of 900 euros per month (poorly optimized). Replatform estimate: three additional weeks to adapt the Postgres database into RDS and refactor the connections, with an estimated reduction to 600 euros per month. Calculation: investing one week of two engineers (80 hours) to save 300 euros per month is worthwhile beyond 8 months. The answer is replatform. Case 2: a large insurer must immediately migrate a legacy COBOL batch that runs an annual report on the last day of the fiscal year. A one-week delay would be a regulatory disaster. The app consumes 5,000 euros per month in server costs. Rehost: deploy the batch on an EC2 machine with the same RAM and CPU in two weeks, migrate the data. The batch runs in November and December, then the team can optimize it later when there is no urgency. Answer: rehost now, replatform in Q2 if profitable. Case 3: an e-commerce SME has a store management application written in Java with a self-replicated MySQL database, a Redis cache inside, and an in-house order queue. No extreme urgency, a team of four developers, an on-premises server bill of 15,000 euros per month. The database, the cache, and the queue could move to AWS managed services. Rehost would cost 18,000 euros per month on AWS (not optimized). Replatform, about twenty days of development, would reduce it to 9,000 euros per month. The team can free up that bandwidth. Answer: replatform, because the ROI is obvious and achievable.
Rehost and replatform within the broader 6R framework Rehost and replatform are only two facets of the complete 6R framework. The six strategies (Rehost, Replatform, Refactor, Repurchase, Retire, Retain) cover the full set of possible decisions during a cloud migration. Many organizations do not choose a single model for their entire portfolio: they typically combine rehost for urgent or inherited applications of low criticality, replatform for moderately sized business components, refactor for critical new services, repurchase for generic applications (ERP, CRM, office suite) that a SaaS can cover more cheaply, retire for obsolete applications, and retain for systems too complex or tied to specialized hardware that will stay on-premises or in a private cloud. A 6R selection matrix helps quickly classify each application in your portfolio against these six criteria (cost, risk, timeline, engineering capacity needed, dependencies). If an application comes out as a rehost or replatform candidate, this article deepens that choice. If it seems more like a refactor or repurchase, it means it falls outside the rehost/replatform scope: it requires either a rewrite or a change of product. The important thing is not to let a rehost or replatform decision be imposed by false urgency; revisit the 6R matrix with the stakeholders (business, finance, technical) to make sure you are not missing a repurchase or retire opportunity that would have a better ROI.
Resources to refine your decision: dependencies, blockers, and next steps Before locking in a rehost or replatform choice, identify the technical dependencies and blockers that could influence that choice. Dependencies (connections to other systems, shared authentications, specific network paths, licenses) must be listed because they can make rehost slower and riskier if they require configuration changes. Blockers (the impossibility of modifying the app for regulatory reasons, dependence on a third party who cannot lead the migration, performance constraints that forbid even a light overhaul) can rule out replatform and force rehost. A thorough diagnosis of dependencies and blockers before choosing can spare you weeks of post-migration rework. Once rehost or replatform is selected, the immediate next steps are a costed migration plan (timelines, resources, costs), a cutover strategy (big bang or progressive migration), and a two to three day testing plan before go-live. These topics belong to the migration project itself rather than to the strategic choice; if this article has clarified for you why you were choosing rehost or replatform, the practical next steps will follow naturally from that choice.