Rehosting is a valid migration strategy
Yes. Many legacy applications can move to AWS or Azure without an immediate rebuild.
The usual approach is called rehosting, sometimes described as lift and shift: replicate or recreate the application's existing servers, operating system, runtime and configuration in cloud virtual machines, then cut over with controlled downtime. It can be a sensible way to leave a data centre, reduce infrastructure risk, improve resilience, or buy time for a more deliberate modernisation programme.
But “can it run in the cloud?” is not the same question as “will it be safe, supportable and cost-effective there?” A legacy application may technically boot on an AWS EC2 instance or Azure Virtual Machine while retaining every weakness it had on premises: unsupported software, fragile integrations, manual releases, unclear ownership and a database that cannot meet its recovery objective.
The right answer is usually to migrate first where it creates a clear business benefit, then improve the application in planned stages.
Applications tend to fall into several migration paths:
- Retire: switch off applications that no longer serve a useful purpose.
- Retain: keep an application where it is temporarily because of risk, contractual constraints or a pending replacement.
- Rehost: move the existing workload to cloud infrastructure with minimal application change.
- Replatform: make limited changes, such as moving a database to a managed service, without redesigning the whole application.
- Refactor: change the application architecture to use cloud-native services.
- Replace: move to a SaaS product or a packaged alternative.
Rehosting is especially useful where there is a time-bound trigger: a data-centre exit, expiring hardware support, a resilience requirement, a merger, or an urgent need to reduce dependence on a small number of aging servers.
AWS Application Migration Service supports lift-and-shift migration of physical, virtual and cloud-based servers to AWS, while Azure Migrate provides discovery, assessment and migration tooling for servers, databases and web applications. Both platforms make the infrastructure move more achievable; neither removes the need to understand the workload first.
What can usually move without a rebuild?
Applications are often good rehosting candidates when they have a relatively conventional architecture:
- A Windows or Linux application running on a supported server operating system
- A stable Java, .NET, PHP, Python or similar runtime
- A small number of well-understood virtual machines
- A database that can remain on the existing engine initially
- Predictable network, storage and batch-processing needs
- Known users, support owners and downtime tolerances
- Vendor support for the application in a virtualised or cloud-hosted environment
A typical example is an internal line-of-business application comprising a web server, application server and SQL Server database. If its dependencies are known, its licensing allows cloud deployment, and its performance profile is understood, it may be practical to move the application to cloud virtual machines first. The team can then improve backups, monitoring, recovery testing, patching and deployment automation before deciding whether to migrate the database to a managed service.
This is often safer than combining a hosting move, database replacement, application rewrite and operating-model change into one high-risk release.
For organisations planning their first cloud move, workload prioritisation should consider more than the age of an application. A good initial candidate is meaningful enough to prove the new operating model, but contained enough that the organisation can test, learn and roll back if needed.
The applications that need greater caution
Some workloads can move, but deserve a deeper assessment before any commitment.
Unsupported operating systems and runtimes
An application running on Windows Server 2008, an old Linux distribution, obsolete Java middleware or an unsupported database may replicate successfully. That does not mean it becomes secure or vendor-supported after the move.
Azure's migration guidance warns that end-of-support operating systems may not have consistent or reliable migration outcomes and recommends upgrading to supported versions before migration where possible. AWS and Azure can provide infrastructure controls around a legacy server, but they cannot turn unsupported application software into a supported product.
Where an immediate move is necessary, compensating controls may be appropriate: network isolation, strict administrative access, continuous vulnerability management, enhanced monitoring and a committed remediation date. These controls should be documented as temporary risk treatment, not accepted as the final design.
Hardware-bound or location-bound software
Legacy systems may depend on USB devices, serial interfaces, dongles, specialist printers, industrial equipment, broadcast hardware or on-premises network appliances. These are not ordinary server migration problems.
The application may need a hybrid architecture, with a local component retained near the equipment and secure connectivity to cloud-hosted services. In other cases, rehosting may be impractical until the vendor provides a supported architecture or the business replaces the application.
Tight latency and data-transfer constraints
Moving an application away from its users, data sources or dependent services changes network behaviour. A system that performs thousands of small database calls across a local network may become slow when one tier remains on premises. Large file transfers, real-time integrations and synchronous calls to partner systems can produce similar issues.
The assessment should measure actual traffic flows, latency sensitivity and data volumes. “The application is only used by a few people” does not tell you whether it will perform acceptably across a wide-area network.
Licensing and vendor support
Licensing is often discovered too late. Commercial applications may have processor, core, virtualisation, geographic, support or hosting restrictions. A vendor may support the software on AWS but not on Azure, or support it only on particular operating system versions.
Confirm these points before designing the target architecture. A migration plan that depends on a cloud instance type or licensing model which the vendor will not support is not a plan.
Rehosting does not mean copying the data centre
A common failure mode is to recreate every server, subnet and manual process exactly as it exists today. That can move operational risk from a data centre into a cloud bill.
The application may not need a rebuild, but the surrounding foundation should be designed properly. At a minimum, a production migration needs:
- Separate environments and accounts or subscriptions with clear ownership
- Identity, role-based access and privileged-access controls
- Network segmentation, DNS, firewall rules and private connectivity where needed
- Central logging, metrics, alerting and audit trails
- Tested backup, restoration and disaster-recovery procedures
- Encryption and key-management decisions appropriate to the data
- Patch management and vulnerability remediation
- Cost allocation, budget alerts and rightsizing reviews
- Documented deployment, rollback and incident-response procedures
This is where cloud consultancy becomes valuable. The aim is to create reusable controls and patterns for the next migration wave, rather than a collection of one-off cloud servers that only a migration partner understands.
A well-run rehost should improve the application's operational position even if its code does not change.
AWS or Azure: choosing the target
Neither provider is automatically a better home for every legacy estate. The decision should start with the workload and operating context.
AWS can be a strong fit where an organisation already has AWS governance, networking, security tooling, skills or adjacent workloads. Application Migration Service is designed to replicate source servers and launch them in AWS, helping teams execute staged test and cutover processes.
Azure is often attractive where identity, endpoint management, Windows Server, SQL Server, Microsoft 365, Active Directory or existing Microsoft commercial agreements are central to the environment. Azure Migrate can discover and assess workloads, then support server migration through agentless or agent-based methods, depending on the source environment and requirements.
The more important question is whether the organisation can operate the chosen platform consistently. That includes security ownership, access management, networking, monitoring, support arrangements, FinOps and deployment practices. A platform selected only because a particular virtual-machine image exists can create avoidable complexity later.
For a broader comparison of the two ecosystems, see AWS vs Azure: which cloud platform is better for your business?.
Assess the application, not only the server
Server inventory tools are useful, but a server list is not an application map. A single business service may include web servers, databases, scheduled tasks, file shares, service accounts, message queues, reporting tools, certificates, partner VPNs and undocumented manual operations.
Before choosing rehost, answer these questions:
- What business process does the application support, and who accepts the migration?
- What happens if it is unavailable or data is lost?
- Which services, databases, files, identities and external parties does it depend on?
- Which parts are stateful, and where does the authoritative data live?
- What are the actual CPU, memory, storage, IOPS and network requirements?
- Which software versions are unsupported or nearing end of life?
- Can the application be tested in an isolated cloud environment?
- How will users authenticate, connect and obtain support after cutover?
- What is the rollback point, and how long is it viable?
- What changes are required before the workload is secure enough to operate in the target environment?
Dependency mapping is particularly important. An application can appear self-contained until cutover reveals that it calls an on-premises file share, relies on a scheduled job on another server, sends email through a local relay, uses a hard-coded IP address, or expects an identity service that has not been made reachable.
A practical migration path
A sensible legacy migration programme follows a progression: discover application and dependencies, classify the workload, build a secure cloud foundation, test migration and validate performance, cut over with a rollback plan, then stabilise, rightsize and improve.
Establish the cloud foundation
Set up the target landing zone before moving a production application. Identity, network design, logging, backup, policies and billing ownership should be in place first. Otherwise, delivery teams will create exceptions under deadline pressure and spend months repairing them later.
Group workloads into migration waves
Move applications with shared dependencies together where necessary, but avoid creating waves so large that testing and rollback become unrealistic. The first wave should validate a pattern: for example, a Windows application with SQL Server, an IIS application, or a Linux-based integration service.
Test before the production cutover
A test migration should confirm more than whether the server starts. Validate functional workflows, user access, batch jobs, data consistency, printing, integrations, performance, monitoring, backup restores and operational handover.
For Azure workloads, Microsoft explicitly recommends test migration for scenarios where operational state or replication behaviour needs validation. The same discipline applies on AWS: launch a controlled test environment, prove the workload and document every issue before the production window.
Cut over with a real rollback plan
Rollback needs an explicit decision point. Define what will trigger it, who has authority to make the call, how users will be informed, and how data written in the target environment will be handled. “We can switch it back” is not sufficient if data has already diverged.
Stabilise before modernising
After migration, rightsize resources using observed utilisation rather than inherited server specifications. Resolve security findings, improve alerting, test recovery, document runbooks and transfer ownership to the support team.
Only then decide whether a database should move to a managed service, a monolith should be decomposed, or a particular component should be replaced. Modernisation choices become clearer once the organisation has reliable operating data.
Cost: rehosting is fast, not automatically cheap
A lift-and-shift migration can be more expensive than expected when teams provision cloud servers to match on-premises hardware rather than actual utilisation. Always-on non-production systems, oversized databases, excessive storage snapshots, data-egress charges and unused recovery environments are common sources of waste.
At the same time, forcing a rebuild before leaving a costly data centre can be the more expensive decision. Cost should include the full picture: infrastructure, licensing, migration delivery, ongoing operations, business interruption risk, deferred hardware replacement and the opportunity cost of delaying other work.
Build a baseline before migration, tag resources by application and owner, set budgets, and review costs after each wave. Cloud cost management works best when engineering and finance share accountability for the decisions that create spend.
When a rebuild is the better answer
Rebuilding is justified when the application cannot meet its business, security or reliability requirements in its current form. That may include:
- An unsupported platform that cannot be safely retained
- A system whose architecture prevents required availability or recovery targets
- A database engine or application stack with no viable cloud-hosting support
- A product where change speed is commercially important and current releases are too slow or risky
- A workload that can be replaced cleanly with a SaaS service
- A high-cost server estate where managed services would materially improve operations and economics
Even then, a phased approach is often preferable. Rehost the stable parts, introduce managed services around the edges, extract one constrained capability at a time, and retire legacy components once the replacement proves itself.
The practical answer
Legacy applications do not need to be rebuilt before they move to AWS or Azure. Rehosting can be a disciplined, low-disruption way to reduce data-centre dependency and create room for better decisions.
The condition is that the organisation does not confuse migration with completion. Move the workload using a secure foundation, understand dependencies, test the operational model, control costs and set a clear post-migration improvement plan. Then modernise the parts where modernisation earns its investment, rather than rebuilding everything because the cloud makes it technically possible.
