There is a sentence that turns up in architecture reviews and risk committees across the country: "It's a CNCF Graduated project, so it's enterprise-ready." It sounds like due diligence. It is usually the end of it.
The sentence is not wrong about the project. Graduation is a demanding process, and a Graduated project has shown things many commercial products never have to show. The mistake is in what the sentence quietly assumes: that graduation transfers some of the work of running the software away from you. It does not.
CloudNala's position is that graduation is evidence about how a project is governed, not a promise about how your installation will be supported. Treat it as a strong input to selection. Then write down, separately and explicitly, who owns version support, upgrades, configuration and incident response for your deployment, because the badge answers none of those questions.
Baobab Retail Group is fictional, and its systems and figures are illustrative. Baobab, the Johannesburg grocery retailer from Part 1, learned this the practical way. Its GitOps controller, from a Graduated project, had been installed two years earlier by an engineer who has since left. It worked well. It was also four minor versions behind, outside the project's supported releases, and nobody on the platform team had ever upgraded it.
What graduation actually evidences
The CNCF publishes its graduation requirements as an application template in the Technical Oversight Committee's public repository. Reading it is worthwhile, because it is far more specific than the word "graduated" suggests. On 28 October 2026, the required items included, among others:
- Maintainers from at least two organisations, verified against the project's maintainer list and affiliations, and a documented mechanism that balances governance decisions across organisations.
- Clear, discoverable governance: how decisions are made, how maintainers join and leave, and a complete list of current maintainers.
- A defined security process: a way to report vulnerabilities, documented security response roles, a security self-assessment, a third-party security review and the OpenSSF Best Practices passing badge.
- Adoption evidence: a public list of adopters and use by at least three independent adopters, verified by the Technical Oversight Committee.
- A documented release process and a history of regular, quality releases.
Every one of these is about the health and survivability of the project. They reduce real risks: that the project is abandoned, that one company can steer it alone, that vulnerabilities are handled in private or not at all. Those risks matter, and a Graduated label means someone independent has checked them.
For the lifecycle itself, the due diligence process and how levels are awarded, the From Experiment to Trusted Platform series has the detail. The point here is narrower: notice what is not on the list.
What stays with you
None of the graduation requirements say anything about your deployment. Five obligations remain yours, whatever the level.
Version support windows. Open-source projects support a limited set of recent releases. Kubernetes itself, for example, maintains release branches for the most recent three minor releases, and its releases page states that versions from 1.19 onwards receive roughly one year of patch support. A Graduated project running an unsupported version gets no security fixes for that version. Baobab's GitOps controller was on exactly such a version.
Upgrades. Someone has to read release notes, test the upgrade against your configuration and run it. Projects publish deprecations and breaking changes. They do not test your manifests.
Configuration. Defaults are rarely right for production, and misconfiguration is your problem. A well-governed policy engine configured to audit nothing protects nothing.
Vendor distributions. If you buy a commercial distribution or use a cloud provider's managed add-on, you are relying on the vendor's packaging, patching cadence and support window, which may differ from the project's. A managed Kubernetes service, for instance, sets its own version lifecycle. Amazon EKS, to take one documented case, gives each Kubernetes minor version 14 months of standard support followed by 12 months of extended support at an additional per-cluster cost, and then upgrades the control plane automatically.
Commercial support. Foundation projects do not offer an SLA. If you need someone contractually obliged to help during an incident, you have to buy that from a vendor or build the capability yourself.
The ledger that should exist before production
The practical fix is simple and rarely done: for every cloud-native component in production, write a one-page support ledger. Baobab now keeps one per component, with five entries.
| Entry | Question it answers | Baobab's GitOps controller, after the review |
|---|---|---|
| Version and support window | Which version runs, and until when is it supported upstream or by the vendor? | Pinned to a supported minor release, end date in the platform calendar |
| Upgrade owner | Who reads release notes and runs upgrades, and how often? | Named engineer, quarterly upgrade window |
| Configuration record | Where does the configuration live, and who reviews changes? | In Git, changes reviewed by two engineers |
| Support route | Who do we call during an incident, and is it contracted? | Internal on-call; no commercial contract, accepted in writing |
| Exit plan | What would replacing it involve? | Manifests are standard; controller swap estimated at six weeks |
The ledger is deliberately boring. Its value is that each empty cell is a decision someone has to make, rather than an assumption someone is making. For pinning practice specifically, Pin the version before you pin your hopes on the platform covers why a pinned version is not a frozen one and how to keep a pinned platform current.
Three misreadings worth correcting
"Graduated means stable, so we can skip testing upgrades." Graduation evidences a release process and a history of quality releases. It does not mean releases never break anything. A mature project will still deprecate APIs and change defaults, and it will tell you in its release notes, which someone has to read.
"Incubating is not ready for production." Incubating projects are used in production by many organisations, and the CNCF's own description of the level is about growing adoption and stability. The level is a signal to look harder at the evidence, not a prohibition. Part 3 treats it as one weighted input among eight.
"If it's Graduated, our auditors will be satisfied." An auditor or a risk committee wants to know that your organisation manages the component: that it is patched, configured, monitored and supported. The project's governance is relevant background. Your ledger is the evidence.
When to pay for support
Whether to buy commercial support is a real decision with real trade-offs, and the maturity level should not make it for you.
Paying for support makes most sense when the component sits on a critical path, when your team lacks deep skills in it, when you need someone to backport fixes to a version you cannot yet leave, or when regulation or contracts require a supported product. For a South African organisation, it is also worth asking where the vendor's support engineers are and in which time zone, because a 2am incident in Johannesburg falls in the afternoon on the US west coast and at the start of the working day in Singapore.
Not paying makes sense when the component is well understood by your team, when you can stay inside the project's supported versions without strain, and when a failure is tolerable for the length of time it takes your own engineers to fix it. Baobab chose this route for its GitOps controller and accepted the risk in writing, which is the part that matters.
What Baobab changed
After the review, Baobab upgraded the controller in three steps across two weekends, one minor version at a time, testing each step against a copy of production configuration. Two deprecated settings had to be rewritten. Nothing broke in production, mostly because the team expected something might.
The bigger change was procedural. Every production component now has a ledger. The platform calendar shows every version's end-of-support date. And the phrase "it's Graduated" is now followed in reviews by a second question: "and who owns it here?"
Next: Part 3, A scorecard for choosing cloud-native projects. All parts are on the series page.
How CloudNala can help
CloudNala reviews cloud-native platforms for supportability. We inventory the components you run, check their versions against upstream and vendor support windows, identify components with no upgrade owner or support route, and help you build a support ledger and upgrade calendar your team can maintain. Where commercial support is worth paying for, we help you work out what to ask a vendor for.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Cloud Native Platform Review or write to us at consult@cloudnala.co.za