Workforce Transformation & Capability Empowerment

PLAN

People-First Workforce Transition

Analyze existing IT roles, identify qualification gaps, and support employees through the transition into new cloud role profiles.

In 1 trail

People first — technology follows

Cloud transformations do not fail because of Kubernetes. They fail because people do not know what role they are supposed to play in the new world, whether their job is secure, and whether their experience still counts.

A workforce transition is not an HR project running in parallel with the technical migration. It is a leadership task that begins before the first technical step and does not end after go-live.

The three transition scenarios

Workforce Transition Overview

Scenario 1: Upskilling — developing existing employees

The most common and most recommended path. Experienced employees know the business domain, the processes, and the internal culture. Cloud knowledge is learnable — domain knowledge is not.

What a qualification agreement contains:

Designation of the target role and the current starting profile
Timeline with milestones (typically: 6–18 months)
Concrete qualification measures (courses, certifications, mentoring, project shadowing)
Resources: learning time, cost coverage, leave provisions
Assessment criteria: how is goal attainment measured?
Consequences in case of non-fulfilment (formulated for both parties)

Role transitions that are common in practice:

Swipe sideways to see the whole table

Starting role	Target role	Typical transition period
System administrator	Platform Engineer	9–12 months
Network administrator	Cloud Network Engineer	6–9 months
Storage administrator	Cloud Storage & Backup Specialist	6–9 months
IT project manager	Cloud Product Owner	12–18 months
Application developer	Cloud-Native Developer	4–8 months
IT controller	FinOps Analyst	6–12 months

Scenario 2: New hire — new roles, new people

Some roles do not yet exist in the organisation and cannot be filled internally. This frequently applies to Platform Architects, Site Reliability Engineers, and DevSecOps specialists.

What applies in the new hire process:

Internal advertisement before external — even if the internal success probability appears low
Clear role profiles that describe the specific STACKIT context
Realistic salary expectations: cloud specialists are scarce, the market is competitive
Onboarding programme for external hires: they know the cloud, but not your organisation

Scenario 3: Managed service — outsourcing tasks

For areas without strategic differentiation, the decision may be made to permanently transfer tasks to a managed service provider. This has employment law consequences that must be clarified early.

What must be clarified:

Scope of the task transfer and the remaining internal steering function
Impact on affected employees: redeployment, upskilling, or — as a last resort — redundancy
SLA structure with the MSP: what does the provider guarantee, how is it measured?
Exit clauses: what happens if the MSP changes or the decision is reversed?

The most common mistakes

Mistake 1: Informing too late. If employees hear rumours about the cloud migration before receiving official information, you lose trust that is difficult to regain. Communicate early, even when not all questions can yet be answered.

Mistake 2: Treating qualification as optional. Anyone who regards upskilling as a nice-to-have ends up with neither qualified teams nor a viable cloud environment. Qualification is investment, not cost.

Mistake 3: Describing roles too technically. A job description that consists exclusively of lists of technologies puts off experienced employees whose domain competence is not reflected in a row of certifications.

Mistake 4: Measuring success only technically. Anyone who measures transformation success exclusively by SLAs and deployment frequency notices too late when teams are overloaded, frustrated, or have disengaged internally.

Practical implementation

Inventory of current roles — Which skills exist, which are missing? Where are there overlaps with future cloud roles?
Early involvement of the works council — Inform proactively before decisions are fixed. Present the qualification plan as a central element.
Individual conversations — Every affected person deserves a personal conversation about their development perspective, not a generic email.
Conclude qualification agreements — In writing, with timeline and resources. Not as a control instrument, but as a mutual commitment.
Structurally anchor learning time — Without explicitly protected learning time, qualification does not happen. Day-to-day operations systematically crowd out learning.
Make progress visible — Regular check-ins and publicly visible successes (certifications, new project responsibilities) reinforce commitment.

Connection to Cloud Empowerment

The qualification content for the roles described here is developed in the Cloud Empowerment chapter as the Six-Track model. Workforce transition and qualification planning are two sides of the same coin — the organisational framework here, the learning content there.

