Fixed scope. Your maintenance window. A rollback plan signed off before work begins. Your team never has to touch production, and does not lose a sprint to it.
Three facts this whole service rests on. Every one of them is yours to verify — the sources are under each tile.
A new minor release appears roughly three times a year, and each version gets about a year of patches. On Amazon EKS, standard support runs 14 months from release. A production cluster therefore needs upgrading at least twice a year — indefinitely.
Sources: kubernetes.io — release cadence, kubernetes.io — patch support, AWS EKS pricing. Verified 30 Aug 2026.
A cluster past standard support costs USD 0.60 per hour on Amazon EKS instead of USD 0.10. On Azure AKS, the Premium tier with Long-Term Support likewise costs USD 0.60 per hour against USD 0.10 on Standard. Both platforms charge USD 365 per month per cluster for a postponed upgrade — roughly EUR 3,760 a year per cluster.
Sources: AWS EKS pricing, AKS pricing (verified through the Azure Retail Prices API), Microsoft Learn — AKS LTS. Verified 30 Aug 2026.
Downtime is not caused by the cluster. It is caused by your applications: a single replica, a missing PodDisruptionBudget, no graceful shutdown, long-lived connections without draining. We answer for what happens twenty minutes after that button is pressed.
This one is not a statistic but experience from production clusters. What passes and what does not in your case comes out of the assessment — written down service by service.
Assessment, remediation, rehearsal, execution, handover. Everything else rests on the rehearsal — which is why it is a phase of its own, with its own time budget.
Read-only access, nothing touched in production. We go through manifests and Helm charts for deprecated and removed APIs, build an add-on compatibility matrix (CNI, CSI, ingress, cert-manager, service mesh, GitOps, autoscaler) and score every service on whether it survives a node drain. You get a risk map, a Workload Readiness Scorecard and an upgrade plan with a fixed price.
Whatever fails the Readiness Bar gets fixed before the upgrade — on the current cluster version. Missing PodDisruptionBudgets, a single replica on a service that should not have one, probes that lie, applications without graceful shutdown. Application fixes and the cluster upgrade never share one window.
We start outside production, of course — on your staging, or on a clone of the cluster that we build when staging does not resemble production in the ways that matter. The difference is not that we rehearse, it is what we take away from it: we run the whole upgrade including the rollback and record the timing of every step. Those timings then become the content of the maintenance window instead of being estimated. If something breaks, it breaks here, and we fix it before it ever reaches you.
This is the only way to talk about zero downtime and mean it. Without a measured rehearsal, “no downtime” is a hope.
In your maintenance window, nights and weekends included, following the runbook proven in the rehearsal. The rollback plan is agreed in writing beforehand. We track progress against your SLOs rather than against a feeling — if the indicators move, we know before you do.
Updated infrastructure code, a final report, and a runbook your own team can follow for the next upgrade. We do not need you dependent on us — if you hire us again, let it be because it pays off.
Zero downtime is a measured quantity, not a claim in a proposal. We measure the impact on availability first during the rehearsal on a clone of your cluster, and again during the upgrade itself, against your own SLOs. The measured figures go into the final report.
The yardstick is the Readiness Bar — ten specific conditions verified during the assessment. Anything that fails gets a separate remediation phase: we fix it before the upgrade, on the current cluster version. Application fixes and the cluster upgrade never share one window — if something failed, the cause could not be traced.
Nobody can honestly promise zero downtime for an application they have never seen. That is why we start by looking at it.
We do not publish a price list, because every cluster is neglected differently. What we do publish is a fixed price for the first step, and an honest account of what drives the second.
A fixed price for 1 to 3 clusters. Each additional cluster +EUR 500.
You get a risk map, the full list of deprecated APIs, an add-on compatibility matrix, a Workload Readiness Scorecard and an upgrade plan — with a fixed price for execution.
What the price depends on:
We go above EUR 9,000 only where the assessment finds services below the Readiness Bar — that work is a separate line at EUR 800 per day. Each further identically built cluster comes to EUR 2,500 – 4,000.
The exact upgrade price is set after the assessment — without one it would be a guess, and a guess on a production cluster is not a price but a promise somebody ends up paying for. Prices exclude VAT and apply to clusters on Azure AKS and Amazon EKS.
Before we talk about our price: work out what it costs you not to upgrade the cluster.
Calculate the cost of waiting →The assessment is a fixed EUR 2,900 for 1 to 3 clusters, with each additional cluster at +EUR 500. It takes five working days and needs only read-only access. The upgrade of the first cluster is typically EUR 6,000 to 9,000, depending on how many versions the cluster is behind, how many services fail the Readiness Bar, and whether a non-production environment exists.
We deduct the assessment fee from the upgrade price if you order the upgrade within 90 days. The exact upgrade price is set after the assessment — without one it would be a guess.
The assessment needs read-only access: a reader role in Azure or AWS and a ServiceAccount in the cluster with permission to read objects. We do not read secrets and do not need access to them.
Execution requires temporarily elevated rights, limited to the maintenance window and revocable in one step. On Azure we use Azure Lighthouse, on AWS a cross-account role with an ExternalId. We never enter the management account. Every action appears in your own logs under the name of a specific engineer.
The rollback plan is agreed in writing before work starts — including the specific conditions that trigger it. We do not invent those criteria during the window, when there is no calm to do it in.
The rollback is part of the rehearsal: we run it on a clone of your cluster and time it. So we know in advance that it works and how many minutes it takes — and that figure goes into the maintenance window plan rather than being argued about on the night.
This is also why we never mix application fixes and the cluster upgrade into one window: if something failed, the cause could not be traced. Commercial terms for such an event are agreed in the contract, according to the scope of the engagement.
The assessment takes five working days. From assessment to execution is usually two to three weeks, depending on the scope of remediation. Execution itself runs in the maintenance window you choose, nights and weekends included. You set the window, not us.
Our priority is Azure AKS and Amazon EKS — that is where our process is most established and the pricing most predictable. Self-hosted clusters (kubeadm, RKE2, k3s) are assessed case by case: we will always do the assessment, and decide on execution based on how the cluster is built. We say so on the first call, not after you have paid.
Tell us which version you are on and how many production clusters you run. We reply within one working day with a date and a scope — the first call needs no access at all.