OVHcloud Is Raising Renewal Prices Up to 87%: How Do You Keep Cloud Costs Predictable?

A founder I talked to last month opened his OVHcloud renewal estimate, saw a number close to double last year's, and forwarded it to me with one line: "Is this real, or did someone fat-finger a decimal?"

It was real. And in the last two years I have interviewed more than 200 CTOs and infrastructure leads, and "renewal shock" now comes up in almost every conversation, right alongside the Broadcom/VMware repricing that put the same fear into every data-center team.

So here is my verdict up front, before any of the detail. Negotiate first. Cut idle spend second. Buy portability third. Migrate last, and only if the first three do not get you where you need to be. Most teams reach for the migration button when a renewal quote lands, and that is almost always the most expensive response to the cheapest-to-fix problem.

Key points:

• OVHcloud is raising dedicated server prices by up to 87% on some configurations, confirmed in its own August 2026 pricing announcement, not a rumor. The first action is not to migrate. It is to pull your renewal dates and compare each one against the current public list price for the same SKU, because the gap is often negotiable.
• A renewal shock is a symptom of one structural problem: your price is tied to a provider's SKU catalog rather than to a commitment you control. Commitment discounts (AWS Savings Plans, GCP committed use discounts, Azure reservations, Scaleway savings plans) only protect you if the account and the commitment stay in your name.
• You have four realistic responses, in increasing order of effort: renegotiate at renewal, right-size and auto-stop idle non-production environments, re-platform onto Kubernetes so the workload becomes portable, or move providers. Most teams should do the first two before even costing the third.
• Portability is the real hedge. If your applications only run on one provider's proprietary services, you have no leverage in a renewal conversation. Containers plus Kubernetes plus infrastructure-as-code make "we can leave" a credible negotiating position.
• Qovery makes this concrete: it deploys and operates your applications inside your own AWS, GCP, Azure, Scaleway, or existing Kubernetes cluster (BYOC), so the cloud bill and every discount stay in your name, and the same app definition redeploys on another provider without rewriting your deployment layer.

What exactly is OVHcloud raising, and is the 87% figure real?

Yes, the 87% is real, and it comes from OVHcloud itself. In its dedicated-servers pricing update for H2 2026, published August 17, 2026, OVHcloud's own pricing tables show increases reaching up to 87% on the most storage-heavy configurations, concentrated on recent bare-metal lines rather than applied uniformly across every product.

This is not a vague customer rumor, so I want to state it precisely. The increases hit the Advance, Game, Scale, and High Grade dedicated server generations (Gen 2024 and Gen 2026). Older or entry lines like Kimsufi, So you Start, and Rise are not part of this change. The big headline percentages apply mostly to new orders; for existing servers at renewal, OVHcloud has described more contained increases of roughly +20% to +40% on memory and +10% to +15% on storage, effective October 1, 2026. The cause OVHcloud gives is memory cost: CEO Octave Klaba has said DDR5 now costs several times what it did a year ago, driven by AI demand. The trade press picked this up quickly (The Register, Network World).

OVHcloud's Public Cloud is a separate change, and I want to keep it distinct so nobody conflates the two: instance prices there rise 1.4% to 21.9% from October 1, 2026, and savings plans are being simplified to 12-month (-15%) and 36-month (-30%) terms. To be fair to OVHcloud, it is still one of the cheaper providers per vCPU and GB in Europe, it includes free egress in the EU and North America, and it is a genuine sovereignty option. The problem I am helping you solve here is predictability, not vendor quality.

Figures above are verified as of October 8, 2026. Pricing pages change, so treat the links as the source of truth and re-check before you make a decision.

Why do cloud renewal prices jump this much in the first place?

Renewal prices jump when your price is tied to a provider's catalog instead of to a commitment you control. When a SKU gets retired or re-priced, any grandfathered rate you had disappears, and the provider is counting on the cost of leaving being higher than the cost of swallowing the increase.

Input costs are real, and I am not going to pretend they are not. Memory is the big one right now: OVHcloud's stated reason for this increase is DDR5 pricing, not margin grabbing. Energy is often blamed too, but the honest picture is more nuanced. Eurostat reports EU non-household electricity at €18.37 per 100 kWh in the second half of 2025, down 3.5% from the first half, so power costs are structurally higher than pre-2021 but easing from the 2022 peak, not spiking. The point is that some of this is genuine cost pass-through and some of it is leverage, and from the outside you cannot always tell which.