BASE

Works Council Partnership & Qualification

Involve the works council as a partner under Section 87 of the German Works Constitution Act, structure legally sound written qualification agreements, and protect learning time.

In 1 trail

People first — technology follows

Cloud transformations do not fail because of Kubernetes. They fail because people do not know what role they are supposed to play in the new world, whether their job is secure, and whether their experience still counts.

A workforce transition is not an HR project running in parallel with the technical migration. It is a leadership task that begins before the first technical step and does not end after go-live.

The three transition scenarios

Workforce Transition Overview

Scenario 1: Upskilling — developing existing employees

The most common and most recommended path. Experienced employees know the business domain, the processes, and the internal culture. Cloud knowledge is learnable — domain knowledge is not.

What a qualification agreement contains:

Designation of the target role and the current starting profile
Timeline with milestones (typically: 6–18 months)
Concrete qualification measures (courses, certifications, mentoring, project shadowing)
Resources: learning time, cost coverage, leave provisions
Assessment criteria: how is goal attainment measured?
Consequences in case of non-fulfilment (formulated for both parties)

Role transitions that are common in practice:

Swipe sideways to see the whole table

Starting role	Target role	Typical transition period
System administrator	Platform Engineer	9–12 months
Network administrator	Cloud Network Engineer	6–9 months
Storage administrator	Cloud Storage & Backup Specialist	6–9 months
IT project manager	Cloud Product Owner	12–18 months
Application developer	Cloud-Native Developer	4–8 months
IT controller	FinOps Analyst	6–12 months

Scenario 2: New hire — new roles, new people

Some roles do not yet exist in the organisation and cannot be filled internally. This frequently applies to Platform Architects, Site Reliability Engineers, and DevSecOps specialists.

What applies in the new hire process:

Internal advertisement before external — even if the internal success probability appears low
Clear role profiles that describe the specific STACKIT context
Realistic salary expectations: cloud specialists are scarce, the market is competitive
Onboarding programme for external hires: they know the cloud, but not your organisation

Scenario 3: Managed service — outsourcing tasks

For areas without strategic differentiation, the decision may be made to permanently transfer tasks to a managed service provider. This has employment law consequences that must be clarified early.

What must be clarified:

Scope of the task transfer and the remaining internal steering function
Impact on affected employees: redeployment, upskilling, or — as a last resort — redundancy
SLA structure with the MSP: what does the provider guarantee, how is it measured?
Exit clauses: what happens if the MSP changes or the decision is reversed?

The most common mistakes

Mistake 1: Informing too late. If employees hear rumours about the cloud migration before receiving official information, you lose trust that is difficult to regain. Communicate early, even when not all questions can yet be answered.

Mistake 2: Treating qualification as optional. Anyone who regards upskilling as a nice-to-have ends up with neither qualified teams nor a viable cloud environment. Qualification is investment, not cost.

Mistake 3: Describing roles too technically. A job description that consists exclusively of lists of technologies puts off experienced employees whose domain competence is not reflected in a row of certifications.

Mistake 4: Measuring success only technically. Anyone who measures transformation success exclusively by SLAs and deployment frequency notices too late when teams are overloaded, frustrated, or have disengaged internally.

Practical implementation

Inventory of current roles — Which skills exist, which are missing? Where are there overlaps with future cloud roles?
Early involvement of the works council — Inform proactively before decisions are fixed. Present the qualification plan as a central element.
Individual conversations — Every affected person deserves a personal conversation about their development perspective, not a generic email.
Conclude qualification agreements — In writing, with timeline and resources. Not as a control instrument, but as a mutual commitment.
Structurally anchor learning time — Without explicitly protected learning time, qualification does not happen. Day-to-day operations systematically crowd out learning.
Make progress visible — Regular check-ins and publicly visible successes (certifications, new project responsibilities) reinforce commitment.

Connection to Cloud Empowerment

The qualification content for the roles described here is developed in the Cloud Empowerment chapter as the Six-Track model. Workforce transition and qualification planning are two sides of the same coin — the organisational framework here, the learning content there.

STEP

