IT leadershipBusiness softwareMaintenanceBudget
How to migrate a legacy business application to the cloud: options, hidden costs and a method for smaller companies
11 min read
To migrate a legacy business application to the cloud, start by choosing the right strategy: move it as it is onto hosted servers, swap a few components (database, backups, file storage) for managed services, or rebuild it as a web application. The right answer depends on the state of the application, not on fashion. A healthy application can be moved; an ageing one that gets moved is still ageing, just on a more expensive server. Whatever you pick, data migration, backups and an exit plan have to be ready before cutover.
Most guides on this topic come from the big cloud providers or from integrators that move hundreds of servers at a time. This one is for a smaller company with one application that matters, often running on a server in a back room, and a decision to make about it.
Why the question comes up now
The triggers are nearly always the same:
- the server is reaching end of life, and replacing it forces a decision about where the application will live for the next five years;
- remote work: sales, field staff or managers need the application away from the office, and the VPN is no longer enough;
- an incident: a hardware failure, ransomware, a backup that would not restore;
- the person who looked after it has left, whether an employee or a contractor;
- a component is out of support, such as an old Windows Server or database version.
If the last point is your main concern, read our guide to replacing unsupported business software as well: the question is then not only where to host it, but whether to keep it at all.
Migration strategies in plain English
Cloud providers group migrations into a handful of strategies. AWS documents seven, known as the "7 Rs". For a single business application, four of them really matter:
| Strategy | What you do | When it fits |
|---|---|---|
| Rehost ("lift and shift") | Move the application unchanged onto hosted servers | Healthy application, urgent hardware problem |
| Replatform | Move it and swap a few components for managed services | Fragile database or backups |
| Refactor or rebuild | Rebuild it as a web application designed for the cloud | End-of-life software, desktop client, mobile needed |
| Repurchase | Switch to an off-the-shelf SaaS product | Standard need, well covered by an existing product |
The other three (retire, retain, relocate) mostly apply to large estates: switching off an application nobody uses, keeping one on premises for now, or moving virtual machines in bulk.
For large migrations, AWS itself advises moving first and modernizing afterwards, describing refactoring as the most complex and costly strategy. With a single application the logic is different: if the software has to be rebuilt within two years anyway, paying for a careful rehost in the meantime may be money wasted.
The desktop client problem
Many business applications in smaller companies are Windows programs installed on every PC and connected to a database on the office server: Visual Basic 6, Delphi, Microsoft Access, FileMaker, WinDev, or an old packaged product. There are two routes.
Remote desktop
You install the application and its database on a cloud server, and users connect through remote desktop or a published-app service. It is fast, needs no code changes and works from anywhere. The limits: Windows Server and remote access licences add to the bill, local printers and scanners often misbehave, phone use is painful, and the software has not become a day younger.
Rebuilding as a web application
You rebuild the application so it runs in a browser, on desktop and mobile, with a hosted database and managed backups. It is a real project, but it is also the moment to remove years of workarounds. Our guides on converting an Access database to a web app and on WinDev to web migration cover two common cases, and the VB6 migration guide covers another.
A middle path works well: remote desktop now to solve the hardware emergency, then a gradual rebuild, module by module, following the step-by-step modernization method.
Where to host: what actually matters
Choosing a provider comes down to a few questions:
- Where data and backups live. If you handle personal data of people in the EU, GDPR governs transfers outside the European Economic Area; other regions have their own rules. Our article on hosting a business application in Europe covers the details, including sector rules such as health data.
- Who is responsible for what. The provider secures its data centres; your application, accounts and backups remain your job. AWS spells this out in its shared responsibility model, and other providers follow the same principle.
- Service levels. Guaranteed uptime, support response times, and above all backup frequency and retention.
- Simplicity. For one application, a regional provider with managed servers is often easier to run than a hyperscaler with hundreds of services.
The costs people forget
Migration quotes usually cover the move itself, rarely the rest. Compare over three to five years:
| Item | Office server | Application in the cloud |
|---|---|---|
| Hardware | Purchase, then periodic replacement | None, included in the monthly bill |
| Running costs | Power, UPS, cooling | Monthly bill, often usage-based |
| Licences | Already paid, sometimes out of support | Server or remote access licences to rent |
| Backups | External drive, often never tested | Managed service, still to configure and test |
| Administration | Internal time or a contractor | Still needed, in a different form |
| Exit | Not applicable | Data export, covered by the EU Data Act in the EU |
Two traps come up again and again: oversized resources nobody scales down after cutover, and data egress fees charged by some providers. For the budget of a rebuild, see our breakdown of software modernization cost.
Exit rights are now regulated in the EU
Leaving a cloud provider used to be expensive. The EU Data Act (Regulation 2023/2854), applicable since 12 September 2025, changes this for customers in the European Union: the notice period to start switching may not exceed two months, a 30-day transition period applies, and from 12 January 2027 providers may no longer charge switching fees (Article 29).
The law does not remove technical lock-in. An application built on one provider's proprietary services is still costly to move. Prefer standard building blocks (a mainstream relational database, containers, compatible object storage) unless a proprietary service brings a clear benefit. The same discipline applies to your development partner, as explained in our vendor lock-in exit plan.
A seven-step method
- Inventory everything. Servers, versions, database, shared folders, scheduled jobs, printers, links to other software. Anything not listed will be forgotten at cutover.
- Assess the application. Is the source code available, documented, on supported versions? A software audit stops you from moving a problem to a new address.
- Pick a strategy from the table above, one application at a time if you have several.
- Prepare the data. Cleansing, volumes, transfer time, and a legacy data migration rehearsed on a copy.
- Migrate a copy and have real users test it on their daily tasks, printing included.
- Cut over on a weekend or an evening, with a written rollback plan and the old installation kept read-only for a few weeks.
- Restore a backup within the first month. A backup that has never been restored is not a backup.
Common mistakes
- Moving without looking. Rehosting software nobody understands just carries the technical debt somewhere more expensive.
- Forgetting integrations. The 6 pm accounting export, the scanner's network share, the file a supplier drops every night: everything that touched the server has to be found.
- Ignoring latency. A desktop client designed for a local network can become painfully slow when it queries a remote database directly.
- Switching off the old server too soon. Keep it, powered down or read-only, until the first month-end close has gone through.
- Leaving default security in place. Shared admin accounts and ports open to the internet are the first things to fix; see our security essentials for business applications.
Questions to ask whoever runs the migration
Before signing, ask your provider to answer these in writing:
- Which strategy do you recommend for this application, and why not the cheaper one?
- What exactly is in scope: data, scheduled jobs, printers, integrations, user accounts?
- How many test migrations are included, and who signs them off?
- What is the rollback plan if cutover goes wrong, and how long can it take?
- Who owns the cloud account, the admin credentials and the backups after go-live? The answer should be you.
- What will the monthly bill look like after the move, and who reviews it?
A provider who cannot answer the last two questions clearly is selling a move, not a running service.
When not to migrate
Stay on premises if the application depends on local hardware with no remote equivalent (a machine on the shop floor, a controller), if it will soon be replaced by an off-the-shelf product, or if it serves three people in one office and works fine. In that last case, an off-site, tested backup gives you most of the safety at a fraction of the cost.
Where to start
Take the inventory, then ask the one question that matters: should this application live another five years as it is? If yes, move it properly. If not, the migration is your chance to rebuild it, and you can see the result before committing a budget. We build a free visual prototype of the future web application, presented on a video call within 5 business days, as explained in see your software before you pay.