Cloud migration budgets fail in a specific way: the number covers moving the workloads and nothing else, and the project then spends its contingency on the parts nobody costed. So it is worth starting from what published 2026 figures actually say, and then being precise about what those figures do and do not include.
Cost per workload varies by what you do to it, and the spread is enormous. A straight rehost - lift and shift, no re-architecture - is commonly quoted between $40,000 and $150,000 per workload. Replatforming, where you move onto managed databases and container platforms without redesigning the application, runs $100,000 to $250,000. A genuine refactor into cloud-native services is $200,000 to $600,000 and upwards. Replacing a system with a SaaS product costs $30,000 to $120,000, essentially all of it in data migration and reconnecting integrations.
At project scale, mid-sized migrations typically land between $50,000 and $250,000 in total, while large enterprise programmes routinely pass $1 million. A comprehensive fifty-application portfolio migration is commonly $1 million to $3 million in professional-services fees alone, before any infrastructure spend.
Now the important caveat, because those are global professional-services rates. Delivered from India, the labour component - which is the majority of the bill - is substantially lower. The figures above are still worth knowing because they tell you the shape of the work and the ratio between the strategies, but do not take them as an Indian quote. What travels across markets is the proportion, not the absolute.
That proportion is the genuinely useful part, and published breakdowns are consistent about it. Assessment and discovery is 5-10% of the total. Migration execution is 40-55%. Licensing and replatforming is 10-20%. Running both environments in parallel during cutover is 5-15%. Security, compliance and governance is 10-15%. Change management and training is 5-10%. If a proposal you receive has nothing priced against parallel running or governance, it is not cheaper - two line items are missing, and they will arrive later as overruns.
The costs that actually break budgets are the ones outside that table, and industry estimates put their effect at 200-300% of the original number when they are not modelled upfront. In order of how often we see them: egress charges for moving data out of the old environment, which are invisible until the invoice; software licences that do not transfer to cloud infrastructure and must be repurchased; the dual-running period lasting longer than planned because one dependency will not move; and the post-migration optimisation phase, where the bill is high until someone rightsizes what was provisioned defensively.
On timelines, the published ranges are 4-12 weeks for a small estate, two to four months for ten to twenty applications, six to eighteen months for a large enterprise, and nine to fifteen months to refactor a single monolith. That last figure is the one to hold on to when someone proposes refactoring as part of the migration: it is a separate project wearing the same name, and merging them is the most reliable way to make a migration late.
The budgeting approach we would recommend is to price the assessment separately and first. Five to ten per cent of the total buys you a workload inventory, a dependency map and a wave plan - and, crucially, a cost estimate for the rest that is based on your actual estate rather than an average. Every migration that has surprised us on cost skipped that phase to save time, and every one of them spent the saving several times over.