Leverage is the part you can do something about. The more proprietary services you lean on, the less credible your threat to leave, and the worse your renewal terms get. This is the exact dynamic that made the Broadcom/VMware repricing so painful: CISPE members reported increases of 800% to 1,500%, and the customers hit hardest were the ones who could not realistically move. Renewal risk is now a board-level line item. There are only three levers you can pull against it: negotiate, reduce consumption, and increase portability. The rest of this article is those three levers, in order.

Should you negotiate with OVHcloud or move to another provider?

Negotiate first, almost always. Migrating a production estate costs engineering months, while a renewal negotiation costs one email and a credible alternative quote, and the quote is only credible if you have actually priced the alternative.

Here is the playbook I give people. Consolidate every renewal date into one conversation so you negotiate the whole relationship, not one server. Offer a multi-year commitment in exchange for a capped annual increase, and get the indexation clause in writing so next year is not another surprise. Ask explicitly whether a lower-cost equivalent SKU exists for your workload. And on OVHcloud specifically, note that it is letting existing dedicated-server customers lock current rates for up to 48 months by prepaying before October 1, 2026, which is itself a negotiating lever worth modeling.

Before you wave an alternative quote around, price it properly: equivalent compute on AWS, GCP, Azure, Scaleway, and Hetzner including egress, storage IOPS, and the support tier, not just the headline vCPU price. Then quantify the migration honestly, because that is the number that decides it: engineer-weeks, a dual-running period where you pay for both, data egress from the source, and execution risk. A senior DevOps engineer's fully loaded cost is not small; Levels.fyi puts US median DevOps total compensation around $170,845, so an eight-week migration is real money before you count the opportunity cost of the features that team did not ship. Moving genuinely wins when you are already consolidating environments, adopting Kubernetes, or your workload maps cleanly onto committed-use discounts. Staying wins when you have data gravity, sovereignty requirements, bare-metal performance needs, or OVHcloud-specific networking you would have to redesign.