Cloud Empowerment Foundation

Build a durable learning organization through protected sandboxes, cloud guilds, and a cloud champions network.

In 1 trail

What this chapter does for you

Cloud technology is bought. Cloud capability is built. The difference between organisations that complete cloud transformation successfully and those that look back frustrated after 18 months is almost always the same question: did the people learn to genuinely use the platform?

This chapter shows you how to develop cloud capability systematically — with a structured learning architecture of six tracks, a clear qualification strategy for all roles, and an organisational learning infrastructure that does not end with the project.

Know the skill gap

A structured assessment of existing and required cloud capabilities — differentiated by role, with concrete prioritisations for the start.

Six learning paths

From cloud awareness for all employees to specialised tracks for Security, FinOps and Architecture — every person gets the learning path that fits their role.

STACKIT University & certifications

STACKIT’s own learning platform, recommended external certifications by track, and a realistic training budget for mid-sized organisations.

Learning organisation

Sandbox environments for experimentation, Cloud Guilds as Communities of Practice, and the Cloud Champions network as a multiplier into the teams.

The investment in people — and why it pays off

Empowerment Overview

Qualification is respect

When organisations invest in the qualification of their employees, they send a clear message: you are part of this transformation, not its victim. This message is the strongest change management lever an IT leader has.

People who know that their capability is actively being developed are more open to change. They become ambassadors instead of sceptics. They bring knowledge into the teams that no external consultant will ever know better: their own organisation, its history, its weaknesses — and its strengths.

Connection to other chapters

Cloud Empowerment is the practical implementation of cultural change and lays the foundation for all technical adoption topics.

Start with the Skill Gap Analysis — baseline before action planning.
Choose the right Training Model for your organisational and role composition.
Plan Certifications as a structured proof of capability.
Establish Sandbox and Communities of Practice as a permanent learning infrastructure.

LIFT

Skill Gap Analysis

Systematically capture existing and missing competencies to define individual, role-based training paths.

In 1 trail

Why skill gap analysis comes before training planning

Without a skill gap analysis, the result is a one-size-fits-all training programme that is too specific for some and too general for others. The analysis provides the foundation for role-specific learning paths and realistic training budgets.

Step 1: Role inventory

A complete inventory of all IT roles and their cloud requirements:

Swipe sideways to see the whole table

Role domain	Typical positions	Cloud responsibilities	Number of people
Platform Engineering	Sysadmins, platform engineers	IaC, landing zone, managed services	[number]
Application Development	Software developers, DevOps	CI/CD, containers, cloud-native patterns	[number]
Security & Compliance	Security analysts, CISO office	IAM, policy-as-code, DevSecOps	[number]
Data & Analytics	Data engineers, BI analysts	Managed databases, object storage	[number]
Operations & SRE	IT operations, SRE	Observability, incident response	[number]
FinOps & Controlling	IT controllers, procurement	Cloud economics, tagging, showback	[number]
Management & Architecture	IT leadership, enterprise architects	Strategy, governance, cost ownership	[number]

Step 2: Four-dimensional competency assessment

Competencies are assessed in four fields on a 1–4 scale for each role domain:

Rating scale:

1 – No knowledge: Has not yet worked with the technology
2 – Basic understanding: Concepts known, no practical experience
3 – Practical experience: Can work independently, with support
4 – Expert: Can guide others, knows best practices

Swipe sideways to see the whole table

Competency field	Assessment questions
Cloud fundamentals	Cloud service categories, STACKIT portfolio, shared responsibility
Technical skills	Writing IaC, operating Kubernetes, configuring networks
Security & compliance	IAM concepts, least privilege, GDPR requirements
Cloud economics	Cost models, tagging standards, optimisation levers

Step 3: Gap matrix

The output of the assessment is a gap matrix — for each role domain the delta between current state and target competency:

Swipe sideways to see the whole table

