What a cloud migration costs
The monthly bill is the visible number and rarely the important one.
Budget for the application work, not the servers. And expect the running cost to be similar or higher — the case for moving is resilience and speed, not savings.
Cloud migration is quoted as an infrastructure project and delivered as an application project. That mismatch is where budgets go.
Copying a server is straightforward. What takes the time is everything attached: hard-coded paths, licence keys tied to hardware, scheduled jobs nobody documented, integrations assuming a local network, and the report server pointing at something that will not exist afterwards.
Two ways to move, priced very differently
Lift and shift
- Cheaper and faster to execute
- Minimal application change
- Often higher monthly cost afterwards
- Keeps existing operational habits
- Reasonable when the deadline is real
Modernise while moving
- More project cost up front
- Managed services replace self-managed ones
- Lower and more predictable running cost
- Reduces ongoing operational load
- Better when the system will live for years
What belongs in the budget
- Assessment and dependency discovery — small, and it prevents the expensive surprises.
- Application changes: connection strings, paths, licensing, scheduled jobs.
- Data transfer, and the cost of getting large volumes across.
- Running both environments in parallel during transition.
- Rehearsal, plus a restore test of the new backups.
- Right-sizing after go-live, which is where most savings actually appear.
Keeping the monthly bill predictable
Runaway cloud bills are almost never caused by pricing. They are caused by provisioning for a peak that never arrives, environments nobody switched off, storage that only grows, and data transfer nobody modelled.
Set budget alerts on day one, right-size after a month of real usage rather than guessing beforehand, and put a name against reviewing the bill for the first quarter. That is unglamorous and it is the whole of cost control.
If a proposal promises cloud will cut your infrastructure spend, ask for both columns in full. Often it will not, and the real case for moving is a better one.
Cloud migration cost — questions we get asked
Will our monthly cost go up?
Frequently, line for line — and that comparison usually excludes hardware refresh, power, and the hours currently spent maintaining servers. We put both columns in front of you before you decide.
Is lift-and-shift a waste of money?
No, when the driver is a deadline — a lease ending, hardware failing, an office move. It is a legitimate first step provided you plan to optimise afterwards rather than declaring it finished.
How long does a migration take?
Assessment is one to two weeks. Execution depends on how many applications and dependencies exist, which is precisely what the assessment establishes — which is why we do not quote before it.
The work this leads to
Moving an on-premise database to the cloud
Moving a production database is routine work done carefully. The difficulty is almost never the copy — it is the applications pointing at it and the cutover window.
Read itMigrationModernizing FoxPro, VB6 and Access systems
These systems usually encode two decades of business rules that exist nowhere else. The migration risk is not the code — it is losing the rules.
Read itOther guides
Cloud or on-premise, for an Indian business
The cost comparison people run is the wrong one, because it compares a server against a server and ignores everything the server needs to keep working.
Cost guideWhat ERP implementation actually costs in India
Most firms answer this with 'it depends, contact us'. It does depend — on a small number of things you can assess yourself before anyone quotes you.
Still weighing it up?
Most of these questions are quicker to settle in a conversation than in an article — particularly the ones where the answer depends on your numbers.