Understanding and Addressing Resistance
Last updated on
Resistance is rational
Section titled “Resistance is rational”Every organisation attempting a cloud transformation will encounter resistance. The first mistake is treating resistance as irrational or as something to overcome. Resistance is rational — it is the response of people who are trying to protect something they value: their job security, their area of expertise, their established processes, their team’s stability.
Understanding what is being protected is the prerequisite for constructive engagement. The six resistance patterns below are the most commonly encountered in German enterprise cloud transformations. Each has a legitimate concern at its core.
Pattern 1: The competence protector
Section titled “Pattern 1: The competence protector”What it looks like: Senior technical staff argue that cloud cannot match on-premises performance, security, or control. They raise detailed technical objections in every meeting.
The concern underneath: Career value built over years of on-premises expertise feels threatened by a technology shift that makes that expertise less relevant.
The constructive response: Identify the most respected technical voices and involve them early in the technical design. Their on-premises knowledge is genuinely valuable in migration planning. Create a visible path from on-premises expertise to cloud expertise — certifications, specialised roles, recognition for people who make the transition.
Pattern 2: The compliance guardian
Section titled “Pattern 2: The compliance guardian”What it looks like: Legal, compliance or CISO staff raise regulatory concerns at every stage. Every new cloud service triggers a detailed risk assessment.
The concern underneath: Legitimate responsibility for regulatory compliance in an environment where the regulatory landscape for cloud is genuinely complex.
The constructive response: This resistance is the most important to take seriously. Involve the CISO and compliance team in the governance design from the beginning, not as reviewers of decisions already made. Use STACKIT’s sovereign cloud properties and BSI C5 attestation proactively — most cloud compliance concerns are directly addressed by STACKIT’s documented controls.
Pattern 3: The availability defender
Section titled “Pattern 3: The availability defender”What it looks like: Operations teams argue that current systems are stable and cloud introduces unnecessary risk. “If it ain’t broke, don’t fix it.”
The concern underneath: Responsibility for production stability — any outage will be attributed to the cloud migration, regardless of cause.
The constructive response: Agree on a clear separation of responsibility for production stability during migration. Celebrate operational stability as a transformation success, not just a baseline. Design the migration to improve availability metrics, not just maintain them.
Pattern 4: The autonomy preservationist
Section titled “Pattern 4: The autonomy preservationist”What it looks like: Department heads or business unit leaders resist the CCoE governance requirements. “We know what we need better than a central team.”
The concern underneath: Real concern about losing decision-making autonomy over their technology environment.
The constructive response: The CCoE federated model directly addresses this concern — teams retain full autonomy within guardrails. Make the autonomy explicitly visible: show what teams can do without CCoE approval versus what requires CCoE involvement. The list of autonomous actions should be long.
Pattern 5: The workload worrier
Section titled “Pattern 5: The workload worrier”What it looks like: Middle management raises concerns about team capacity. “We cannot take on cloud transformation on top of everything else.”
The concern underneath: Legitimate concern about change management overhead being loaded onto already-stretched teams.
The constructive response: Take this concern seriously — it is often correct. The Adoption phase requires genuine resource investment. Work with middle managers to identify what can be deferred, what can be supported by external resources, and what the realistic timeline is given current capacity.
Pattern 6: The strategic sceptic
Section titled “Pattern 6: The strategic sceptic”What it looks like: Senior stakeholders ask whether the business case is real. “I’ve seen these promises before.”
The concern underneath: Experience with IT transformation programmes that promised more than they delivered.
The constructive response: Acknowledge the track record honestly. Show the conservative scenario, not just the optimistic one. Commit to specific, measurable outcomes with defined review points. Build credibility through early wins rather than large promises.