Repository-Neustrukturierung für alle Lösungen in AEM 6.5 common-repository-restructuring-in-aem

/libs/settings/workflow/models

/conf/global/settings/workflow/models

/var/workflow/models

Alle neuen oder geänderten Workflow-Modelle müssen nach /conf/global/workflow/models migriert werden.

1. Stellen Sie die geänderten Workflow-Modelle in einer lokalen AEM 6.5-Entwicklungsinstanz bereit, sodass sie im vorherigen Speicherort vorhanden sind.

2. Bearbeiten Sie das Workflow-Modell unter Verwendung des Editors für AEM Workflow-Modelle unter „AEM“ > „Tools“ > „Workflow“ > „Modelle“.

3. Migration von modifizierten, von AEM bereitgestellten Workflow-Modellen

   1. Öffnen Sie den Editor für Workflow-Modelle, ändern Sie die Browser-URL und ersetzen Sie das Pfadsegment „/libs/settings/workflow/models“ mit „/etc/workflow/models“.
      • Ändern Sie beispielsweise: http://localhost:4502/editor.html /libs/settings/workflow/models/dam/update_asset.html in http://localhost:4502/editor.html /etc/workflow/models/dam/update_asset.html

4. Aktivieren Sie den Bearbeitungsmodus im Editor für Workflow-Modelle, wodurch die Definition des Workflow-Modells nach „/conf/global/workflow/models“ kopiert wird.

5. Wählen Sie die Synchronisierungsschaltfläche, um die Änderungen am Laufzeit-Workflow-Modell unter „/var/workflow/models“ zu synchronisieren.

