Cloud Migration Services for Teams Racing a Lease or Licence Deadline
Cloud migration services are bought under a deadline — a lease ending, a licence renewal, hardware past its refresh date. The decision that matters is not whether to move but which workloads justify the cost of moving, and every quote you compare should answer that question before it names a number.
When are cloud migration services worth the cost?
Migration pays back fastest when a spend event is already on the calendar. Five conditions do most of the justifying:
Where none of these hold — steady load, amortised hardware, no compliance pressure — the honest answer may be to stay put, and a section below covers exactly that. Migration is also frequently the first stage of a broader cloud modernization strategy; the two are budgeted separately for good reason.
What does cloud migration cost?
Cloud migration cost is priced by workload shape, not server count. The bands below assume production quality: tested cutover, rollback plans, and documentation. A quick cloud migration calculator gives a first estimate before any call.
| Workload type | What it covers | Timeline | Cost |
|---|---|---|---|
| Single application rehost | One application, lift-and-shift, no re-architecture | 2–6 weeks | $1,500 – $4,750 |
| Application replatform | Managed database, container runtime, CI/CD | 4–10 weeks | $4,750 – $13,300 |
| Multi-application programme | 5–20 applications, phased cutover, integration rework | 12–24 weeks | $13,300 – $47,500 |
| Data centre exit | Full estate migration, network, identity, DR | 16–36 weeks | $28,500 – $114,000 |
| Post-migration optimisation | Rightsizing, commitments, cost governance | Monthly | From $665/month |
US professional-services rates for the same work are commonly quoted at $2,000–$8,000 per application for a straight rehost, and $100,000–$250,000 per application where an enterprise replatform includes security redesign and a database transition. A 20 to 50 application programme is typically priced at $80,000–$250,000 in services alone. The bands above reflect a hybrid delivery model, not a lower standard of engineering. An assessment converts them into a fixed written quote for your estate.
Data volume moves these bands more than most buyers expect — transfer windows and sync tooling are covered in the data migration cost guide. The assessment converts a band into a fixed written cloud migration cost estimate for your estate.
Which cloud migration strategy fits your workload?
The six Rs are the standard decision framework, and most estates use four of them at once. The mistake is picking one strategy for everything; the table is per workload.
| Strategy | What happens | Relative cost | Time to migrate | Best when |
|---|---|---|---|---|
| Rehost | Lift and shift migration — the workload moves as-is onto cloud infrastructure | Lowest | Days–weeks | A deadline dominates; re-architecture can wait for usage data |
| Replatform | Small upgrades in transit — managed database, containers, CI/CD | Low–medium | Weeks | The ops burden, not the code, is the problem |
| Refactor | Re-architecture for cloud-native services | Highest | Months | The application is core to the business and worth the investment |
| Repurchase | Replace with SaaS — the workload stops being yours to run | Subscription | Weeks | A mature SaaS product matches the workflow closely |
| Retire | Switch it off — discovery reliably finds servers nobody uses | Negative | Immediate | Usage data shows the application earns nothing |
| Retain | Stays on-premise, revisited on a schedule | Zero now | — | Latency, licensing, or residency makes moving a bad trade |
AWS, Azure, or Google Cloud?
Honestly: platform choice usually follows existing licensing, skills, and enterprise agreements rather than benchmarks. The feature gap between the three is smaller than the gap between a well-run and badly-run estate on any of them — which is why AWS migration services and Azure migration services are compared below on tooling and commercial terms rather than benchmarks.
| Platform | Migration tooling | Strongest fit | Commercial notes |
|---|---|---|---|
| AWS | AWS migration services: Migration Hub, Application Migration Service, DMS for databases | The broadest service catalogue; strongest for mixed and unusual workloads | Migration Acceleration Program credits can offset a meaningful share of the build |
| Microsoft Azure | Azure migration services: Azure Migrate for discovery, replication, and cutover | Windows Server, SQL Server, .NET estates, and anywhere Microsoft 365 already anchors identity | Hybrid Benefit re-uses existing Windows and SQL licences — often the decisive commercial factor |
| Google Cloud | GCP migration services: Migrate to Virtual Machines, Database Migration Service | Data and analytics workloads heading for BigQuery; Kubernetes-first teams | Committed-use discounts are simpler than reserved instances, but the enterprise agreement matters more |
Which technologies do migrations run on?
The working set most programmes draw from — chosen per estate, documented so your team can own it after handover.
Cloud Platforms
AWSMigration & Replication Tooling
AWS Migration HubAWS DMSInfrastructure as Code
AWS CloudFormationContainers & Runtime
Amazon EKSDatabases
Observability & Cost Governance
What drives a migration quote up?
Application count and interdependency dominate. Twenty applications that call each other migrate as one untangling problem, not twenty small ones — dependency mapping is where quotes diverge most.
Data volume and the transfer window come second. Terabytes move slowly over production links, and a short cutover window forces staged sync tooling that a lazy weekend copy avoids.
Licence re-entitlement is the quiet one: SQL Server, Oracle, and Windows licences rarely transfer cleanly, and re-buying mid-migration is where budgets break. It belongs in the assessment, not the surprise column.
Compliance and data residency add controls, evidence, and region constraints — modest on most estates, decisive on regulated ones.
Refactoring in scope is the multiplier: every workload promoted from rehost to refactor roughly triples its line in the quote. Deferring refactors until usage data exists is usually the better sequence.
How long does a cloud migration take?
Six stages, with a decision point after the first: work stops there if the business case does not hold — which costs a fraction of discovering it at wave three. The stages below double as a cloud migration checklist: nothing in a later row is safe to start before the row above it has produced its output.
| Stage | Weeks | What happens | What you get |
|---|---|---|---|
| Assessment and dependency mapping | 2–3 | Estate inventoried, dependencies mapped, six-R decision per workload | A staged plan and a fixed quote — the go/no-go point |
| Landing zone build | 2–4 | Cloud foundation built as code in your accounts | Accounts, network, identity, guardrails |
| Pilot migration | 2–4 | One representative workload moved, rehearsed, and cut over | One workload live, runbook proven |
| Wave migration | 4–20 | Applications moved in dependency order, integrations re-pointed | Estate moving in scheduled waves |
| Cutover and decommission | 2–4 | Final sync, DNS cutover, old estate verified idle then retired | Old estate retired, costs stop |
| Optimisation | Ongoing | Rightsizing against real usage, commitment purchases, cost governance | Rightsizing and commitment planning |
Which hidden costs surface after cutover?
Egress charges on chatty integrations. An application that stayed on-premise talking constantly to one that moved now pays $0.02–$0.09 per gigabyte for the conversation — the line that grows fastest on integrations left spanning on-premise and cloud mid-wave (transfer maths in the data migration cost guide). Dependency mapping exists to catch exactly this. Hybrid connectivity circuits held open through the migration add $1,000–$5,000 per month on top.
Licence re-entitlement. The SQL Server licence that was fine on-premise may need repurchasing for cloud cores — five figures on a mid-size estate when discovered late.
Dual-running during waves. Both estates run at once mid-programme. Budget one to three months of overlap per wave; a quote without a dual-running line is incomplete.
On-premise sizing carried into cloud. Servers sized for peak-plus-headroom become instances billed every hour. Industry measurement puts roughly 29% of enterprise cloud spend on capacity nobody uses — recovering it is what the optimisation retainer exists to do.
The unbudgeted optimisation pass. Commitment planning (reserved instances, savings plans) routinely cuts 20–40% off the run rate, and nobody schedules it. Put it in the contract or in the calendar — and budget a 20% contingency against dependencies discovery does not surface; large database modernisations are the line item that most often runs over.
What does application migration to cloud actually involve?
Four pieces of work decide whether a single application moves cleanly. Dependency mapping first: what the application calls, what calls it, and which of those links will cross a network boundary after the move. Surprises here are the root cause of most failed cutovers.
The data sync window second: how the database stays consistent between first copy and final cutover — snapshot-and-catch-up for tolerant workloads, continuous replication for the rest.
The cutover rehearsal third: the move performed against a copy, timed, and documented as a runbook, so the real event is a repeat rather than a first attempt.
The rollback plan last: the tested route back if verification fails, with the old environment kept warm until the new one has survived a full business cycle.
How does a data centre exit differ from migrating applications?
Data center migration to cloud is a different problem wearing the same name. Application migration optimises one workload; a data centre exit clears a building — including the workloads nobody owns, the network appliances with undocumented rules, the identity infrastructure everything authenticates against, and the DR arrangements that must exist on day one in the new estate.
The lease deadline changes the engineering. When the exit date does not move, strategy tilts toward rehost-now-optimise-later, waves are scheduled backwards from the date, and anything that cannot move in time needs a colocation bridge priced into the programme rather than discovered in the final quarter.
Identity and network land first — the landing zone stage exists because every subsequent wave authenticates against it. Getting DR proven before the first production wave, not after the last, is the discipline that separates a controlled exit from a gamble.
When are cloud migration services the wrong answer?
More often than migration vendors admit — staying on-premise is frequently the better trade. Steady, predictable load on hardware already amortised is cheaper to keep than to move — the cloud premium buys elasticity, and a workload that never flexes never collects. Data residency rules occasionally cannot be satisfied by any available region. Latency-bound workloads sitting next to physical plant — factory control systems, trading systems near an exchange — lose more to distance than they gain from elasticity. And some licence terms punish virtualised or cloud deployment badly enough to erase the case on their own.
The six-R table handles this honestly: those workloads are Retained, revisited when hardware, licence, or regulation changes. An assessment that ends with “keep these twelve on-premise” is a success, not a failure — Perimattic has delivered exactly that verdict, and the assessment is priced so that answer costs little to reach.
What should you ask a cloud migration consulting partner before signing?
Cloud migration consulting is sold on confidence; these five questions test for substance. Ask them of every candidate — this one included.
Frequently asked questions
How much does cloud migration cost?
By workload: a single application rehost runs $1,500 – $4,750, a replatform $4,750 – $13,300, a multi-application programme $13,300 – $47,500, and a full data centre exit $28,500 – $114,000. The assessment converts those bands into a fixed written quote for your estate — and a cloud migration cost estimate is free to sanity-check with the online calculator.
How long does a cloud migration take?
A single application moves in 2–6 weeks. A multi-application programme typically runs 12–24 weeks in dependency-ordered waves. A data centre exit is usually scheduled against the lease date, working backwards — the assessment and dependency mapping stage takes 2–3 weeks and fixes the timeline in writing.
Is lift and shift migration a bad practice?
No — it is the right first move for many estates. Rehosting gets workloads off failing hardware or an expiring lease fastest, and defers re-architecture until usage data exists to justify it. It becomes a mistake only when the lifted estate is never optimised: on-premise sizing carried into the cloud typically overspends 30–50% until a rightsizing pass.
Who owns the cloud accounts after migration?
You do, from the first day of the landing zone build. Accounts, billing, identity, and infrastructure code sit in your name — if the engagement ends, the estate keeps running on subscriptions you control, with no handover fee.
Do you provide cloud migration managed services after cutover?
Yes — ongoing cloud migration consulting and managed operations run as a monthly optimisation retainer covering rightsizing, commitment planning, patching, and cost governance from $665/month. It is optional: full documentation and runbooks transfer at cutover either way, so an in-house team can run the estate instead.
Should I migrate to cloud at all?
Sometimes no — and an assessment that concludes 'keep these on-premise' is a legitimate deliverable. Migration pays back when a spend event is imminent (lease end, hardware refresh, licence renewal), when capacity swings, or when compliance controls the current estate cannot produce. Steady load on amortised hardware, latency-bound workloads next to physical plant, and licences that penalise virtualisation are the three profiles where staying put is the cheaper trade.
How do I choose between AWS, Azure, and Google Cloud?
Existing licensing and identity anchor the decision more than benchmarks. Windows Server, SQL Server, and Microsoft 365 estates lean Azure via Hybrid Benefit. Analytics-heavy or Kubernetes-first workloads lean Google Cloud. Everything else — especially mixed or unusual workloads — usually lands on AWS for the broader service catalogue. The gap between a well-run and badly-run estate on any of the three is larger than the gap between the platforms; commercial terms and the enterprise agreement matter more than feature comparisons.
What is a landing zone and why does it come first?
The landing zone is the cloud foundation built as infrastructure code before any workload moves: accounts, network segmentation, identity federation, encryption defaults, logging, and cost guardrails. Building it first means every subsequent wave inherits the same controls without rework, and every DR test runs against the same baseline. Skipping the landing zone to save two weeks up front creates rework at every wave boundary; two to four weeks is the standard duration.
How do I calculate cloud migration ROI?
Compare the three-year total cost of the current estate — hardware refresh, licences, colocation, staff, DR — against the target cloud run-rate plus one-off migration services. Include a realistic optimisation pass (rightsizing and commitment planning routinely cut 20–40% off the initial cloud bill) and a dual-running overlap of one to three months per wave. The quickest first estimate comes from a cloud migration calculator; the assessment converts that into a fixed written figure for the specific estate.
What are the biggest risks in cloud migration?
Undiscovered dependencies are the number-one cause of failed cutovers — the application that quietly calls a database nobody documented. Dual-running budget shortfalls come second: both estates run in parallel through the wave programme, and quotes without an overlap line item are incomplete. Licence re-entitlement (SQL Server, Oracle, Windows) is the quiet third — repurchasing mid-programme is where five-figure surprises land. Egress charges on integrations left spanning cloud and on-premise mid-wave are the fourth. Dependency mapping in the assessment stage is the single control that reduces all four.
Related services and guides
Application Modernization
The five Rs applied to the legacy systems already running in your estate.
Learn about Application Modernization→Cloud-Native Development
Container-first architecture for what you build once the migration lands.
Learn about Cloud-Native Development→Data Engineering Consulting
Pipelines and observability for the data that moves with the estate.
Learn about Data Engineering Consulting→Cloud Migration Cost Calculator
Sanity-check a quote against workload count and migration strategy.
Learn about Cloud Migration Cost Calculator→
Price the Programme Before You Commit to It
A migration assessment maps the dependencies, makes the six-R call per workload, and prices the programme in writing — and says honestly if the business case does not hold. Yours to keep, whoever runs the migration.