Managed Lifecycle Responsibility: What It Actually Covers
Every provider in this market says "we operate your platform." Fewer can say what that means when the invoice is itemized.
Swiss federal procurement for IT operations services draws the line explicitly. It separates platform processes into two categories: ones any firm supplying engineers by the hour can perform, and ones that require a bounded area of responsibility, with clear system boundaries, that stays with one operator over the life of the contract. The second category is what "managed lifecycle" means, and it is the shape of what VSHN sells.
Two categories of work, not two tiers of skill
The distinction is not about seniority or technical depth. A contractor billing by the hour can be excellent at a task and still structurally unable to take on the second category, because that category requires continuity the engagement itself does not provide.
Delivery, staffing and project work, the kind any competent firm can bid on a time-and-materials basis:
- Implementing a specific configuration change or feature
- Running a defined migration or upgrade project
- Providing engineers who work inside a client's own team and tooling, under the client's own direction
Lifecycle responsibility, which requires standing commitment to a system rather than a task:
- Maintaining the configuration model and the record of what is actually deployed, not just what was last requested
- Controlling and tracking configuration information over time, including license management
- Assessing, recording and evaluating changes as they happen, including handling emergency changes under pressure
- Assessing risk from disaster scenarios before they occur, not reconstructing a response after
- Identifying compliance requirements, defining the measures that satisfy them, and running the reviews that prove it
- Developing and maintaining the competencies the platform needs over years, not for the duration of one ticket
- Setting the strategic direction for the platform itself: what it needs to become, not only what was asked for today
A firm supplying people into someone else's team can be asked to do any one of these once. What it cannot do is be the party accountable for all of them continuously, because accountability for a system requires staying with that system, and staffing engagements end.
Why this distinction is procurement's own, not ours
This is not VSHN's framing of itself. It mirrors how large buyers already separate platform service management into five management process categories, Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement, and classify the supporting processes beneath them by whether each one requires standing platform ownership. Swiss public-sector IT operations tenders use exactly this structure to decide which bidders can take on a "Managed Lifecycle" engagement, defined as responsibility for a bounded platform or product area including service levels, operations, stabilization and continuous improvement, and which can only supply staff into someone else's.
In VSHN's own practice, those five categories map onto work that is continuous rather than episodic: Service Strategy is deciding what the platform needs to become and raising that before a customer asks; Service Design is planning a change before it touches production; Service Transition is rolling that change out safely, tested and reversible; Service Operation is the day-to-day running, monitoring and incident handling; and Continual Service Improvement is the standing practice of making the platform cheaper to run and safer to change, which only exists under a commitment that outlasts a single engagement.
That a public buyer needs this distinction in writing tells you it is not obvious from a sales pitch. Two vendors can say "we operate your platform" and mean structurally different things: one means a team is available, the other means one party is accountable for the system's configuration, its compliance posture, its disaster readiness and its long-term direction, for as long as the contract runs.
What this changes about the objection "we'll just hire engineers"
Hiring engineers gives you staffing capacity. It does not by itself give you lifecycle responsibility, because that responsibility is a function of continuity and accountability structure, not headcount. A team that rotates, that reports to a project rather than to the platform, or that has no mandate to maintain the configuration model between tickets, is doing delivery work even if every person on it is skilled.
VSHN's Red Hat OpenShift and Kubernetes services are sold and operated as lifecycle responsibility: one party accountable for the platform's configuration, change management, disaster-risk posture, compliance evidence and long-term direction, for the duration of the engagement, with CNCF Kubernetes Certified Service Provider status held since 2019 and Red Hat Premier Certified Cloud and Service Provider status on the Red Hat side.
Where this sits next to our other content
This page explains the shape of the commitment. Security controls covers what that commitment evidences in audit terms, and sovereignty covers who holds it and under what law. Compare VSHN against building and staffing this yourself on partners.
Get a lifecycle responsibility assessment
Comparing a staffing proposal against an operations proposal and the two numbers don't look like they are pricing the same thing? They probably are not. Contact us and we'll walk through which category of work each line item actually falls into.