6. Exportieren Sie sowohl das Workflow-Modell (https://experienceleague.adobe.com/conf/global/workflow/models/<workflow-model>?lang=de) als auch das Laufzeit-Workflow-Modell (https://experienceleague.adobe.com/var/workflow/models/<workflow-model>?lang=de) und integrieren Sie beide in das AEM-Projekt.

   1. Exportieren Sie zum Beispiel:

      • /conf/global/settings/workflow/models/dam/my_workflow_model
        und
      • /var/workflow/models/dam/my_workflow_model

Die Auflösung des Workflow-Modells geschieht in der folgenden Reihenfolge:

1. /conf/global/settings/workflow/models
2. /libs/settings/workflow/models
3. /etc/workflow/models

Daher müssen alle Anpassungen zu den von AEM bereitgestellten Workflow-Modellen, die am vorherigen Speicherort bestehen bleiben, nach „/conf/global/settings/workflow/models“ verschoben werden, wenn sie beibehalten werden sollen. Andernfalls werden sie durch die von AEM bereitgestellte Definition des Workflow-Modells in „/libs/settings/workflow/models“ ersetzt.

Für die Anpassung an den neuen Speicherort ist keine Aktion erforderlich.

Bisherige Workflow-Instanzen können weiterhin am vorherigen Speicherort erhalten bleiben und neue Workflow-Instanzen werden am neuen Speicherort erstellt.

Alle expliziten Pfadverweise in custom -Code zum vorherigen Speicherort sollten auch den neuen Speicherort berücksichtigen. Es wird empfohlen, diesen Code so umzugestalten, dass er die AEM-Workflow-APIs verwendet.

/libs/settings/workflow/launcher/config

/conf/global/settings/workflow/launcher/config

Jeder neue oder modifizierte Workflow-Starter muss nach /conf/global/workflow/launcher/config migriert werden.

1. Kopieren Sie alle neuen oder geänderten Workflow-Starter Konfigurationen vom bisherigen Speicherort an den neuen Speicherort (/conf/global).

Die Auflösung des Workflow-Starters geschieht in der folgenden Reihenfolge:

1. /conf/global/settings/workflow/launcher
2. /libs/settings/workflow/launcher
3. /etc/workflow/launcher

Daher müssen alle Anpassungen zu von AEM bereitgestellten Workflow-Startern, die am vorherigen Speicherort bestehen bleiben, an den neuen Speicherort (/conf/global/settings/workflow/launcher) verschoben werden, wenn sie beibehalten werden sollen. Andernfalls werden sie durch die von AEM bereitgestellte Definition des Workflow-Starters in /libs/settings/workflow/launcher ersetzt.

/libs/workflow/scripts

/apps/workflow/scripts

Alle neuen oder geänderten Workflow-Skripte müssen an den neuen Speicherort migriert werden, und die verweisenden Workflow-Modelle müssen so aktualisiert werden, dass sie den neuen Speicherort berücksichtigen.

1. Kopieren Sie jedes neue oder modifizierte Workflow-Skript vom vorherigen Speicherort zum neuen Speicherort.
   • /apps/workflow/scripts sollte in SCM gepflegt werden.
2. Aktualisieren Sie alle Verweise auf die Workflow-Skripte in den Workflow-Modellen am vorherigen Speicherort, sodass sie auf die neuen Speicherorte verweisen.

Nach der Veröffentlichung von AEM 6.4 SP1 ist es möglich, die Restrukturierung bis Version 6.5 zu verschieben upgrade .

Wenn Sie auf AEM 6.4 aktualisieren möchten, bevor AEM 6.4 SP1 veröffentlicht wurde, sollte diese Neustrukturierung als Teil der Aktualisierung ausgeführt werden. Tun Sie dies nicht, wird der Workflow-Skript-Verweis durch das Bearbeiten und Abspeichern von Workflow-Schritten, die auf Skripte am vorherigen Speicherort verweisen, vollständig aus dem Workflow-Schritt entfernt und nur die Workflow-Skripte an neuen Speicherorten sind in der Dropdown-Liste „Skriptauswahl“ verfügbar.

/libs/settings/cloudsettings

/conf/global/settings/cloudsettings

/conf/<tenant>/settings/cloudsettings

Alle neuen oder modifizierten ContextHub-Konfigurationen müssen an den neuen Speicherort migriert werden, und die verweisenden AEM Sites-Seiten müssen so aktualisiert werden, dass sie den neuen Speicherort berücksichtigen.

1. Kopieren Sie alle neuen oder modifizierten ContextHub-Konfigurationen vom vorherigen Speicherort zum neuen Speicherort.
2. Verknüpfen Sie die entsprechenden AEM-Konfigurationen mit den AEM-Inhaltshierarchien.
   1. Die Seitenhierarchien von AEM Sites über AEM Sites > Seite > Seiteneigenschaften > Erweitert > Cloud-Konfiguration.
3. Trennen Sie alle migrierten ContextHub-Konfigurationen von den oben aufgeführten AEM-Inhaltshierarchien.

Nicht zutreffend

/libs/settings/wcm/designs/cloudservices

/apps/settings/wcm/designs/cloudservices

Für alle Designs, die in SCM verwaltet werden und in die nicht zur Laufzeit über Design-Dialogfelder geschrieben wird.

1. Kopieren Sie die Designs vom bisherigen Speicherort an den neuen Speicherort (/apps).
2. Wandeln Sie die gesamten CSS-, JavaScript- und statischen Ressourcen im Design in eine Client-Bibliothek mit allowProxy = true um.
3. Aktualisieren Sie Verweise auf den vorherigen Speicherort in der Eigenschaft cq : designPath .
4. Aktualisieren Sie alle Seiten, die auf den vorherigen Speicherort verweisen, sodass sie die neue Kategorie der Client-Bibliothek verwenden (dies erfordert auf der Seite eine Aktualisierung des Implementierungs-Codes).
5. Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen.

Für alle Designs, die NICHT in SCM verwaltet werden und die über Design-Dialogfelder zur Laufzeit angepasst werden.

• Entfernen Sie keine bearbeitbaren Designs aus /etc.

Nicht zutreffend

/libs/settings/wcm/designs/dashboards

/apps/settings/wcm/designs/dashboards

Für alle Designs, die in SCM verwaltet werden und in die nicht zur Laufzeit über Design-Dialogfelder geschrieben wird.

1. Kopieren Sie die Designs vom vorherigen Speicherort an den neuen Speicherort (https://experienceleague.adobe.com/apps?lang=de).
2. Wandeln Sie die gesamten CSS-, JavaScript- und statischen Ressourcen im Design in eine Client-Bibliothek mit allowProxy = true um.
3. Aktualisieren Sie Verweise auf den vorherigen Speicherort in der Eigenschaft cq : designPath .
4. Aktualisieren Sie alle Seiten, die auf den vorherigen Speicherort verweisen, sodass sie die neue Kategorie der Client-Bibliothek verwenden (dies erfordert auf der Seite eine Aktualisierung des Implementierungs-Codes).
5. Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen.

Für alle Designs, die NICHT in SCM verwaltet werden und die über Design-Dialogfelder zur Laufzeit angepasst werden.

• Entfernen Sie keine bearbeitbaren Designs aus /etc.

Nicht zutreffend

/libs/settings/wcm/designs/reports

/apps/settings/wcm/designs/reports

Für alle Designs, die in SCM verwaltet werden und in die nicht zur Laufzeit über Design-Dialogfelder geschrieben wird.

1. Kopieren Sie die Designs vom vorherigen Speicherort an den neuen Speicherort (https://experienceleague.adobe.com/apps?lang=de).
2. Wandeln Sie die gesamten CSS-, JavaScript- und statischen Ressourcen im Design in eine Client-Bibliothek mit allowProxy = true um.
3. Aktualisieren Sie Verweise auf den vorherigen Speicherort in der Eigenschaft cq : designPath .
4. Aktualisieren Sie alle Seiten, die auf den vorherigen Speicherort verweisen, sodass sie die neue Kategorie der Client-Bibliothek verwenden (dies erfordert auf der Seite eine Aktualisierung des Implementierungs-Codes).
5. Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen.

Für alle Designs, die NICHT in SCM verwaltet werden und die über Design-Dialogfelder zur Laufzeit angepasst werden.

• Entfernen Sie keine bearbeitbaren Designs aus /etc.

Nicht zutreffend

/libs/settings/wcm/designs/default

/apps/settings/wcm/designs/default

Für alle Designs, die in SCM verwaltet werden und in die nicht zur Laufzeit über Design-Dialogfelder geschrieben wird.

1. Kopieren Sie die Designs vom vorherigen Speicherort an den neuen Speicherort (https://experienceleague.adobe.com/apps?lang=de).
2. Wandeln Sie die gesamten CSS-, JavaScript- und statischen Ressourcen im Design in eine Client-Bibliothek mit allowProxy = true um.
3. Aktualisieren Sie Verweise auf den vorherigen Speicherort in der Eigenschaft cq : designPath .
4. Aktualisieren Sie alle Seiten, die auf den vorherigen Speicherort verweisen, sodass sie die neue Kategorie der Client-Bibliothek verwenden (dies erfordert auf der Seite eine Aktualisierung des Implementierungs-Codes).
5. Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen.

Für alle Designs, die NICHT in SCM verwaltet werden und die über Design-Dialogfelder zur Laufzeit angepasst werden.

• Entfernen Sie keine bearbeitbaren Designs aus /etc.

Nicht zutreffend

Keine Aktion erforderlich.

Der vorherige öffentliche Speicherort fungiert als Proxy-Endpunkt für den privaten neuen Speicherort.

Nicht zutreffend

Keine Aktion erforderlich.

Der vorherige öffentliche Speicherort fungiert als Proxy-Endpunkt für den privaten neuen Speicherort.

Nicht zutreffend

Verwenden Sie die Wartungsaufgabe zum Bereinigen des Posteingangs, um alte Aufgaben vom vorherigen Speicherort zu entfernen.

Für die Migration von Aufgaben an den neuen Speicherort sind keine Maßnahmen erforderlich.

• Aufgaben, die am vorherigen Speicherort vorhanden sind, sind weiterhin verfügbar und funktionieren.
• Neue Aufgaben werden am neuen Speicherort erstellt.

/libs/msm

/apps/msm

1. Kopieren Sie benutzerdefinierte Konfigurationen von /etc/blueprints nach /apps/msm.
2. Remove /etc/blueprints.

Nicht zutreffend

/libs/cq/core/content/projects/dashboard/gadgets

/apps/cq/core/content/projects/dashboard/gadgets

Alle neuen oder modifizierten Dashboard-Gadget-Konfigurationen für AEM-Projekte müssen an den neuen Speicherort (/apps) migriert werden.

1. Kopieren Sie alle neuen oder modifizierten Dashboard-Gadget-Konfigurationen für AEM-Projekte vom vorherigen an den neuen Speicherort (/apps).
   1. Kopieren Sie keine unmodifizierten Dashboard-Gadget-Konfigurationen für AEM-Projekte, da diese bereits am neuen Speicherort (/libs) existieren.
2. Aktualisieren Sie alle AEM-Projektvorlagen, die auf den vorherigen Speicherort verweisen, sodass sie auf den neuen Speicherort verweisen.

Wenn das AEM 6.4-Kompatibilitätspaket verwendet wird, muss die Anpassung des Repositorys zum Zeitpunkt der Entfernung des Kompatibilitätspakets durchgeführt werden.

/libs/settings/notification-templates/com.day.cq.replication

/apps/settings/notification-templates/com.day.cq.replication

Alle neuen oder modifizierten E-Mail-Vorlagen für die Replikationsbenachrichtigung müssen an den neuen Speicherort (/apps) migriert werden.

1. Kopieren Sie alle neuen oder modifizierten E-Mail-Vorlagen für die Replikationsbenachrichtigung vom vorherigen Speicherort an den neuen Speicherort (/apps).
2. Entfernen Sie alle migrierten E-Mail-Vorlagen für die Replikationsbenachrichtigung vom vorherigen Speicherort.

Die einzigen neuen unterstützten E-Mail-Vorlagen für die Replikationsbenachrichtigung sind solche, die neue Gebietsschemata unterstützen.

Die Auflösung für die E-Mail-Vorlage für die Replikationsbenachrichtigung geschieht in der folgenden Reihenfolge:

1. /etc/notification/email/default/com.day.cq.replication
2. /apps/settings/notification-templates/com.day.cq.replication
3. /libs/settings/notification-templates/com.day.cq.replication

Alle Tags müssen nach /content/cq:tags migriert werden.

1. Kopieren Sie alle Tags vom vorherigen Speicherort an den neuen Speicherort.
2. Entfernen Sie alle Tags aus dem vorherigen Speicherort.
3. Über die AEM-Web-Konsole erfolgt der Neustart des Day Communique 5 Tagging OSGi-Bundles unter https://serveradresse:serverport/system/console/bundles/com.day.cq.cq-tagging, damit AEM erkennt, dass der neue Speicherort Inhalt enthält und verwendet werden sollte.

Beim Neustart des Day Communique Tagging OSGi-Bundles wird der neue Speicherort nur dann als Tag-Stammverzeichnis registriert, wenn der vorherige Speicherort leer ist.

Verweise auf den vorherigen Speicherort funktionieren auch nach der Migration zum neuen Speicherort für alle Funktionen, die TagManager-API von AEM für die Tag-Auflösung verwenden.

Jeder benutzerspezifische Code, der explizit auf den Pfad

/etc/tags

verweist, muss aktualisiert werden auf /content/

cq

:tags

oder vorzugsweise so umgeschrieben werden, dass die TagManager Java-API gemeinsam mit dieser Migration verwendet wird.

/libs/settings/cloudconfigs/translation/translationcfg

/apps/settings/cloudconfigs/translation/translationcfg

/conf/global/settings/cloudconfigs/translation/translationcfg

/conf/<tenant>/settings/cloudconfigs/translation/translationcfg

Alle neuen Cloud-basierten Übersetzungsdienste müssen an den neuen Speicherort (/conf/global,/apps oder /conf/<tenant>) migriert werden.

1. Migrieren Sie vorhandene Konfigurationen im bisherigen Speicherort zum neuen Speicherort.

   • Erstellen Sie manuell neue Konfigurationen der Cloud-basierten Übersetzungsdienste über die AEM-Benutzeroberfläche unter Tools > Cloud-Dienste > Cloud-basierte Übersetzungsdienste.
     ODER
   • Kopieren Sie alle neuen Konfigurationen für Cloud-basierte Übersetzungsdienste vom vorherigen Speicherort an den neuen Speicherort (/conf/global,/apps oder /conf/<tenant>).

2. Verknüpfen Sie die entsprechenden AEM-Konfigurationen mit den AEM-Inhaltshierarchien.

   1. Die Seitenhierarchien von AEM Sites über AEM Sites > Seite > Seiteneigenschaften > Registerkarte „Erweitert“ > Cloud-Konfiguration.
   2. Hierarchien von AEM-Experience Fragments über AEM Experience Fragments > Experience Fragments > Eigenschaften > Registerkarte „Cloud-Services“ > Cloud-Konfiguration.
   3. Ordnerhierarchien von AEM-Experience Fragments über AEM Experience Fragments > Ordner > Eigenschaften > Registerkarte „Cloud-Services“ > Cloud-Konfiguration.
   4. Ordnerhierarchien von AEM Assets über AEM Assets > Ordner > Ordnereigenschaften > Cloud-Services > Konfiguration.
   5. AEM-Projekte über AEM-Projekte > Projekt > Projekteigenschaften > Erweitert > Cloud-Konfiguration.

3. Trennen Sie alle migrierten alten Cloud-basierten Übersetzungsdienste von den oben genannten AEM-Inhaltshierarchien.

Die Auflösung der Cloud-basierten Übersetzungsdienste geschieht in der folgenden Reihenfolge:

1. /conf/<tenant>/settings/cloudconfigs/translations/translationcfg
2. /conf/global/settings/cloudconfigs/translations/translationcfg
3. /apps/settings/cloudconfigs/translations/translationcfg
4. /libs/settings/cloudconfigs/translations/translationcfg

Migrierte Cloud-basierte Übersetzungsdienste müssen mit AEM 6.4 kompatibel sein.

/libs/settings/translation/supportedLanguages

/apps/settings/translation/supportedLanguages

Alle neuen oder modifizierten Definitionen für Übersetzungssprachen erfordern eine Migration der Definitionen für Übersetzungssprachen an den neuen Speicherort (/apps).

1. Falls Ergänzungen oder Modifikationen an den Definitionen für Übersetzungssprachen vorgenommen wurden, sollten Sie alle Definitionen für Übersetzungssprachen vom vorherigen Speicherort an den neuen Speicherort (/apps) kopieren.

Die Auflösung des Pfads für Übersetzungssprachen geschieht in der folgenden Reihenfolge:

1. /etc/translation/supportedLanguages
2. /apps/settings/translation/supportedLanguage
3. /libs/settings/translation/supportedLanguages

Diese Lösung unterstützt kein Zusammenführen von Überlagerungen, der aufgelöste Pfad muss also alle unterstützten Sprachen enthalten und übernimmt keine unterstützten Sprachen von übergeordneten Auflösungen.

/libs/settings/translation/rules/translation_rules.xml

/apps/settings/translation/rules/translation_rules.xml

/conf/global/settings/translation/rules/translation_rules.xml

Eine modifizierte XML-Datei für Übersetzungsregeln muss an den neuen Speicherort (/apps oder /conf/global) migriert werden.

1. Kopieren Sie die modifizierte XML-Datei für Übersetzungsregeln vom bisherigen Speicherort an den neuen Speicherort.

Die XML-Auflösung der Replikation der Übersetzungsregeln geschieht in der folgenden Reihenfolge:

1. /conf/global/settings/translation/rules/translation_rules.xml
2. /apps/settings/translation/rules/translation_rules.xml
3. /etc/workflow/models/translation/translation_rules.xml
4. /libs/settings/translation/rules/translation_rules.xml

/libs/settings/wcm/designs/translation/translationwidget

/apps/settings/wcm/designs/translation/translationwidget

Für alle Designs, die in SCM verwaltet werden und in die nicht zur Laufzeit über Design-Dialogfelder geschrieben wird.

1. Kopieren Sie die Designs vom vorherigen Speicherort an den neuen Speicherort (https://experienceleague.adobe.com/apps?lang=de).
2. Wandeln Sie die gesamten CSS-, JavaScript- und statischen Ressourcen im Design in eine Client-Bibliothek mit allowProxy = true um.
3. Aktualisieren Sie Verweise auf den vorherigen Speicherort in der Eigenschaft cq : designPath .
4. Aktualisieren Sie alle Seiten, die auf den vorherigen Speicherort verweisen, sodass sie die neue Kategorie der Client-Bibliothek verwenden (dies erfordert auf der Seite eine Aktualisierung des Implementierungs-Codes).
5. Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen.

Für alle Designs, die NICHT in SCM verwaltet werden und die über Design-Dialogfelder zur Laufzeit angepasst werden.

• Entfernen Sie keine bearbeitbaren Designs aus /etc.

Nicht zutreffend

/libs/settings/cloudconfigs/translation/<vendor>

/apps/settings/cloudconfigs/translation/<vendor>

/conf/global/settings/cloudconfigs/translation/<vendor>

/conf/<tenant>/settings/cloudconfigs/translation/<vendor>

Alle neuen Connector-Cloud-Services für Übersetzungsanbieter müssen an den neuen Speicherort (/conf/global,/apps oder /conf/<tenant>) migriert werden.

1. Migrieren Sie vorhandene Konfigurationen im bisherigen Speicherort zum neuen Speicherort.

   • Erstellen Sie manuell neue Konfigurationen der Connector-Cloud-Services für Übersetzungsanbieter über die  AEM-Authoring-Benutzeroberfläche unter „Tools“ > „Cloud-Dienste“ > „Cloud-basierte Übersetzungsdienste“.
     ODER
   • Kopieren Sie alle neuen Konfigurationen für Connector-Cloud-Services für Übersetzungsanbieter vom vorherigen Speicherort an den neuen Speicherort (/conf/global , /apps oder /conf/<tenant>).

2. Verknüpfen Sie die entsprechenden AEM-Konfigurationen mit den AEM-Inhaltshierarchien.

   1. Die Seitenhierarchien von AEM Sites über AEM Sites > Seite > Seiteneigenschaften > Registerkarte „Erweitert“ > Cloud-Konfiguration.
   2. Hierarchien von AEM-Experience Fragments über AEM Experience Fragments > Experience Fragments > Eigenschaften > Registerkarte „Cloud-Services“ > Cloud-Konfiguration.
   3. Ordnerhierarchien von AEM-Experience Fragments über AEM Experience Fragments > Ordner > Eigenschaften > Registerkarte „Cloud-Services“ > Cloud-Konfiguration.
   4. Ordnerhierarchien von AEM Assets über AEM Assets > Ordner > Ordnereigenschaften > Cloud-Services > Konfiguration.
   5. AEM-Projekte über AEM-Projekte > Projekt > Projekteigenschaften > Erweitert > Cloud-Konfiguration.

3. Trennen Sie alle migrierten alten Cloud-basierten Übersetzungsdienste von den oben genannten AEM-Inhaltshierarchien.

Die Auflösung der Cloud-basierten Übersetzungsdienste geschieht in der folgenden Reihenfolge:

1. /conf/<tenant>/settings/cloudconfigs/translations/<vendor>
2. /conf/global/settings/cloudconfigs/translations/<vendor>
3. /apps/settings/cloudconfigs/translations/<vendor>
4. /libs/settings/cloudconfigs/translations/<vendor>

/libs/settings/workflow/notification

/conf/global/settings/workflow/notification

Alle modifizierten E-Mail-Vorlagen für Workflow-Benachrichtigungen müssen an den neuen Speicherort (/conf/global) migriert werden.

1. Kopieren Sie alle modifizierten E-Mail-Vorlagen für die Workflow-Benachrichtigung vom bisherigen Speicherort an den neuen Speicherort.
2. Entfernen Sie migrierte E-Mail-Vorlagen für die Workflow-Benachrichtigung vom vorherigen Speicherort.

Die Auflösung für die E-Mail-Vorlage für die Workflow-Benachrichtigung geschieht in der folgenden Reihenfolge:

1. /etc/workflow/notification
2. /conf/global/settings/workflow/notification
3. /libs/settings/workflow/notification

Bestehende Workflow-Pakete sollten vom vorherigen Speicherort an den neuen Speicherort migriert werden.

1. Entfernen Sie alle Workflow-Pakete vom vorherigen Speicherort, die nicht durch andere Inhalte referenziert werden und auch sonst nicht benötigt werden.
2. Verschieben Sie alle Workflow-Pakete an den vorherigen Speicherort, die nicht durch andere Inhalte referenziert werden, aber am neuen Speicherort benötigt werden.
3. Belassen Sie alle Workflow-Pakete, die durch andere Inhalte referenziert werden, am vorherigen Speicherort.

Workflow-Pakete, die über die Miscadmin-Konsole in der klassischen Benutzeroberfläche erstellt wurden, verbleiben am vorherigen Speicherort, während alle anderen am neuen Speicherort gespeichert werden.

Die Workflow-Pakete, die entweder am vorherigen oder am neuen Speicherort gespeichert sind, können über die Miscadmin-Konsole in der klassischen Benutzeroberfläche verwaltet werden.