AWS Cloud Migration Cost for UK Firms: What the Project Costs, and What the Bill Looks Like After Cutover

0
15

There are two numbers, not one. There is a one-off project cost to get workloads across. There is a monthly bill after cutover. Teams that conflate them either under-fund the move or panic when NAT, egress and non-production environments show up on the invoice.

How to read these ranges

The figures below separate partner project fees from ongoing AWS consumption. They are planning ranges, not quotations, and assume workloads suitable for a conventional migration programme. They exclude VAT, third-party licences, application redevelopment beyond agreed scope, connectivity changes and exceptional data-transfer requirements. Cost them against the target region and architecture before approval.

What the project actually costs

Indicative partner-engagement ranges for UK AWS migration projects typically fall into the following bands:

Join The European Business Briefing

New subscribers this quarter are entered into a draw to win a Rolex Submariner. Join 40,000+ founders, investors and executives who read EBM every day.

Subscribe
Company size Workloads Typical approach Timeline Project cost
Startup / small SaaS 1–3 apps, 1 database Replatform 3–6 weeks £12,000 – £31,000
Mid-market 5–15 apps, 2–5 databases Replatform + partial refactor 2–4 months £39,000 – £119,000
Enterprise 20–50+ apps, complex dependencies Mixed (strategy per workload) 4–12 months £119,000 – £392,000+

That is partner engagement: assessment, architecture, infrastructure as code, execution, a period of support after go-live. It is not the AWS bill.

For UK firms in regulated or security-sensitive sectors, the decision can also include operational-resilience requirements, customer or contractual security controls, and data-location considerations. FCA-regulated firms, for example, need to address operational resilience in their wider governance and outsourcing arrangements; Cyber Essentials Plus may be relevant where required by customers, procurement rules or the organisation’s security programme.

Regulatory, audit and security-control requirements can move a project towards the top of the band because they add discovery, design, logging, evidence, testing and documentation work.

A single web app plus its database, moving from Heroku or a small on-premise estate onto ECS Fargate and RDS, can still be done in four to six weeks including assessment, proof of concept, migration and stabilisation. Larger estates need waves, and a six-week promise against a 20-application landscape is not ambition but a future change request.

What the bill looks like after cutover

Once DNS has flipped, the invoice is mostly compute, database, data transfer and telemetry.

Component Small app Mid-size platform Enterprise
Compute (ECS Fargate) $50–150 $300–1,500 $2,000–10,000+
Database (RDS) $60–140 $250–800 $1,000–5,000+
Data transfer $10–30 $50–200 $200–2,000
Monitoring and logging $20–50 $50–200 $200–1,000
Monthly total $150–400 $700–2,500 $3,500–18,000+

Illustrative monthly ranges only. AWS pricing varies by region, deployment model, availability design, storage, data transfer, committed-use discounts and usage patterns. Validate estimates in the AWS Pricing Calculator for the target architecture and region before approval.

AWS invoices in dollars. UK finance should account for VAT on infrastructure spend, where applicable, and the exchange rate. AWS states that its UK branch charges VAT on service charges for UK accounts unless the customer has special status; VAT treatment and recoverability depend on the customer’s tax position, so finance or tax advisers should confirm the treatment for the individual business.

Platform choice moves the needle:

  • ECS Fargate bills per vCPU and memory. No instance babysitting.
  • EKS is $0.10 per hour per cluster during standard support, plus nodes and other underlying services. It starts to make sense when the team already needs Kubernetes capabilities or operates a meaningful microservices estate; extended support costs differ.
  • EC2 can be cheaper per unit of compute, but creates an operational responsibility for instance management, patching and capacity planning.
  • RDS costs depend on engine, instance class, storage, I/O, availability design and region. For production workloads with defined high-availability or recovery requirements, Multi-AZ is often appropriate. Its cost and architecture should be assessed against the service’s RTO, RPO, business impact and existing resilience design.
  • Aurora and standard RDS should be costed against the expected workload rather than compared through a fixed percentage: the outcome depends on engine, instance class, storage, I/O profile, availability design and region.

For many first migrations, ECS Fargate is a sensible option where the workload suits containers and the team does not need Kubernetes-specific capabilities. EKS is a product decision, not a default.

The invoice line items that were not in the board pack

