> ## Documentation Index > Fetch the complete documentation index at: https://docs.devin.ai/llms.txt > Use this file to discover all available pages before exploring further. # Migration Ihres Enterprise-Kontos > Schrittweise Einführung der deklarativen Umgebungskonfiguration in Ihrem Enterprise-Konto: Rollout-Status, org-spezifische Überschreibungen, Playbook für die schrittweise Migration und Monitoring. Die Migration eines Enterprise-Kontos von der klassischen Umgebungseinrichtung zur deklarativen Konfiguration ist eine weitreichende Änderung. Auf der Seite „Rollout“ können Enterprise-Admins diesen Übergang detailliert steuern. Sie können Blueprints für einige Pilot-Orgs aktivieren, die Einführung in Ihrem eigenen Tempo ausweiten und bei Problemen sofort zurückrollen.
## Rollout-Status im Enterprise
Auf der Rollout-Seite gibt es eine Auswahl für den **Rollout-Modus**, die steuert, wie Blueprints für Organisationen verfügbar sind. Es gibt drei Modi sowie einen Anfangszustand, bevor deklarative Umgebungen aktiviert sind: | Status | Bedeutung | Auswirkung auf Organisationen | | --------------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Nicht aktiviert** | Deklarative Umgebungen wurden für das Enterprise noch nicht aktiviert | Keine Orgs sehen die Umgebungsseiten. Alle Orgs verwenden das klassische Setup. Wenden Sie sich zum Aktivieren an Ihren Cognition-Administrator. | | **Testbetrieb** | Nur manuell aktivierte Organisationen verwenden deklarative Umgebungen | Ein Enterprise-Administrator aktiviert einzelne Orgs auf der Rollout-Seite. Alle anderen Orgs bleiben beim klassischen Setup und sehen keine Änderungen. | | **Verfügbar** | Org-Administratoren sehen eine Migrationsaufforderung und können selbst umstellen | Org-Administratoren im klassischen Setup sehen auf ihrer Seite „Machine Configuration“ einen Migrationshinweis. Sie können ohne Eingreifen eines Enterprise-Administrators eigenständig migrieren. | | **Standardmäßig aktiviert** | Neue Organisationen verwenden standardmäßig deklarative Umgebungen | Alle neuen Orgs starten mit Blueprints. Bestehende Orgs, die im klassischen Setup mit Repos arbeiten, erhalten automatisch klassische Überschreibungen. | Die Abfolge ist: **Testbetrieb → Verfügbar → Standardmäßig aktiviert**. Sie können über das Dropdown für den Rollout-Modus frei zwischen **Testbetrieb** und **Verfügbar** wechseln. **Standardmäßig aktiviert** ist jedoch eine dauerhafte Aktion, die ohne einen Cognition-Administrator nicht rückgängig gemacht werden kann. **Standardmäßig aktiviert ist dauerhaft.** Sobald Sie diesen Modus aktivieren, kann er nicht ohne Kontaktaufnahme mit Ihrem Cognition-Administrator auf „Testbetrieb“ oder „Verfügbar“ zurückgesetzt werden. Stellen Sie sicher, dass Ihr Enterprise-Blueprint vollständig validiert ist und die meisten Orgs bereits Blueprints verwenden, bevor Sie diesen Modus aktivieren.
### Details zu „Testing mode“
Im Status „Testing mode“ verwenden Organisationen, die nicht aktiviert wurden, weiterhin das klassische Setup, und für sie ändert sich nichts. Der Enterprise-Admin kann auf der Rollout-Seite einzelne Orgs aktivieren. Nur diese Orgs wechseln zur deklarativen Konfiguration. Dies ist der Modus, der als Ausgangsbasis dient, wenn deklarative Umgebungen für ein Enterprise erstmals aktiviert werden.
### Details zum Modus „Available“
Der Modus „Available“ fügt einen Migrationshinweis hinzu: Org-Admins, die noch das klassische Setup verwenden, sehen auf ihrer Seite „Machine Configuration“ einen Hinweis, der sie zur Migration zur deklarativen Konfiguration auffordert. Dadurch ändert sich ihre Einrichtung nicht, und sie erhalten keinen Zugriff auf die vollständigen Seiten zur Umgebungskonfiguration. Sie werden lediglich darauf aufmerksam gemacht, dass Blueprints verfügbar sind, und erhalten die Möglichkeit, sich selbst zu aktivieren. Das ist nützlich, um Aufmerksamkeit zu schaffen und Org-Admins die Migration in ihrem eigenen Tempo zu ermöglichen.
## Überschreibungen pro Organisation
Enterprise-Admins können den Rollout-Status einzelner Organisationen direkt in der Tabelle pro Organisation auf der Rollout-Seite überschreiben: * **In den Modi „Testing“ oder „Available“**: Bestimmte Organisationen für Blueprints **aktivieren**. Diese Organisationen wechseln sofort vom klassischen Setup zur deklarativen Konfiguration. * **Im Modus „Enabled by default“**: Bestimmte Organisationen **wieder auf das klassische Setup zurücksetzen**. Diese Organisationen verwenden weiterhin ihre klassische Konfiguration. Überschreibungen sind dauerhaft. Sie bleiben auch bei Modusänderungen bestehen. Wenn Sie eine Organisation während des Modus „Testing“ für Blueprints aktivieren, bleibt sie bei Blueprints, wenn Sie zu „Available“ oder „Enabled by default“ wechseln.
### Automatische klassische Überschreibungen
Beim Aktivieren von **Enabled by default** verhindert ein Sicherheitsmechanismus Unterbrechungen: Jede Org, die derzeit das klassische Setup verwendet **und Repository konfiguriert hat**, erhält automatisch eine explizite klassische Überschreibung. Das bedeutet, dass sich durch den Wechsel für Orgs, die das klassische Setup aktiv nutzen, nichts ändert. Sie werden unverändert weitergeführt, bis Sie sie ausdrücklich migrieren. Orgs ohne Repository (oder Orgs, die bereits Blueprints verwenden) sind von diesem Schutzmechanismus nicht betroffen. Am besten erstellen und validieren Sie Ihre Konfiguration zunächst isoliert, bevor Sie sie für Org-Admins freigeben. Vermeiden Sie eine Big-Bang-Migration. Beginnen Sie kontrolliert, prüfen Sie alles und erweitern Sie den Rollout dann schrittweise.
### Phase 1: Isoliert aufsetzen und verifizieren (Testing)
Beginnen Sie mit dem Enterprise im Modus **Testing**. Orgs können sich nicht selbst dafür anmelden, sodass Sie die volle Kontrolle haben. 1. **Aktivieren Sie deklarative Umgebungen** für das Enterprise. Ihr Cognition-Administrator aktiviert die Funktion, wodurch das Enterprise in den Modus Testing versetzt wird. 2. **Erstellen Sie eine dedizierte Test-Org** zum Testen der Umgebungskonfiguration. Diese Org dient ausschließlich dazu, Ihre Blueprints zu validieren. 3. **Aktivieren Sie die deklarative Konfiguration** nur für diese Test-Org (über den org-spezifischen Override auf der Rollout-Seite). 4. **Konfigurieren Sie Ihren Enterprise-Blueprint**: Installieren Sie alle gemeinsam genutzten Sprach-Runtimes, Sicherheitstools, Unternehmenszertifikate, internen CLIs, Proxy-Einstellungen und die Registry-Authentifizierung. Das ist Ihre Basisschicht, die jede Org übernimmt. 5. **Konfigurieren Sie einen Org-Blueprint** für die Test-Org mit allen Tools auf Org-Ebene oder der Registry-Konfiguration. 6. **Fügen Sie Repository-Blueprints hinzu** für eine repräsentative Auswahl an Repositorys. Wählen Sie Repos aus, die Ihre gängigsten Tech-Stacks abdecken. 7. **Prüfen Sie alles Ende-zu-Ende**: Starten Sie Devin-Sitzungen in diesen Repos und bestätigen Sie, dass alles funktioniert. Die Repos sollten geklont, Abhängigkeiten installiert und Lint-/Test-/Build-Befehle korrekt ausgeführt werden; außerdem sollten alle Tools in den erwarteten Versionen vorliegen. Prüfen Sie nicht nur, ob Builds erfolgreich sind. Ein erfolgreicher Build bedeutet nicht immer, dass die Umgebung auch wirklich funktioniert. Ein fehlender PATH-Eintrag, eine falsche Tool-Version oder eine fehlende Registry-Authentifizierung können leicht unbemerkt bleiben. Verifizieren Sie daher immer, indem Sie eine echte Devin-Sitzung ausführen.
### Phase 2: Opt-in für Org-Admins aktivieren (Verfügbar)
Sobald Sie bestätigt haben, dass Ihr Blueprint-Stack enterprise → org → repo korrekt zusammenspielt und funktionierende Umgebungen erzeugt: 1. **Intern kommunizieren** Sie gegenüber den Org-Admins, dass die deklarative Konfiguration verfügbar und einsatzbereit ist. 2. **In den Modus Available wechseln**: Ändern Sie das Dropdown „Rollout mode“ von Testing auf Available. Org-Admins im klassischen Setup sehen jetzt einen Migrationshinweis, der sie zur Migration ermutigt. 3. **Org-Admins können jetzt migrieren** ihre eigenen Organisationen. Da der Enterprise-Blueprint bereits die Basisschicht (Laufzeitumgebungen, Tools, Zertifikate, Registries) bereitstellt, müssen Org-Admins nur noch das konfigurieren, was für ihr Team und ihre Repos spezifisch ist. Jeder Org-Admin kann den **Migrationsassistenten** nutzen, um den Prozess zu vereinfachen. Devin kann den vorhandenen Snapshot der Organisation analysieren und automatisch eine äquivalente Blueprint-Konfiguration generieren. Siehe [Migration zu deklarativer Konfiguration](/de/onboard-devin/environment/migration) für den Schritt-für-Schritt-Ablauf. Erstellen Sie eine Bibliothek mit Blueprint-Vorlagen für Ihre gängigsten Tech-Stacks (Node.js, Python, Java, Go, mehrsprachige Monorepos) und teilen Sie sie intern, damit Org-Admins nicht bei null anfangen müssen. Die [Vorlagenbibliothek](/de/onboard-devin/environment/templates) ist dafür eine gute Grundlage.
### Phase 3: Ausweiten und aufräumen (Enabled by default)
1. **Enabled by default aktivieren**, sobald die meisten Orgs Blueprints verwenden. Dies ist eine dauerhafte Aktion — Orgs, die das klassische Setup mit Repos genutzt haben, erhalten automatisch klassische Überschreibungen, sodass sich für sie nichts ändert. 2. **Neue Orgs**, die ab diesem Zeitpunkt erstellt werden, starten standardmäßig mit Blueprints. 3. **Die Rollout-Seite überwachen**, um den Build-Status aller Orgs im Blick zu behalten. Nach „Classic“ filtern, um zu sehen, wer noch nicht migriert ist. 4. **Mit den verbleibenden Org-Admins zusammenarbeiten**, um die letzten Nachzügler zu migrieren. Der Migrationsassistent macht das einfach. 5. **Klassische Überschreibungen entfernen**, sobald alle Orgs auf Blueprints bestätigt sind. Die klassische Konfiguration bleibt immer erhalten. Beim Wechsel einer Org zu Blueprints wird nichts gelöscht. Falls etwas schiefgeht, können Enterprise-Admins jede Org über die Rollout-Seite mithilfe von org-spezifischen Überschreibungen wieder auf das klassische Setup zurücksetzen.
### Beschleunigte Migrationsstrategie
Für Enterprise-Kunden, die schnell umsteigen möchten, gibt es einen Ansatz, der den Migrationsaufwand pro Organisation minimiert: 1. **Im Testing-Modus beginnen** (damit jede Organisation einzeln aktiviert werden kann). 2. **Zuerst den Enterprise-Blueprint konfigurieren.** Lassen Sie Admins den Enterprise-Blueprint mit gemeinsam genutzten Runtimes, Tools, Zertifikaten und der Registry-Konfiguration einrichten. Das ist die Basisschicht, die alle Organisationen übernehmen. 3. **In den Modus „Available“ wechseln.** Dadurch wird der Migrationshinweis aktiviert, sodass Organisations-Admins auf ihrer Seite „Machine Configuration“ einen Hinweis sehen und die Migration selbst durchführen können. 4. **Dokumentation breit streuen** über die vorhandenen internen Channels (Slack, E-Mail, Wiki) und Organisations-Admins dazu ermutigen, sich selbst zu aktivieren. Der Migrationsassistent ermöglicht diesen Selbstservice für Organisations-Admins. 5. **Für Organisationen mit 0 aktuell konfigurierten Repositorys automatisch aktivieren.** Diese Organisationen haben nichts zu migrieren — der Wechsel zu Blueprints ist risikolos, da sie kein bestehendes klassisches Setup haben, das erhalten werden muss. 6. **Die verbleibenden Organisationen schrittweise nacheinander migrieren.** Wenn der Enterprise-Blueprint bereits konfiguriert ist, muss bei jeder Organisationsmigration nur noch organisationsspezifische und repo-spezifische Konfiguration ergänzt werden. Das ist deutlich einfacher, als von Grund auf zu migrieren. 7. **„Enabled by default“ aktivieren**, sobald die meisten Organisationen migriert wurden. Neue Organisationen, die nach diesem Zeitpunkt erstellt werden, starten mit aktivierten Blueprints. Bei diesem Ansatz wird die Konfiguration des Enterprise-Blueprints (die wirkungsvollste Arbeit) vorgezogen, und anschließend können einzelne Organisationen mit minimalem Aufwand in ihrem eigenen Tempo migrieren.
## Rollback
Nicht immer läuft alles reibungslos. Das Rollout-System ermöglicht Rollbacks auf jeder Ebene.
### Rollback pro Org
Enterprise-Admins können auf der Rollout-Seite jede einzelne Org wieder auf das klassische Setup zurücksetzen: * Die Org **kehrt sofort** zu ihrem Snapshot des klassischen Setups zurück. * Die klassische Konfiguration bleibt **erhalten**. Wenn eine Org zu Blueprints wechselt, geht nichts verloren, daher ist ein Zurückwechseln sicher. * Aktive Sitzungen sind nicht betroffen. Die Änderung wird in der nächsten Sitzung wirksam.
### Modus-Rollback
Enterprise-Admins können über das Dropdown-Menü für den Rollout-Modus frei zwischen **Testing** und **Available** wechseln. Das ist nützlich, wenn Sie die Self-Service-Migration pausieren möchten, während Sie ein Problem untersuchen. **Enabled by default kann** vom Enterprise-Admin nicht rückgängig gemacht werden. Wenn Sie von Enabled by default zurückkehren müssen, wenden Sie sich an Ihren Cognition-Administrator. Überschreibungen pro Organisation können weiterhin verwendet werden, um einzelne Organisationen jederzeit wieder auf das klassische Setup umzustellen. Ein Rollback löscht weder Blueprints noch klassische Konfigurationen. Beide bleiben erhalten, unabhängig davon, welcher Modus aktiv ist, sodass Sie ohne Arbeitsverlust zwischen Testing und Available wechseln können.
## Überwachung des Rollout-Status
Die Seite „Rollout“ bietet ein Dashboard zur Nachverfolgung des Migrationsfortschritts in Ihrem Unternehmen.
### KPI-Zeile
Oben auf der Seite geben zusammenfassende Metriken einen schnellen Überblick über den Rollout-Status: * **Blueprint-Organisationen**: Anzahl der Organisationen, die derzeit Blueprints nutzen * **Rollout-Prozentsatz**: Prozentsatz der Organisationen mit Blueprints an der Gesamtzahl * **Build-Status**: Aggregierter Build-Status über alle Blueprint-Organisationen hinweg
### Tabelle pro Org
Unterhalb der KPIs führt eine detaillierte Tabelle jede Organisation auf: | Column | Description | | ------------------- | ----------------------------------------------------------------------------------------- | | **Organization** | Name der Org | | **State** | Aktueller Modus: Blueprints oder Classic | | **Override** | Ob der Status der Org explizit überschrieben wird oder dem Enterprise-Standard entspricht | | **Classic repos** | Anzahl der Repos mit klassischer Setup-Konfiguration | | **Blueprint repos** | Anzahl der Repos mit Blueprints | | **Latest build** | Status des letzten Builds (erfolgreich, teilweise, fehlgeschlagen usw.) |
### Filtern
Filtern Sie die Tabelle nach: * **Alle**: Alle Orgs im Enterprise * **Blueprints**: Orgs, die derzeit Blueprints nutzen * **Classic**: Orgs, die derzeit das klassische Setup nutzen * **Überschreibungen**: Orgs mit expliziten Statusüberschreibungen (in beide Richtungen)
## Sicherheit bei gleichzeitigen Änderungen
Statusänderungen sind vor gleichzeitigen Änderungen geschützt. Wenn ein anderer Administrator den Enterprise-Status zwischen dem Laden der Seite und dem Absenden Ihrer Änderung ändert, wird die Anfrage mit einem Konfliktfehler abgelehnt. Dadurch werden versehentliche Überschreibungen verhindert, wenn mehrere Enterprise-Admins gleichzeitig Änderungen vornehmen. Wenn Ihre Änderung abgelehnt wird, aktualisieren Sie die Seite, um den aktuellen Status zu sehen, und senden Sie die Änderung gegebenenfalls erneut ab.
## Audit-Protokollierung
Alle Statuswechsel beim Rollout werden in Audit-Logs erfasst: * Änderungen am Enterprise-Modus (Testing → Verfügbar, Aktivierung von „Standardmäßig aktiviert“ usw.) * Änderungen an org-spezifischen Überschreibungen (org hat sich angemeldet, org hat sich abgemeldet, Überschreibung entfernt) * Welcher Admin die Änderung vorgenommen hat und wann Diese Logs sind über die Standardoberfläche für Audit-Logs Ihres Enterprise verfügbar.