Role domain	Cloud fundamentals	Technical skills	Security	Economics	Priority
Platform Engineering	Current: 2 / Target: 4	Current: 1 / Target: 4	Current: 2 / Target: 3	Current: 1 / Target: 2	🔴 High
App Development	Current: 2 / Target: 3	Current: 2 / Target: 3	Current: 1 / Target: 3	Current: 1 / Target: 2	🔴 High
Security	Current: 2 / Target: 3	Current: 1 / Target: 3	Current: 2 / Target: 4	Current: 1 / Target: 2	🟡 Medium
IT Operations	Current: 2 / Target: 3	Current: 2 / Target: 3	Current: 2 / Target: 2	Current: 1 / Target: 2	🟡 Medium
Controlling	Current: 1 / Target: 2	Current: 1 / Target: 1	Current: 1 / Target: 1	Current: 1 / Target: 3	🟡 Medium
Management	Current: 1 / Target: 2	Current: 1 / Target: 1	Current: 1 / Target: 2	Current: 1 / Target: 2	🟢 Low

Assessment methods

Option A: Self-assessment with calibration Each person rates themselves using the 1–4 scheme. The team lead then calibrates the assessments. Fast, but at risk of overestimation.

Option B: Structured interview A CCoE member or external trainer conducts 30-minute interviews with one person per role domain. Representative, but not comprehensive.

Option C: Technical assessment Short tasks (1–2 hours): write IaC, review an IAM policy, calculate a cost model. Objective, but time-intensive.

Recommendation for most organisations: Option A with team lead calibration for the initial assessment. After 6 months of training: Option C to measure progress.

Output: Training plan as direct result

The gap matrix feeds directly into the training model:

Red priority → Tracks C/D as mandatory training, immediate sandbox access
Yellow priority → Tracks B/C in the first 6 months
Green priority → Track A mandatory, B/C optional

LIFT

The Six-Track Training Model

Run structured, role-based STACKIT University training tracks, from cloud awareness through architecture and security to FinOps.

In 2 trails

Why six tracks instead of one universal course

Cloud competency is not a uniform quantity. A CIO needs strategic understanding, not Terraform knowledge. A platform engineer needs Terraform depth, not FinOps details. An IT controller needs cloud economics expertise, not Kubernetes knowledge.

Six role-specific tracks ensure that each person receives exactly the skills they need for their cloud responsibilities — no more, no less.

Track A — Cloud Awareness (All staff)

Target group: 100% of IT staff + relevant business units + management Duration: 4 hours (mandatory, within 6 months of adoption start) Format: Interactive e-learning course + optional live Q&A

Learning objectives:

What is cloud? What is sovereign cloud?
What does STACKIT mean for our organisation?
How does my work change — and what stays the same?
Why are we choosing STACKIT instead of US Hyperscalers?

STACKIT relevance: STACKIT University Track A covers these topics with STACKIT-specific context.

KPI: Track A completion rate — target: 100% within 6 months

Track B — Cloud Practitioner (IT generalists)

Target group: IT staff without cloud specialisation, project managers, IT procurement Duration: 12–16 hours Format: Blended in-person/online course + first sandbox exercises

Learning objectives:

Understand the STACKIT product portfolio (Compute, Storage, SKS, Managed DB, Object Storage)
Cloud cost models: pay-as-you-go, reserved instances, cost optimisation
Basic security principles: IAM, least privilege, shared responsibility
First hands-on experience: STACKIT console, creating simple resources

STACKIT relevance: STACKIT University Track B + hands-on lab in STACKIT sandbox

Track C — Cloud Engineer (Platform engineers, DevOps)

Target group: Platform engineers, sysadmins in transition, DevOps engineers Duration: 40–80 hours Format: Technical intensive course + project practical tasks

Learning objectives and content:

Swipe sideways to see the whole table

Module	Content	Hands-on
IaC with Terraform	Terraform fundamentals, STACKIT Terraform Provider	Deploy VPC + VM
STACKIT SKS	Managed Kubernetes, create clusters, deploy workloads	App on SKS
Network configuration	VPC, subnets, firewall rules, hub-and-spoke	Landing zone network
CI/CD integration	GitHub Actions / GitLab CI with STACKIT	Build a pipeline
Observability	STACKIT Observability, logging, alerting	Configure an alert
IAM in practice	Service accounts, workload identity, RBAC	IAM setup

