Workforce Transition and Role Development

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

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

1. Inventory of current roles — Which skills exist, which are missing? Where are there overlaps with future cloud roles?

2. Early involvement of the works council — Inform proactively before decisions are fixed. Present the qualification plan as a central element.

3. Individual conversations — Every affected person deserves a personal conversation about their development perspective, not a generic email.

4. Conclude qualification agreements — In writing, with timeline and resources. Not as a control instrument, but as a mutual commitment.

5. Structurally anchor learning time — Without explicitly protected learning time, qualification does not happen. Day-to-day operations systematically crowd out learning.

6. 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.