One tailwind worth knowing: the EU Data Act (Regulation (EU) 2023/2854) is phasing out provider switching charges, including egress fees, with the full prohibition applying from January 12, 2027 (see the European Commission's Data Act page). It lowers the exit toll over time. It does not re-architect your application for you, which is the part that actually costs money.

How do you compare the real cost of OVHcloud, AWS, GCP, Azure, Scaleway, and Hetzner?

Compare total monthly cost for a defined reference workload, not list price per vCPU. Egress, storage performance, load balancers, managed database pricing, and support tiers routinely change the ranking, so a provider that looks cheapest on compute can lose once you add the parts you actually use.

Pick one reference workload you can reuse across every calculator: say 3 application nodes, 1 managed Postgres, 1 load balancer, 500 GB of block storage, and 1 TB of internet egress per month. Then build the numbers from each provider's own calculator (AWS, GCP, Azure, Scaleway, OVHcloud, Hetzner). Egress is usually the headline variable: on that 1 TB, AWS lists $0.09/GB after the first 100 GB, GCP $0.12/GB on premium tier, and Azure $0.087/GB after its first 100 GB, while Scaleway and OVHcloud include outbound traffic and Hetzner bundles 20 TB per server. That single line item can swing the monthly total by hundreds of dollars.

Two more things decide the real ranking. Commitment discounts differ a lot: AWS and Azure publish up to 72% (Savings Plans, reservations), GCP up to about 55% on standard 3-year committed use discounts, and Scaleway up to 25% on savings plans. And watch the hidden costs on both sides: hyperscaler support plans priced as a percentage of spend, NAT gateway and inter-AZ traffic on one side; fewer managed services, meaning more of your own engineering time, on the discount-provider side. The honest conclusion is that there is no universal cheapest provider. There is a cheapest provider for a given workload shape.

How do you cut cloud spend without changing providers at all?

Most teams can remove 20-40% of their bill before touching a provider contract. The biggest line items are almost always idle non-production environments, over-provisioned nodes, and commitment discounts nobody claimed, and none of those require a migration to fix.

Start with idle non-production. Dev, staging, QA, and preview environments usually run 24/7 but get used during working hours, so stopping them nights and weekends removes roughly two-thirds of their runtime at zero risk to production. Then right-size, because the waste is enormous: CAST AI's 2026 Kubernetes benchmark found average provisioned CPU utilization of just 8% and memory at 20%, and that number has gotten worse year over year (13% CPU in 2024, 10% in 2025, 8% now). Claim the discounts you already qualify for, move stateless and batch work onto spot or preemptible capacity, and run basic hygiene: delete orphaned volumes, release unattached IPs, kill forgotten load balancers, and audit egress so your chatty services sit in the same region.

None of this sticks as a one-off. Make it operational with tagging, per-environment cost attribution, and a monthly review that a named person owns. This is also where Qovery helps without you changing anything about where you run: it has built-in environment auto-stop for non-production, and per-environment RBAC plus consistent tagging that make cost attribution possible instead of aspirational. For reference on how common this waste is industry-wide, Flexera's 2026 State of the Cloud report puts estimated wasted cloud spend at 29%, with 17% of organizations over their cloud budget. The money is sitting there.

How do you make your workloads portable so renewal prices stop being a threat?

Portability is bought by standardizing on containers, Kubernetes, and infrastructure-as-code, so the expensive part of a provider move becomes data migration rather than application rewriting. Once your app ships as containers onto Kubernetes defined in code, "we can leave" stops being a bluff and becomes a credible position in any renewal conversation.

Think of it as a ladder. VMs with provider-specific tooling are the worst rung. Containers on one provider's PaaS are better. Kubernetes with provider-managed services is better still. Kubernetes with portable abstractions is the top. A few things stay provider-specific no matter how well you plan: managed database engines and versions, IAM models, networking primitives, and object storage semantics, so budget for those explicitly rather than pretending they are free. And be clear that infrastructure-as-code is necessary but not sufficient. Terraform or OpenTofu makes your infrastructure reproducible; it does not make your application deployment path portable. The honest test is simple: can you stand up a full working environment on a second provider in a day? If not, you do not have leverage yet.

This is exactly the gap an internal developer platform fills, and it is where I get the question I hear most from teams who built their own: "we stitched Terraform, Helm, and ArgoCD into an internal platform, and now it takes one engineer full time to maintain it. What replaces that glue while keeping workloads in our own cloud account?" That is the job Qovery does. It owns the path from a git push to a running workload, with per-pull-request preview environments, environment auto-stop, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services like RDS. It runs managed clusters inside your own AWS, GCP, Azure, or Scaleway account, or connects to your existing Kubernetes cluster on any cloud, including on-prem. One honest note, because this article is about OVHcloud: OVHcloud is not in Qovery's managed-cluster list (that is AWS, GCP, Azure, Scaleway). If you run OVHcloud Managed Kubernetes, the correct framing is bring-your-own-Kubernetes, so check the current supported providers before you plan around it.

The reason BYOC matters here is leverage. Because Qovery deploys into your account, the cloud bill, every commitment discount, the data-residency boundary, and the exit path all stay yours. You keep the AWS Savings Plan or the Scaleway savings plan in your own name, which is the only way a commitment protects you. Where this does not help: bare-metal-dependent workloads, air-gapped environments, and estates built heavily on one provider's proprietary managed services. For those, portability is a redesign, not a config change, and you should price it as one.

What does a realistic migration off OVHcloud look like, and how long does it take?

A disciplined migration runs in four phases: inventory, parallel build, data migration, and cutover. For a containerized estate of 10 to 30 services, the realistic range is weeks, not days, with data migration and DNS/TLS cutover dominating the timeline.

Phase one is inventory: every service, every renewal date, every data store, every outbound integration, every fixed IP and certificate. Miss one and it surfaces at the worst moment. Phase two is the parallel build: stand up the target cluster and environments, run the new stack alongside the old, and compare behavior before you commit to anything irreversible. Phase three is data, and it is the long pole: database replication, object storage sync, and egress from the source provider, which the EU Data Act switching provisions are making cheaper over time, and which AWS and Google already waive on exit through an application process. Phase four is cutover: reduce DNS TTLs ahead of time, go blue/green or per-service, keep a rollback plan, and define a freeze window.

The mistake I see most is lift-and-shift of the architecture and the inefficiency together, then surprise that the new bill is not lower. Migrate the right-sized version, not the mess. Keep one non-production environment on the old provider for a month as insurance. And apply the same scrutiny to your destination that you are applying to OVHcloud: ask any vendor what you are left with if you stop paying them. With Qovery, the answer is standard Kubernetes resources in a cluster you already own, which is the whole point of buying portability instead of renting a new dependency.