Auswerten und Genehmigen des Experience Modernization Agent evaluate
Diese Seite richtet sich an die Person, die den Experience Modernization Agent für ein Team genehmigt, das Adobe Experience Manager-Sites in Edge Delivery Services erstellt oder migriert: eine Architektin, eine technische Leiterin oder ein Plattformbesitzer, die den Agenten nie persönlich verwenden darf. In diesem Abschnitt wird erläutert, welche Änderungen sich für Ihr Team ergeben, wie eine Migration durchgeführt wird, wie das Adobe-Team mit Ihrem Team zusammenarbeitet, welche Systeme und Daten der Agent berührt, wie Änderungen kontrolliert und nachverfolgt werden und was bei der Projektarbeit verbleibt.
Informationen dazu, was Edge Delivery Services ist und wie ein Projekt zusammenpasst, finden Sie unter So wird Ihre Site erstellt und aktualisiert. Ein Ergebnis auf Ihren eigenen Seiten sagt Ihnen mehr als jede Beschreibung. Bitten Sie daher ein Team-Mitglied, beim Lesen mit dem -Modus zu beginnen oder eine Seite Schritt für zu importieren.
Änderungen für Ihr Team team-impact
Ohne den Agenten beginnt die Migration zu Edge Delivery Services mit wochenlanger Entwicklerarbeit, bevor irgendjemand das Ergebnis beurteilen kann: die Quellseiten auflisten, sie nach Layout gruppieren, ihren Inhalt Blöcken zuordnen, Blockcode und Stile schreiben und Importskripte schreiben. Der Agent erledigt diese sich wiederholende Arbeit mit Ihrem Team in einer gehosteten Umgebung, die nicht installiert werden muss.
- Ihr Team entscheidet und prüft; der Agent produziert. Die Personen legen den Umfang, das Inhaltsmodell, das Zieldesign und die Integrationen fest und akzeptieren das Ergebnis. Der Agent schreibt den Code, importiert den Inhalt und vergleicht das Ergebnis mit der Quelle.
- Weitere Personen leisten direkte Beiträge. Designer, Inhaltsspezialisten und Marketing-Experten, die einige HTML und die Grundlagen von Git kennen, nehmen Änderungen vor, indem sie sie in einfacher Sprache beschreiben. Entwickler behalten die Kontrolle darüber, was die Produktion erreicht, indem sie diese Änderungen als Pull-Anforderungen überprüfen. Siehe Größerer Beitrag, gleiche Produktionskontrolle.
- Der Aufwand steigt mit Layouts, nicht mit Seiten. Durch eine Korrektur wird ein wiederverwendbarer Block oder ein Importskript anstelle einer Seite geändert, sodass sie auf jede Seite desselben Layouts angewendet wird. Eine Site mit 5.000 Seiten, die 12 Layouts gemeinsam haben, ist hauptsächlich die Arbeit von 12 Vorlagen. Siehe Migration des Agenten in großem Maßstab und " vor Bestätigung“, um die Arbeit aus den ersten Vorlagen zu .
- Das Ergebnis ist ein Standardprojekt. Der Code besteht aus HTML, CSS und JavaScript in Ihrem Git-Repository und folgt den Konventionen des AEM-Textbausteins. Die Site ist zur Laufzeit nicht vom Agenten abhängig, und Entwickler können in ihrem eigenen Editor oder mit anderen KI-Tools fortfahren.
- Projektwissen verbleibt im Repository. Die Konventionen, die Ihr Team für Live-
AGENTS.mdund zugehörige Dateien vereinbart, denen der Agent und neue Team-Mitglieder folgen. Siehe Projektanweisungen und -speicher.
Was der Agent tut und was Ihr Team tut responsibilities
Informationen zur Koordinierung der Mitwirkenden durch den Migrationsleiter finden Sie unter Lead der Migration. Mehrere Personen können an einem Projekt arbeiten, jeweils in ihrem eigenen Konsolenarbeitsbereich. Siehe Arbeiten als Team.
Was an Projektarbeit verbleibt project-work
Der Agent ist ein Entwicklungs-Agent: Was auf Edge Delivery Services erstellt werden kann, kann damit erstellt werden. Bei einer Migration wird jedoch kopiert, was die Quellseiten zeigen, nicht die Systeme dahinter. Der Agent erstellt die Site neu: seine Seiten, Blöcke, Stile und den Code, der Ihre Services aufruft. Genehmigungs- und Veröffentlichungs-Workflows, die Backend-Systeme hinter Integrationen und die Art und Weise, wie Ihre Teams auf der neuen Site arbeiten, bleiben die Arbeit Ihres Unternehmens. Diese Anforderungen erfordern eine Entscheidung Ihres Teams, bevor der Agent sie erstellen kann:
Informationen zum Quellzugriff, zu interaktiven Inhalten und anderen Begrenzungen des Imports finden Sie unter Einschränkungen.
Figma und Designsysteme figma
Figma kann die Quelle eines neuen Designs sein. Mit dem Figma-Import-Add-on liest der Agent die ausgewählte Komponente oder den ausgewählten Frame über die Figma-API mithilfe eines MCP-Servers (Model Context Protocol) und auf dieselbe Weise, wie ein Entwickler ein Design-Handoff liest. Die Variablen und Stile des Designs, wie Farben, Typografie und Abstände, werden als benutzerdefinierte CSS-Eigenschaften in die globalen Stile des Projekts geschrieben. Diese Eigenschaften sind die Design-Token der Site. Sie befinden sich im Code, nicht in einem separaten Token-Export, sodass Designer und Entwickler sie wie jede andere Änderung überprüfen können. Wie Designer von Figma mit dem Agenten arbeiten, erfahren Sie unter Arbeiten von einem Figma Design.
Zu genehmigende Elemente:
- Zugriff: Jede Person, die Figma mit dem Agenten verwendet, erstellt ein persönliches Figma-Zugriffstoken mit schreibgeschützten Bereichen und speichert es in den der Konsole. FIGMA gibt dieses Zugriffstoken heraus und steuert es, was nichts mit Design-Token zu tun hat. Es gibt keine organisationsweite Figma-Verbindung und ein persönliches Zugriffstoken kann nicht auf bestimmte Dateien beschränkt werden: Es liest jede Datei, die der Besitzer öffnen kann.
- Lizenzen und Ratenbeschränkungen: Figma beschränkt, wie oft ein Token Dateien lesen kann, basierend auf dem Sitzplatz des Tokenbesitzers und dem Plan, dem die Datei gehört. Bei einem View- oder Collab-Sitz kann ein Token Dateien nur wenige Male im Monat über die Figma-API lesen, sodass Personen, die Figma mit dem Agenten verwenden, einen Dev- oder Full-Seat benötigen. Siehe die "" der Figma.
- Daten: Für den ausgewählten Rahmen oder die ausgewählte Komponente sendet der Agent seine Struktur, einen Screenshot, seine Variablen und seinen Text an das KI-Modell. Siehe Was das KI-Modell verarbeitet.
Auswählen, wie die Migration ausgeführt wird approaches
Derselbe Agent kann eine Migration auf drei Arten ausführen. Sie unterscheiden sich darin, wer den Agenten steuert und wer für das Ergebnis verantwortlich ist. Alle drei erstellen ein standardmäßiges Edge Delivery Services-Projekt mit Code in einem Git-Repository und Inhalten, die von Autorinnen und Autoren bearbeitet werden, sodass Sie von einem zum nächsten wechseln können: Übertragen Sie ein Auto-Modus-Ergebnis auf Ihre eigene Site und fahren Sie in der Konsole fort oder setzen Sie den Agenten nach einem Interview mit den Agentic Outcome Engineers selbst fort.
Das Team hinter dem Agenten adobe-team
Wenn Sie den Agenten auswählen, wählen Sie auch das Team aus, das ihn erstellt, und die Richtung, in die er geht. Die Art und Weise, wie Menschen im Internet Informationen finden, ändert sich: Mehr von ihnen fragen einen KI-Assistenten, der auf dem antwortet, was er auf der eigenen Website der Marke liest. Ein Agent kann den Inhalt, das Design und den Code einer Site gemeinsam ändern, sodass eine Änderung, die einmal erforderlich war, ein Projekt Stunden dauern kann. Die Mission des Teams besteht darin, Ihnen beim Umzug nach Edge Delivery Services zu helfen, Experience Manager optimal zu nutzen und mit agenten Entwicklungs-Tools Sites zu erstellen, die im Laufe dieser Veränderungen relevant bleiben. Die Zusammenarbeit mit Ihnen endet nicht mit der Migration, und der Agent ändert sich weiter. In den Versionshinweisen wird jede Änderung aufgeführt.
Wenn Änderungen billig sind, besteht die Schwierigkeit darin, zu entscheiden, was geändert werden soll, es zu regulieren und dem Agenten die richtige Marke, das richtige Design und den richtigen Geschäftskontext zu geben. Dieses Wissen liegt bei Ihren Teams und Systemen. Das Adobe-Team hilft Ihnen, die Verbindung zur -Plattform herzustellen:
- Ingenieure, die die Migration mit Ihnen durchführen können. Für eine komplexe Migration können die Agentenergebnisingenieure von Adobe den Agenten mit Ihrem Team betreiben und die Site an das Team übergeben. Siehe Auswählen, wie die Migration ausgeführt wird.
- Aktuell, wenn sich das Produkt ändert. Der Hinweis Neue Funktionen“ der Konsole die Highlights der einzelnen Versionen auf. Um eine Änderung auf Ihre eigene Site anzuwenden, Ihre Architektur zu überprüfen oder einen Bedarf zu besprechen, den der Agent noch nicht erfüllt, bitten Sie Ihren Adobe Customer Success Manager oder Ihr Account Team um ein Treffen mit Fachleuten und dem Produkt-Team.
- Ihre Erfahrung formt das Produkt. Das Produkt-Team tauscht Fachwissen mit Kunden und Partnern aus und arbeitet mit einigen von ihnen an neuen Funktionen. Was Sie melden, fließt in die Korrekturen und Builds des Teams ein.
Um das Team über die Konsole zu erreichen, verwenden Sie Support anfragen oder Hilfe anfordern auf den Seiten für den Automatikmodus. Ihre Nachricht wird direkt an das Team weitergeleitet, das den Agenten erstellt. Das Team schaut nach und erhält die Nachricht per E-Mail. Siehe Support anfordern und, was eine Anfrage teilt, Support-Anfragen.
Das Adobe-Team arbeitet auf die gleiche Weise mit Implementierungspartnern zusammen, sodass sich die Site nach der Migration gemeinsam mit Ihrem Partner weiter verbessert.
Systeme und Datenfluss systems
Der Agent arbeitet in einer gehosteten Umgebung und erreicht Ihre Systeme nur über Verbindungen, die von Benutzern eingerichtet werden, und über von ihnen erteilte Berechtigungen.
aemcoder.adobe.io, an der Personen mit dem Agenten arbeiten.aem.page und die Live-Site auf aem.live.Sicherheit und Datenverarbeitung security
In der Konsole kann der Agent auf Ihrer Site arbeiten, ohne ihm die von Ihnen konfigurierten Anmeldeinformationen zu geben, und Sie entscheiden, wann Änderungen Ihr Git-Repository und Ihr Inhaltsziel erreichen.
Zugriff und Isolierung security-access
- Sie müssen sich mit Ihrer Adobe ID bei der Konsole anmelden. Jede Anfrage wird mit Adobe Identity Management Services (IMS) authentifiziert.
- Jeder Anwender arbeitet in einer separaten Backend-Umgebung mit eigenem Arbeitsbereichsspeicher, einem in jeder Adobe-Organisation, bei der er sich anmeldet. Die Konsole erstellt die Umgebung, wenn sich der Benutzer zum ersten Mal anmeldet, und setzt sie aus, wenn sie inaktiv ist.
- Die Konsole hat keine Projektrollen. Jeder, der Zugriff hat, kann den Agenten um jede Änderung an seinem eigenen Arbeitsbereich bitten. Experience Manager und Ihr Git-Anbieter erzwingen weiterhin ihre eigenen Berechtigungen für Code oder Inhalte, die den Arbeitsbereich verlassen.
Credentials security-credentials
- Der KI-Agent erhält nicht die Anmeldeinformationen, die Sie in der Konsole konfigurieren. Token für GitHub, Cloud Manager-Git-Repositorys, Experience Workspace, Figma und geschützte Quell-Sites befinden sich außerhalb der Umgebung des Agenten. Eine separate Komponente fügt jede Berechtigung nur zu Anfragen für den Service hinzu, zu dem sie gehört. Dasselbe gilt für die Berechtigung, die zum Aufrufen des KI-Modells verwendet wird.
- Die Anmeldeinformationen gehören dem Benutzer, der sie konfiguriert, nicht dem Projekt. Jedes Teammitglied verbindet sein eigenes Git-Konto und speichert sein eigenes Figma-Token.
- Agentenberechtigungen sind deaktiviert, bis Sie sie aktivieren. Durch die Aktivierung dieser Option kann der Agent mit diesem Zugriff agieren, z. B. um einen Push an Ihr Repository zu senden, ohne die Berechtigung zu sehen. Standardmäßig verwendet eine Berechtigung das eigene Anmelden des Benutzers. Geben Sie zur Eingrenzung der Reichweite des Agenten stattdessen ein Token für ihn ein: ein detailliertes persönliches Zugriffstoken für die benötigten Repositorys oder das Token eines Adobe-Service-Kontos.
- Andere Services, die der Agent während der Ausführung aufruft, z. B. eine Test-API, erhalten ihre Anmeldeinformationen auf die gleiche Weise aus einem Eintrag unter Authentifizierung einer geschützten Site für den Hostnamen des Services. Siehe Anmeldedaten für andere Services.
- Anmeldeinformationen nur in den Einstellungen der Konsole speichern, niemals in Eingabeaufforderungen, Chats, Quellinhalten oder Projektdateien: Der Agent liest diese und kann sie an das KI-Modell senden. Machen Sie dies zum Teil des Onboarding, da Personen, die noch nicht mit Kodieragenten vertraut sind, ein Passwort oder einen Schlüssel in den Chat einfügen können, um eine Aufgabe zu erledigen. Bitten Sie alle, die die Konsole verwenden, zuerst " aus dem Chat zu lesen und ihnen mitzuteilen, welche Richtlinie Ihrer Organisation es ihnen erlaubt, mit KI-Tools zu teilen.
Prozessabläufe des KI-Modells security-model-data
Um Ihre Anfrage auszuführen, kann der Agent Folgendes an das von ihm verwendete Large Language Model (LLM) senden, derzeit ein Claude-Modell:
- Ihre Eingabeaufforderungen und Anweisungen.
- Seiten-URLs, Markup und Inhalte von Source oder exportierte CMS-Inhalte.
- Repository-Code und -Konfiguration wie Blöcke, Stile und Site-Konfiguration.
- Design- und Markenreferenzen, wie Figma-Designs und Screenshots.
- Erstellter Inhalt und Code wird überprüft.
Adobe verwendet Ihre Konversationen oder andere Kundendaten nicht zum Trainieren oder Optimieren von KI-Modellen.
Kontrolle über Änderungen security-control
Der Agent funktioniert in Ihrem Konsolenarbeitsbereich, in dem Sie die Änderungen überprüfen und die Vorschau anzeigen. Die Arbeit erreicht Ihre Site in separaten Schritten, und jeder Schritt hat seine eigene Kontrolle:
- Die eigenen Prüfungen der Konsole sind Sicherheitsmaßnahmen, keine Genehmigungs-Gates. Der optionale Planmodus ermöglicht die Genehmigung eines Plans vor dem Start des Agenten. Die Konsole verhindert auch das Hochladen, Anzeigen einer Vorschau oder Veröffentlichen durch den Agenten, es sei denn, Ihre aktuelle Nachricht fordert dazu auf oder Sie stimmen zu, wenn der Agent dies verlangt, aber sie kann nicht alle Möglichkeiten erkennen, eine solche Anfrage zu stellen. Keine dieser Prüfungen verhindert, dass eine Person mit Zugriff Push- oder Veröffentlichungsaktivitäten ausführt.
- Mit der Git-Berechtigung kann der Agent an jede Verzweigung übertragen, in die Ihre Anmeldeinformationen schreiben können, einschließlich
main. Eine Push-Benachrichtigung anmainändert den Code der Live-Site. - Um eine Überprüfung zu verlangen, erzwingen Sie sie an der Stelle, an der die Änderung eintritt. Schützen Sie
mainmit Verzweigungsschutz für den eine überprüfte Pull-Anfrage erforderlich ist, übertragen Sie mit Neue PR erstellen und beschränken Sie, wer mit der Veröffentlichungsrolle Website veröffentlichen darf. In der Pull-Anfrage werden die geänderten Dateien und die Vorschau-URLs der betroffenen Seiten aufgelistet, sodass ein Entwickler das Ergebnis vor dem Zusammenführen prüft. Richten Sie diese Steuerelemente ein, bevor weitere Personen Beiträge leisten, und aktivieren Sie Agentenberechtigungen nur, wenn eine Aufgabe sie benötigt. Siehe Größerer Beitrag, gleiche Produktionskontrolle. - Behandeln Sie Quellseiten und Design-Dateien als nicht vertrauenswürdige Eingabe. Sie können Text enthalten, der versucht, den Agenten zu steuern. Überprüfen Sie die Änderungen, bevor Sie sie per Push übertragen, in der Vorschau anzeigen oder veröffentlichen.
Berechtigungen für Inhalts-Push content-push-permissions
Wenn Sie Inhalte mit Ihrer Adobe-Anmeldung hochladen, erzwingt das Ziel die Berechtigungen Ihres Kontos. Für dokumentbasierte Inhalte, die in Experience Workspace bearbeitet werden, benötigen Sie Schreibzugriff auf den Zielinhalt. Für das Experience Manager-Authoring benötigen Sie die Berechtigung zum Schreiben von Seiten und Assets unter den ausgewählten Pfaden auf der Autoreninstanz. Durch die Anmeldung bei der Konsole werden diese Rechte nicht gewährt.
Wenn Sie die Berechtigung für die Adobe-Anmeldeinformationen des Agenten aktivieren, werden die Inhalte des Agenten über den Zugriff Ihres Kontos an das dokumentbasierte Inhalts-Repository gesendet. Der Agent zum Hochladen aufzufordern, umgeht die Berechtigungen des Ziels nicht. Laden Sie für das Experience Manager-Authoring den Inhalt selbst über die Konsole hoch. Das Hochladen von direkten Agenten wird nicht unterstützt.
Wenn ein dokumentbasierter Upload ein konfiguriertes Fallback-Konto verwendet, weil Ihre Anmeldung nicht verfügbar ist oder die Authentifizierung fehlschlägt, erzwingt das Ziel stattdessen die Berechtigungen dieses Kontos. Dasselbe gilt, wenn Sie explizit ein Service-Konto für den Agenten konfigurieren. Vergewissern Sie sich, welches Konto verwendet wird, bevor Sie sich auf Ihre persönlichen Berechtigungen verlassen, um Änderungen zu begrenzen.
Verfolgen Sie, was der Agent getan hat audit-trail
Die Konsole speichert kein separates Auditprotokoll, aber die Arbeit des Agenten wird nicht aufgezeichnet. Was der Agent erzeugt, gelangt nur über Ihr Git-Repository oder über Experience Manager auf Ihre Site. Beide führen einen Verlauf:
- Code ist der primäre Datensatz. Im Git-Verlauf wird jede Änderung an Blöcken, Stilen und Importskripten aufgezeichnet. Die Importskripte definieren die Struktur jeder importierten Seite.
- Inhaltsänderungen werden mit dem Inhalt aufgezeichnet. Experience Workspace führt einen Versionsverlauf jedes Dokuments, und die Autoreninstanz speichert ihre eigenen Seitenversionen.
- Das Gespräch zeigt, was gefragt wurde. Chat herunterladen speichert die Konversation als Markdown-Datei. Laden Sie sie herunter, bevor Sie Chat löschen auswählen, wodurch die Nachrichten entfernt werden und nicht mehr rückgängig gemacht werden können. Siehe Chat-Bedienfeld.
Der Datensatz lässt sich am einfachsten nachvollziehen, wenn jede Anfrage an den Agenten in einem eigenen Commit endet, an einen Arbeitszweig gepusht wird und nicht an main, und wenn Seiten geändert werden, den eigenen Inhalt hochladen, den der Agent anbietet und den eine Person genehmigt. Fordern Sie dies im AGENTS.md des Projekts an; siehe Hinterlassen Sie einen Datensatz über jede Anfrage. Reviewer lesen dann in Tools, die sie bereits verwenden, was der Agent geändert hat, und zwar auf Anfrage.
Wo Ihre Arbeit gespeichert wird security-storage
- Der gepushte Code wird in Ihrem Git-Repository gespeichert. Inhalte, die Sie hochladen, werden in Experience Workspace oder in Ihrer Autoreninstanz gespeichert. Es gelten ihre eigenen Richtlinien zur Aufbewahrung und zum Versionsverlauf.
- Arbeiten, die Sie weder gepusht noch hochgeladen haben, sind nur in Ihrem Konsolenarbeitsbereich verfügbar, zusammen mit dem Chatverlauf und den Transkripten der Agentensitzungen. Chat löschen entfernt die Nachrichten aus dem Chat-Panel, behält aber die Transkripte bei. Um die Arbeit des geöffneten Projekts im Konsolen-Arbeitsbereich einschließlich der Transkripte zu löschen, verwenden Sie Arbeitsbereich zurücksetzen.
Informationen zu Verarbeitungsorten, Datenaufbewahrung und Compliance erhalten Sie von Ihrem Adobe-Account-Team oder im Adobe Trust Center.
Gesundheitsdaten und HIPAA security-hipaa
Der Experience Modernization Agent ist ein Entwickler-Tool zum Migrieren und Erstellen von Sites. Die Besucher Ihrer Site erreichen diese nie: Edge Delivery Services stellt die veröffentlichte Site bereit, und die Anfragen der Besucherinnen und Besucher werden nicht über die Konsole oder den Agenten weitergeleitet. Sie können die Seiten, Designs und Assets einer Gesundheitswebsite ohne Patientendaten migrieren. Geben Sie dem Agenten niemals echte Endbenutzerdaten, wie z. B. Patientendaten oder Benutzeranmeldeinformationen, und migrieren Sie keine Seiten oder Assets, die diese Daten enthalten. Verwenden Sie fiktive Daten, um patientenspezifische Layouts zu entwickeln und zu testen. Was auch immer Sie dem Agenten geben, er kann das KI-Modell erreichen. Siehe Was das KI-Modell verarbeitet.
Eine Staging-Site, eine Zulassungsliste oder eine Quellanmeldung ändert diese Einschränkung nicht. Überprüfen Sie vor dem Importieren einer geschützten Quelle die im Umfang enthaltenen Seiten und Assets und beschränken Sie das Quellkonto auf Inhalte ohne geschützte Gesundheitsinformationen (PHI). Konfigurieren Sie dieses Konto über Quellauthentifizierung, nicht im Chat.
Bestätigen Sie bei einer Site, die PHI unter dem Health Insurance Portability and Accountability Act (HIPAA) verarbeitet, die Authoring- und Versandeinrichtung mit Ihrem Adobe-Account-Team, einschließlich der erforderlichen Lizenz, der Business Associate Agreement (BAA) und der Konfiguration. HIPAA-Bereitschaft für Adobe Experience Manager as a Cloud Service listet Edge Delivery Services als HIPAA-bereit auf, aber der universelle Editor ist nicht HIPAA-bereit. Er kann einem erweiterten Sicherheitsprogramm nur hinzugefügt werden, wenn kein PHI eingeführt wird. Ein HIPAA-fähiger Bereitstellungsdienst erweitert seine PHI-Abdeckung nicht auf den Agenten oder einen Editor, der nicht HIPAA-fähig ist.
Support-Anfragen security-support
Eine Support-Anfrage wird an das Adobe-Team gesendet, das den Agenten erstellt. Mit dem Thema und der Beschreibung, die der Absender schreibt, teilt er:
- Der Name des Absenders, die E-Mail-Adresse sowie Adobe-Benutzer- und Organisations-IDs.
- Sitzungs-ID, Projektname und Vorschau-URL sowie der Git-Host für GitHub Enterprise.
- Alle aktuellen Eingabeaufforderungen, die der Absender anhängen möchte. Standardmäßig ist keine angehängt.
Mit diesen Details kann das Team die Konversation und die Protokolle der Sitzung finden. Vor der Einrichtung des Arbeitsbereichs der Absenderkonsole gibt eine Anfrage nur den Namen, die E-Mail-Adresse und die Organisation gemeinsam. Auf den Seiten des automatischen Modus gibt Hilfe abrufen nur den Namen und die E-Mail-Adresse des Absenders für seine Nachricht frei. Bitten Sie Benutzer, Passwörter, Token oder persönliche Daten nicht in die Beschreibung aufzunehmen. Siehe Support anfordern.
Nächste Schritte next-steps
Nachdem Ihr Team sich auf den Umfang, den Ansatz und die Kontrollen geeinigt hat, folgen Sie Produktionssite migrieren. Verwenden Sie Automatikmodus für eine erste Prüfung Ihrer eigenen Seiten, bevor Sie sich für diese Arbeit entscheiden.