Material variance from the modelled bill often comes from five places:

  1. Egress. Internet egress pricing depends on destination, region, service and volume. Hybrid estates that still call on-premise systems, or chatty third-party APIs, can feel this first.
  2. Cross-AZ traffic. Cross-Availability Zone traffic can add cost and should be included in the architecture model, particularly for talkative microservice designs.
  3. NAT Gateway. NAT Gateway charges include an hourly component and data processing. Private subnets without suitable VPC endpoints for services such as S3 and DynamoDB can create avoidable NAT processing costs.
  4. CloudWatch Logs. Log ingestion, storage and query volumes should be modelled. Verbose production logging can become a material cost line.
  5. Non-production left on. Dev and staging running overnight and through the weekend. Scheduling them off outside business hours can materially reduce that slice of spend.

None of this is a gotcha unique to the UK. It is what happens when the model was built from the EC2 price list alone. The fix is a proof of concept that includes a modelled invoice, not a spreadsheet of on-demand instances.

Does the move beat staying in the data centre?

The project is a one-off. AWS can reduce total cost of ownership where it replaces hardware refresh, over-provisioning and part of the operational burden. It can also cost more if the target architecture is oversized or poorly governed.

Break-even depends on migration scope, remaining on-premise commitments, data-centre exit costs, licensing, the target architecture and AWS consumption. It should be modelled as part of the business case rather than assumed.

If the bill is higher than the old estate, the architecture may have copied the data centre into AWS: oversized instances, no autoscaling, no Savings Plans on the baseline, test environments left on. That is not “cloud is expensive”. That is a lift-and-shift of a bad operating model.

How UK firms pull the one-off cost down without shrinking the wrong scope

For qualifying migrations, AWS MAP funding may offset a substantial portion of eligible partner-led assessment, mobilisation and migration work. Funding levels, eligible activities and approval criteria vary by programme, customer profile and current AWS policy; confirm the available incentives before treating them as part of the approved business case. As an AWS Advanced Tier Partner, Devopsity can assess eligibility and prepare the required migration case with the customer through its AWS cloud migration service.

MAP does not make the monthly invoice free. It lowers the barrier on the project bucket. The run-rate still follows rightsizing, data transfer design and whether non-production sleeps at night.

The other lever is not moving everything. Portfolio assessment often identifies workloads that can be retired, consolidated, replaced with SaaS or deliberately retained. The proportion varies materially by estate. Every application taken out of scope can shorten a wave and shrink the data problem.

Time is a function of data, not of slides

A rehost of one application: one to two weeks. Ten to twenty applications with replatforming: two to four months, including assessment, proof of concept, waves and stabilisation. A rebuild of the core product: six to twelve months.

Data sits on the critical path.

  • Small database, an acceptable maintenance window: dump and restore, measured in hours.
  • Live production: AWS Database Migration Service with change data capture, so source and target stay in sync while you validate. The DNS cut can be brief, but the final cutover window depends on application behaviour, data consistency requirements and the runbook.
  • Engine change (Oracle to PostgreSQL, SQL Server to Aurora): schema conversion first, then the percentage that will not convert, then CDC. Budget two to four weeks for that stretch.
  • Stateful systems with tight coupling: even with DMS, a 15–60 minute window at low traffic can be the grown-up answer. Put it in the board pack as a business risk, not as an IT footnote.

Skip assessment (three to five days) or skip the proof of concept (one to two weeks) and the overrun shows up in the production wave, which is the expensive place to discover a dependency.

A board-ready way to ask for the number

Ask for both buckets, in pounds, with VAT called out on the run-rate.

  1. What is in scope, what is retired, what stays on-premise for the next wave.
  2. Per application: rehost, replatform or refactor. One mode for the whole estate is how technical debt is imported.
  3. Data: volume, source engine, target engine, whether production can tolerate a window, whether it must stay in London.
  4. Controls that have to exist before the first production wave: identity, encryption, logging, Cyber Essentials Plus / FCA overlays where applicable.
  5. Three environments or one.
  6. Project cost with and without MAP.
  7. Three months of modelled AWS spend after cutover, including egress and non-production, so month-two finance is not a surprise.

That is the conversation. A single “migration for £X” is a slide.

For the underlying ranges, tooling (Migration Hub, MGN, DMS) and the wave process behind these figures, the Devopsity guide to AWS cloud migration cost for UK firms breaks down project cost, the invoice after cutover, and the line items that usually miss the first spreadsheet.

LEAVE A REPLY

Please enter your comment!
Please enter your name here