---
title: "Widerstände verstehen und adressieren"
description: "Die sechs häufigsten Widerstandsmuster bei Cloud-Transformationen, die legitimen Anliegen dahinter und konkrete Antworten, die Widerstand in Engagement verwandeln."
sidebar:
  order: 3
  label: "Widerstände"
source_url: "https://framework.stackit.cloud/de/advisory/cultural-change/resistance/"
source_file: "docs/de/advisory/cultural-change/resistance.mdx"
---

## Widerstand ist rational

Jede Organisation, die eine Cloud-Transformation versucht, wird auf Widerstand stoßen. Der erste Fehler ist, Widerstand als irrational oder als etwas zu behandeln, das es zu überwinden gilt. Widerstand ist rational — es ist die Reaktion von Menschen, die etwas schützen wollen, das sie wertschätzen: Arbeitsplatzsicherheit, Fachwissen, etablierte Prozesse oder die Stabilität ihres Teams.

Zu verstehen, was geschützt wird, ist die Voraussetzung für eine konstruktive Auseinandersetzung. Die folgenden sechs Muster haben jeweils ein berechtigtes Anliegen im Kern.

## Muster 1: Der Kompetenzschützer

**Wie es aussieht:** Leitende technische Mitarbeitende bezweifeln, dass die Cloud mit On-Premises-Leistung, Sicherheit oder Kontrolle mithalten kann.

**Die zugrunde liegende Sorge:** Der über Jahre aufgebaute Karrierewert lokaler Expertise fühlt sich durch den Technologiewandel bedroht.

**Konstruktive Antwort:** Respektierte technische Stimmen früh in das Design einbinden, ihr On-Premises-Wissen für die Migration nutzen und einen sichtbaren Weg zu Cloud-Expertise über Zertifizierungen, neue Rollen und Anerkennung schaffen.

## Muster 2: Der Compliance-Hüter

**Wie es aussieht:** Recht, Compliance oder CISO bringen in jeder Phase regulatorische Bedenken vor.

**Die zugrunde liegende Sorge:** Die berechtigte Verantwortung für Compliance in einer komplexen regulatorischen Cloud-Landschaft.

**Konstruktive Antwort:** CISO und Compliance von Beginn an in das Governance-Design einbinden. Souveräne Cloud-Eigenschaften und dokumentierte STACKIT-Kontrollen proaktiv nutzen.

## Muster 3: Der Verfügbarkeitsverteidiger

**Wie es aussieht:** Betriebsteams argumentieren, dass aktuelle Systeme stabil sind und die Cloud unnötiges Risiko einführt.

**Die zugrunde liegende Sorge:** Jede Störung könnte unabhängig von ihrer Ursache der Cloud-Migration zugeschrieben werden.

**Konstruktive Antwort:** Verantwortung für Produktionsstabilität während der Migration klar trennen, Stabilität als Transformationserfolg feiern und die Migration auf bessere Verfügbarkeitswerte ausrichten.

## Muster 4: Der Autonomiebewahrer

**Wie es aussieht:** Abteilungs- oder Spartenleitungen wehren sich gegen CCoE-Governance: „Wir wissen besser, was wir brauchen.“

**Die zugrunde liegende Sorge:** Der Verlust von Entscheidungshoheit über die eigene Technologieumgebung.

**Konstruktive Antwort:** Das föderierte CCoE-Modell macht sichtbar, was Teams innerhalb der Leitplanken selbst entscheiden können und wann CCoE-Beteiligung erforderlich ist.

## Muster 5: Der Workload-Sorgenvolle

**Wie es aussieht:** Das mittlere Management bezweifelt, dass die Teams zusätzlich zur bestehenden Arbeit eine Cloud-Transformation bewältigen können.

**Die zugrunde liegende Sorge:** Change-Management-Overhead könnte auf bereits überlastete Teams abgewälzt werden.

**Konstruktive Antwort:** Die Sorge ernst nehmen, verschiebbare Arbeit identifizieren, externe Unterstützung prüfen und einen realistischen Zeitplan anhand der tatsächlichen Kapazität entwickeln.

## Muster 6: Der strategische Skeptiker

**Wie es aussieht:** Hochrangige Stakeholder fragen, ob der Business Case real ist: „Diese Versprechen habe ich schon einmal gehört.“

**Die zugrunde liegende Sorge:** Erfahrungen mit IT-Transformationsprogrammen, die mehr versprochen als geliefert haben.

**Konstruktive Antwort:** Die Historie ehrlich anerkennen, das konservative Szenario zeigen, konkrete messbare Ergebnisse mit Prüfpunkten festlegen und Glaubwürdigkeit durch frühe Erfolge aufbauen.