A client once told me their order management system was "held together by one guy named Rakesh and a Windows Server 2012 box in the corner of the warehouse." He wasn't joking. That server had been running since before half his staff had joined. It worked. Nobody wanted to touch it.
If that sounds familiar, this post is for you. I've helped companies move systems like that to the cloud, and I've also told a few of them not to bother — at least not yet. Both conversations are worth having honestly, so let's have them.
First, the uncomfortable question: do you actually need to migrate?
Cloud migration for business gets sold as inevitable. It isn't. I've seen perfectly healthy companies burn six figures moving a stable, low-traffic internal app to AWS and end up with a higher monthly bill, a more complex system, and no measurable benefit.
So before anything else, be honest about your reasons. Here's when I'd say don't migrate right now:
- The system is stable, low-traffic, and nobody's asking it to do anything new. A payroll tool used by four people twice a month does not need Kubernetes.
- Your hardware was replaced recently. If you just spent on servers eighteen months ago, let them depreciate. Plan the move for the next refresh cycle.
- You have no internal capacity for the next 6–9 months. Migrations need someone on your side who knows the business logic. Without that person, you're outsourcing decisions you shouldn't outsource.
- The application is being retired within two years anyway. Don't rehome a building you're about to demolish.
And here's when the move genuinely pays for itself:
- You can't hire for the stack anymore. Nobody wants to maintain classic ASP or Delphi in 2025, and the people who can charge accordingly.
- Your business is seasonal or spiky, and you're paying for peak capacity all year.
- Downtime costs real money and your disaster recovery plan is a external hard drive.
- You need to integrate with modern tools — payment gateways, AI services, mobile apps — and the legacy system has no sane way to expose data.
- Compliance or security audits are becoming painful. Patching a decade-old OS is a losing game.
- Your team is physically distributed and VPN-ing into an office server is slowing everyone down.
Notice that most of those are business reasons, not technical ones. That's the point. Legacy system modernization done for its own sake is expensive theatre.
The five ways to move (and why most people pick wrong)
There's a standard set of migration strategies. I'll skip the jargon-heavy version and give you the practical read.
1. Rehost ("lift and shift")
Take the app as-is, put it on a cloud VM. Fastest, cheapest upfront, lowest risk. You get better hardware, snapshots, and easier disaster recovery — but you keep every architectural problem you had before. And your bill can actually go up, because a VM running 24/7 in the cloud is often pricier than a paid-off box in your office.
Rehosting is a legitimate first step, though. I frequently recommend it when the goal is "get out of this data centre before the lease ends" and modernization can follow later.
2. Replatform
Same application, but you swap out infrastructure pieces for managed services. Your self-hosted MySQL becomes RDS. Your file uploads move to S3. Your cron jobs become scheduled tasks. Moderate effort, real operational gains. This is the sweet spot for a lot of mid-sized businesses and where I'd point most readers.
3. Refactor
Rewrite parts of the codebase to work properly in a cloud environment — break out services, add proper APIs, introduce queues. Expensive, slow, and genuinely transformative when the app is central to your business. Only do this if the system is a competitive asset, not a cost centre.
4. Replace
Buy something off the shelf. Boring advice, and often the right one. If your custom-built CRM from 2011 is really just a contact list with follow-up reminders, a modern SaaS product will beat a rewrite on cost and time. We build Orbis Lead CRM precisely for teams in that situation — the ones who need proper lead tracking and pipeline visibility without commissioning a bespoke system.
5. Retire
Every migration audit I've run has found at least one system that nobody uses anymore. Find those first. Turning them off is the cheapest win available.
Most projects end up being a mix. One module gets replaced, two get replatformed, one gets left alone for another year.
How to sequence a migration without breaking the business
The technical work is rarely what kills these projects. Sequencing is.
Start with a real inventory
Not a list of servers — a list of capabilities. What does this system actually do for the business? Who depends on each part? What are the integration points, the scheduled jobs, the reports somebody in accounts runs on the last Friday of every month? Legacy systems accumulate undocumented behaviour, and the surprises are always in the edges.
Budget two to four weeks for a proper discovery on a decent-sized system. It feels slow. It saves you months.
Deal with the data early
Data migration is consistently the hardest part and consistently underestimated. Legacy databases have duplicate records, fields being used for things they weren't designed for, dates stored as text, and encoding issues from a system upgrade in 2016. You need a cleaning strategy and a validation strategy — a way to prove after cutover that the numbers still match.
Run in parallel before you switch
Where you can, run old and new side by side for a period. Write to both, compare outputs, let users test with real data. It costs extra for a few weeks and it's the single best insurance policy you can buy. A big-bang cutover on a Friday night with no rollback plan is how weekends get ruined.
Use the strangler pattern for big systems
Rather than rewriting a monolith wholesale, put a routing layer in front of it and move one function at a time to the new system. Reporting first, maybe. Then order entry. The old system shrinks gradually until it's small enough to switch off. Slower on paper, dramatically lower risk, and you get value delivered along the way instead of eighteen months from now.
What it costs — realistically
I won't quote you a number, because anyone who does without seeing your system is guessing. But here's how the budget usually breaks down, roughly:
- Discovery and planning: 10–15% of the project. Skipping this is false economy.
- Engineering work: the bulk of it, obviously.
- Data migration and validation: often 20–30% on older systems, and frequently underbudgeted.
- Testing, parallel running, cutover: 15% or so.
- Training and post-launch support: plan for at least a month of elevated support after go-live.
On running costs: assume your cloud bill will be higher than your first estimate. Everyone's is. The savings come from reduced operational overhead, fewer emergencies, and not buying hardware — not usually from the monthly invoice being smaller. Set up cost alerts on day one, right-size your instances after a month of real usage data, and turn off dev environments overnight.
The part people forget: your team
A cloud migration changes how your people work. Deployments happen differently. Access controls tighten. That one person who used to remote into the server and fix things manually can't do that anymore — and honestly, that's the whole point, but it needs to be handled with respect rather than sprung on them.
Bring your internal technical people into the project as participants, not spectators. They know things that aren't written down anywhere. And after go-live, someone on your side needs to own the environment. Handover documentation that nobody reads isn't handover.
A sensible first step
If you're on a legacy system and unsure where to start, don't start with a vendor pitch. Start with an audit: what you're running, what it costs you today (including the hours your team spends babysitting it), what's genuinely at risk, and which single component would deliver the most value if it moved first.
That's usually a two-to-four week exercise, and it gives you something to make a decision with instead of a hunch. Sometimes the answer is a full modernization programme. Sometimes it's "replatform the database, leave the rest, revisit in a year." Both are fine outcomes.
We do this kind of assessment regularly, and you can see the sort of systems we've worked on in our work. If modernization opens the door to smarter automation — document processing, forecasting, that sort of thing — that's often where our AI & ML development work picks up afterwards. But that's a phase two conversation, not a reason to migrate.
If you're weighing up cloud migration for your business and want a straight answer about whether it's worth it right now, get in touch. Tell us what you're running and what's hurting. We'll tell you honestly if you need us — and if you don't, we'll tell you that too.