Migration Drupal 8 zu Drupal 10

soweit ich das kenne, kannst Du mit Hilfe des Kontroll-Moduls upgrade_status Von D8 nach D9 updaten und anschließend entsprechend von D9 nach D10. (https://www.drupal.org/docs/upgrading-drupal/upgrading-from-drupal-8-or-...) Diese Anleitung einmal von D8 nach D9 verwenden und danach von D9 nach D10.

gibt es aber leider nicht für drupal8, sondern nur 7 oder 9,10 usw...
Mir ist auch nicht klar, ob ich dieses Modul in die drupal8 Installation oder in die schon erstelle (leere) drupal10 Seite integrieren muss. Ich möchte ja die vorhandene und mit vielen Nodes ausgebaute d8 Seite in die d10 integrieren (das Theme in 10 ist anders, weil das Theme von 8 nicht weiterentwickelt wurde)...
Sorry, wenn ich so dumm frage, aber ich mache das leider nur laienhaft nebenbei...
LG
D.

Da das Upgrade von Core 9 inzwischen schon eine Nachzügler Aktion ist, kann man froh sein, daß die aktuelle Version noch Drupal 9 Kompatibel ist. Aber es gibt ja auch älter Releases wie z.B. 8.x-3.19

Das ganze wird sehr wahrscheinlich nur als Mehr-Schritt Upgrade funktionieren. Wir helfen gerade einem Kunden bei Upgrade von 9.3 auf 10.1 und da benötigen wir ein Zwischenschritt zu Core 9.5 und Konfigurationsänderung wegen Ckeditor 5. Bei so großen Upgrade-Sprüngen wie von Core 8 können sogar PHP Versionsänderungen zwischen den Upgrade-Schritten nötig werden. Das geht mit Drush und multiplen PHP Versionen einfacher als via update.php, das ich schon seit Jahren nicht mehr benutzt habe.

Ab Core 8 ist Migration auf keinen Fall das Standard-Verfahren und sollte nur in Betracht gezogen werden, wenn es keinen Upgrade-Path mehr gibt für einzelne Module. Der Core und gut gepflegte Contrib-Module haben aber Upgarde/Update-Pfade, die aber (siehe oben) nicht mehr unebedingt mehr als direkter Sprung funtionieren sondern evtl. Zwischenschritte benötigen.

Edit: Letzte 8-Version korrigiert auf 8.x-3.19 / Edit2: Tippfehler berichtigt

Das Modul ist nur dafür da, um den Upgrade status der verwendeten Modul im aktuellen System anzuzeigen. Es könnte auch sein, daß es für diesen großen Sprung (siehe mein vorigen Kommentar) nicht mehr so hilfreich ist selbst wenn man es im alten System installiert. Auf gar keinFall hilft es beim Upgrade oder wenn es denn sein muss bei einem wie gesagt meistens unnötigen Migrations-Ansatz zu D10.
Da Templates eigentlich niemals Funktionen abbilden sollten, sollte man sie in der Regel relativ leicht zumindest in technischer Hinsicht ersetzen können und sei es nur temporär für das Upgrade z.B. mit einem Standard Template, das sowohl in D8 als auch D10 funktioniert. Für das Übergangstemplate würde ich dann auch nicht so viele Block-Anzeige Anpassungen etc vornehmen, sondern das dann auf dem Ziel-Template machen.
Ich weiß es kursieren viele Anleitungen, bei denen ein Upgrade als einmaliger Vorgang beschreiben und propagiert wird. Aber davon kann ich nur abraten. Mit Hilfe von Code-Management (Git, Composer) und Hilfs-Systemen sollte man den Vorgang Upgrade oder Migration als wiederholbaren Prozess planen und testen und dann schrittweise alle Fehler beheben, die da auftreten. Wenn man das als Einmal-Vorgang angeht, kann es sein, daß man sich Fehler in die Produktiv-Datenbank zieht, die dann noch schwerer zu beheben sind. Die Basis-Fähigkeit, Backups zu erzeugen und insbesondere nach Datenbank-Änderungen trotzdem wieder sauber ein Rollback durchzuführen sollte immer vorhanden sein. Und damit meine ich, Code-Zustand vor dem Rollout/Upgrade-Versuch wieder herzustellen und die Datenbank nicht einfach zu überschreiben mit dem Backup sondern diese vorher zu löschen. Denn leider kann Drupal ein Update der Datenbank nur in eine Richtung ausführen. Bei einem erneuten Versuch können dann Tabellen das Update verhindern, die vom vorherigen versuch stammen. Das dann manuell beheben zu müssen während eine Kundenwebsite gerade offline ist, will ich nie wieder erleben.

Das ganze ist zugegeben im Standard-Hosting oder auch auf lokalen Dev-Systemen zugegeben nicht gerade einfach oder gar bequem, wenn man das manuell machen muss/möchte. Im professionellen Kontext läuft das voll- oder mindestens halbautomatisch. Wir haben da eine sehr effiziente und kostengünstige Methode entwickelt, die wir zwar auch als Service anbieten aber mindestens die Fertigkeiten mit Composer, Git und Gitlab, Drush und Composer erfordert.

Ergänzung: Was ich noch schreiben wollte ist, daß das man alles, was das upgrade_status Modul kann auch selbst recherchieren kann, in dem man auf den Modul-Pages eben auch mal in die Release-Liste schaut und Issues anschaut. Die Code-Analyse machen wir generell mit phpstan (commandline tool), das auch von Drupal-Helfer Modulen verwendet wird.
Und allgemeiner Pro-Tipp: Mit "drupal-lenient" kann man D10 Modul Patches benutzen insbesondere die von Drupal.org, wenn das Modul selbst noch via composer.json angibt nur D9 kompatibel zu sein und somit Composer hindert, den Code auf neuesten Stand zu bringen.

Danke für die Infos - Nachdem es um ein privates Projekt geht, habe ich ja Zeit. D.h. dann werde ich meine bisherige Seite und deren Nodes manuell mit Copy + Paste übertragen und in Ruhe überlegen, welche Seiten ich weiter behalten werde und welche ich bei der Gelegenheit ausmiste.
LG
D.