Track C final project: Deploy a complete workload (web application + database) on STACKIT — with Terraform, in SKS, with CI/CD pipeline, with monitoring and tagging.

STACKIT relevance: STACKIT University Track C + CKA preparation + Terraform Associate preparation

Track D — Cloud Architect (Enterprise architects, senior engineers)

Target group: Enterprise architects, senior cloud engineers, technical leads Duration: 40+ hours Format: Workshop format + architecture review cases

Learning objectives:

Landing zone design: hub-and-spoke, multi-project topology, CIDR planning
High-availability architecture patterns on STACKIT
Migration architecture: 6R strategy (Rehost, Replatform, Refactor, Repurchase, Retain, Retire)
Cost optimisation architecture: right-sizing, reserved instances, serverless patterns
Multi-service design: how compute, storage, database and Kubernetes work together

Track E — Cloud Security (Security teams)

Target group: Security analysts, CISO office, compliance managers Duration: 30–50 hours Format: Technical course + compliance mapping workshop

Learning objectives:

STACKIT IAM deep-dive: federation, RBAC, service accounts, PAM
Policy-as-code: Terraform Sentinel, Open Policy Agent
DevSecOps: security scanning in CI/CD pipelines
Regulatory compliance in the cloud: GDPR/TISAX/BAIT in practice
Cloud incident response: forensics, containment, recovery

STACKIT relevance: STACKIT IAM product training + CCSP preparation

Track F — Cloud FinOps (Controlling, IT management)

Target group: IT controllers, CFO office, IT management Duration: 16–24 hours Format: Business-oriented seminar + dashboard workshop

Learning objectives:

Cloud cost models: CAPEX vs OPEX, reserved vs on-demand
Implementing STACKIT tagging strategy
Creating and interpreting showback reports
Building chargeback models
Improving budget management and forecast accuracy

STACKIT relevance: STACKIT Billing Dashboard Workshop + FinOps Foundation Practitioner preparation

Training rollout timeline

Swipe sideways to see the whole table

Month	Activity
Month 1	Launch Track A for all IT staff; sandbox access for technical roles
Months 2–3	Track C first cohort (platform engineers + DevOps)
Months 3–4	Track B for IT generalists; Track E first cohort (security)
Months 4–6	Track D for architects; Track F for controlling
Months 6–12	Further cohorts, cloud guilds active, external certifications

Common mistakes

One-size-fits-all: A general cloud course for everyone wastes time.

Training without application: Track C without an immediately following practical project in the sandbox evaporates within 2 weeks.

Training under time pressure: Instructing teams to complete training while maintaining 100% production load reliably results in training not happening.

GOAL

STACKIT University & Certifications

Structurally verify cloud capabilities and secure training progress through standardized certification exams.

In 1 trail

STACKIT University

STACKIT University is STACKIT’s proprietary learning platform with product-specific courses, hands-on labs and platform-specific certifications.

What STACKIT University covers:

The STACKIT product portfolio in detail (SKS, Object Storage, Managed DB, IAM, Networking)
STACKIT-specific best practices
Hands-on labs with real STACKIT infrastructure
STACKIT-native certifications

Integration into the training tracks:

Track A: STACKIT Cloud Fundamentals course
Track B: STACKIT Practitioner course + first labs
Track C: STACKIT Engineer course + all available labs
Track D: STACKIT Advanced Architecture

Recommendation: Set up STACKIT University access for all IT staff from day 1 of the adoption phase. Cost: part of the STACKIT partnership agreement, often at no additional charge.

Certification as a career signal

Certifications carry a dual value:

Knowledge evidence: Structured learning and verified understanding
Career signal: Publicly visible proof of capability development

Recommendation: Celebrate certification successes internally (intranet, all-hands) — this motivates others and makes the transformation visible.

Practical steps

Set up STACKIT University access for all IT staff
Align the certification budget with HR and controlling
Plan the first certification cohort for Track C graduates (Terraform Associate + CKA)
Celebrate certification successes in internal communication channels