Sie planen eine Drupal Migration Ihrer Website?
Sicherlich fragen Sie sich: Wie lässt sich eine erfolgreiche Drupal 9 Migration, ein sauberes Drupal 8 Update durchführen?
Oder: Was tun mit der veralteten Drupal 7 Website?
Dieses Video gibt einen wichtigen Einblick und eine Orientierung durch das Experten-Know-how von Bright Solutions CEO Manuel Pistner und von unserem langjährigen Drupalpartner und Digitalisierungs-Spezialisten Rouven Volk!
Weiter unten finden Sie das gesamte Interview-Transcript – viel Spaß beim Stöbern!
Links und Hinweise:
Hier geht es zum LinkedIn Profil von Rouven Volk und Manuel Pistner
Verfolgen Sie den aktuellen Stand zu Drupal 6, Drupal 7, Drupal 8 und Drupal 9 auf drupal.org
Weiterführende Links zum Thema Drupal Migration Best Practices, Drupal Roadmap, Drupal Community sowie Drupal Events:
https://dri.es/drupal-7-8-and-9
https://slides.com/gaborhojtsy/state-of-drupal9
Folgen Sie uns auf YouTube und stöbern Sie rund um Digital Know-how!
Folgen Sie uns auf LinkedIn
Johanna Anthes
Hallo Manuel, Hallo Rouven, ich freue mich, euch beide hier zu sehen. Vielleicht stellt ihr euch kurz mal vor, damit wir wissen, weshalb genau ihr jetzt die richtigen Ansprechpartner für mich seid. Rouven Volk ist durchaus ein Name, den man schon öfters gehört hat. Rouven, sei doch so gut und stell dich mal kurz vor!
Rouven Volk
Ich bin jetzt seit ungefähr 2007 aktiv im Drupal Umfeld, das heißt seit 13 Jahren konsolidiert. Habe damals mit Drupal 5 angefangen, mein erstes Projekt war quasi eine Migration zu Drupal 6. Dementsprechend hat mich das Thema von Migrationen halt auch von Anfang an mit begleitet. Und dementsprechend freue ich mich natürlich heute dabei zu sein und ein bisschen was von meinem Background teilen zu können. Aber das Ganze halt auch in Fokus zu setzen, wo die Reise jetzt aktuell mit Drupal 9 hingeht.
Ich bin selbst unterwegs im Bereich IT Beratung, Solution Architecture. Aber ich begleite auch ganz viele Kunden, die Innovationen in ihr Unternehmen einbringen wollen und sagen „Wir wollen beweglich sein, wir wollen flexibel sein und davon profitieren, was da draußen im Internet passiert an Technologie und Entwicklung.“ Und das eben adaptieren; und da treffen wir halt ganz, ganz oft auf klassische, hierarchisch gewachsene Projekt-Strukturen.
Da ist das natürlich komplett konträr. Und da freue ich mich schon heute darauf, mit eingehen zu können. Aber bevor ich jetzt zu viel vorweggreife, erstmal an Manuel. Wir arbeiten ja jetzt inzwischen ja auch schon seit einigen Jahren zusammen und dementsprechend schön, dass du heute auch dabei bist.
Manuel Pistner
Ja, danke. 2015 haben wir uns auf der Drupalcon Barcelona getroffen. Das war so das erste Mal. Ich selbst arbeite seit 2008 mit Drupal. Ich habe mit Drupal 6 angefangen – ich habe mir damals im Hugendubel mein erstes Drupal Buch gekauft und fand das System wegen der Modularität extrem klasse und habe eigentlich mein ganzes Unternehmen darauf aufgebaut, Bright Solutions, was es so seit 2011 gibt.
Ich habe zahlreiche Drupal Projekte selbst entwickelt, selbst gemanaged, habe in vielen Projekten als Berater gearbeitet zum Thema Drupal Architektur und führe heute eben Bright Solutions, wo wir unter anderem Drupal Projekte entwickeln, Drupal Software migrieren, aber eben auch mobile Apps Et cetera. Und, weil eben das Thema Personal Engpässe und Skill Engpässe und Kapazitäts-Engpässe eben ein großes Thema ist, habe ich Flash Hub gegründet und damit bauen wir Virtuelle Teams auf, um Projekte zu beschleunigen und von dem leidigen Personal Engpässe, Skill Engpässe und Kapazitäts-Engpässe zu befreien.
Johanna Anthes
Danke für die Einleitung. Wir sind jetzt direkt gestartet mit diesem Wort „Migration“.
Ich möchte ein bisschen zurück gehen und erst einmal fragen: Was ist das denn überhaupt? Wenn ich Drupal höre, da denke ich vor allem an Updates, Security Updates. Das ist immer ein Riesenthema bei Drupal. Das heißt, ich habe jetzt hier schon zwei Wörter: Drupal Updates und Drupal Migration, kenne aber auch Drupal Relaunch. Was ist denn was?
Rouven Volk
Vielleicht lege ich hier mal vor.
Also prinzipiell: Bei einer Migration sprechen wir immer von einem großen Versions Sprung.
Das heißt, dann, wenn ich nicht einfach nur einen kleinen Teil aktualisieren kann, sondern wenn ich mich halt wirklich zu einer neuen Hauptversion fortbewegen muss. Das kann jetzt zum Beispiel sein von Drupal 8 zu aktuell Drupal 9. Es kann aber auch von einer beliebigen Technologie hin und her sein. Das wäre erstmal grob der Begriff der Migration.
Also, was gehört dazu? Es ist halt nicht nur der Versions Sprung, sondern daran hängt in der Regel auch Technologie, technologische Entscheidungen, Kompatibilität. Aber vor allem – ganz, ganz wichtig – auch die Inhalte. Das, was wir regelmäßig austauschen, wenn wir darüber nachdenken, wie Projekte sich entwickeln, sind technologische Komponenten, um nun mal aktuell zu bleiben, und wie die Sachen zusammenspielen.
It was such a great pleasure being judge at @SplashAwards_CH tonight! Big virtual applause to all winners, well deserved! Here is the link to our live recording starting at my favorite category: Technology https://t.co/gTZ4OBd73k#drupal #splashawards #Awards #livevideos
— Rouven Volk (@rouvenvolk) November 26, 2020
Aber das, was kontinuierlich mit unserem Projekt wächst, sind die Inhalte und die wollen wir natürlich nicht verlieren, wenn wir eine neue Version einführen. Und deswegen ist es so wichtig, über Migration nachzudenken und diese angestammten Daten, die man über die Jahre gesammelt hat, auch wieder in dem neuen Projekts zu vereinen und darauf weiter aufzubauen, ohne diese zurückzulassen – oder sie manchmal auch ganz bewusst zurückzulassen, weil man halt weiß, wir brauchen sie nicht mehr und haben jetzt einen besseren Weg, unser Problem zu lösen.
Manuel Pistner
Ich würde vielleicht noch ergänzen, dass Migration immer dann notwendig ist, wenn sich die technologische Basis wirklich signifikant ändert.
Also wenn ich entweder meinen Content in WordPress habe und will auf Drupal wechseln oder – wie es in der Vergangenheit war – wenn sich die technologische Basis von Versionsnummer zu Versionsnummer so dramatisch ändern. Also Drupal 6 auf Drupal 6, 6 auf 7, 7 auf 8. Das waren immer komplett neue Drupalsysteme unter der Haube, weil die Community gesagt hat „das Alte lassen wir mal das Alte sein und wir wissen jetzt so viel mehr und haben so viel mehr gelernt und machen es mal komplett neu.“
Damit ist das Drupal unter der Haube ein komplett anderes. Da muss ich den Content irgendwie auf diese neue technologische Plattform komplett adaptieren, wohingegen Updates meistens nur kleine Code Änderungen sind, um Bugs zu beheben oder Sicherheitslücken zu schließen.
Johanna Anthes
Ich denke vor allem, was hier wichtig ist, ist, dass man auch versteht, dass eine Migration, eine Drupal Migration auch auf andere Technologien funktioniert oder entsprechend geplant werden kann.
Ich glaube, man denkt da sehr oft innerhalb, oder wenn man das als Newbie ein bisschen hört, oft nur innerhalb von Drupal. Aber, wie du ganz richtig gesagt hast Manuel, das kann auch auf z.B. ein WordPress Systemen sein, wie das jetzt bei Bright Solutions z.B. der Fall war.
Rouven Volk
Was an der Stelle vielleicht spannend zu betrachten ist, ist: Gerade wenn wir uns jetzt die Drupal Welt anschauen, dann kommt es nur alle paar Jahre zu einem Hauptversionssprung. Ich hatte ja eingangs erwähnt, dass ich damals schon 2007 eingestiegen bin. Im Jahr 2008, ich weiß noch, da war es Frühjahr, da wurde die Drupal 6 Release Party gefeiert, damals noch in Berlin, und da war natürlich ganz, ganz viel Bewegung drin, weil, es wurden ja nicht nur Webseiten umgestellt, sondern es mussten ja auch gut hunderte oder tausende von Modulen exportiert werden. Also all die Funktionalitäten, die man im alten System hatte, wollte man auch im neuen System haben.
Und wenn man jetzt bedenkt, wie so ein Open-Source-Projekt altert, dann muss man bedenken, dass da Tausende von Menschen zusammenarbeiten. Und die ziehen natürlich alle an einem Strang. Und wenn jeder sein eigenes Modul dort pflegt, da braucht man in der Mitte einen konsistenten Kern, der sich halt weiterentwickelt und vor allem braucht man stabile APIs und Standards.
Und das hat die Drupal Community relativ früh schon begriffen und deswegen hat es auch sehr lang gedauert, bis es dann zum nächsten Versionssprung kam. Drupal 7 kam dann 2011 raus. Drei Jahre. Also nicht im jährlichen Rhythmus, sondern wirklich drei Jahre, was eine Besonderheit ist.
Der Versionssprung zu Drupal 8 hat dann vier Jahre gedauert. Man hat dann schon angefangen, zu scherzen, es wird immer ein Jahr länger dauern und in der Tat kam Drupal 9 jetzt 2020 raus.
Was wir aber auf diesem Weg gelernt haben, ist, damit umzugehen, diese wiederkehrende Migration in den Griff zu bekommen.
Man hat unglaublich viel dazugelernt und Standards geschaffen, wie man innerhalb von einem System zum nächsten rüberkommt, ohne allzu viel Arbeit damit zu haben.
Manuel Pistner
Zum Glück. Früher war das ja immer echt ein Krampf, es war immer eine komplette Neuentwicklung eigentlich und man konnte meistens noch nicht einmal starten, wenn ein neues Drupal Release da war, weil man auf die ganzen Module warten musste, die dann auch alle komplett neu entwickelt werden mussten, damit sie sich halt mit dem, wie du so schön gesagt hast, stabilen Kern von Drupal, der dann komplett neu war, wieder integrieren. Andernfalls hat man einfach so ein angepflanztes Geschwür als Modul, das sich mit dem Kern gar nicht weiterentwickelt und auch damit meist nicht sauber funktioniert.
Aber das ist ja jetzt zum Glück deutlich besser. Jetzt wird’s endlich mal wahr: „Mit dem neuen Drupal Release wird alles besser.“ Alles? Weiß ich nicht, aber der Upgrade Pfad soll ja jetzt deutlich schlanker sein, von Drupal 8 auf 9, von 9 auf 10 Et cetera, sodass man eben nicht immer wieder alles neu machen muss, wie es in der Vergangenheit war.
Johanna Anthes
Das zeigt ja auch vor allem, dass alle Webseiten oder Systeme auf Drupal 7 – und Drupal 6, falls es das noch gibt – dass das jetzt eine ganz schöne Hürde wird. Also dass die jetzt wahrscheinlich ganz schön zu knabbern haben mit der Migration, oder zumindest jetzt nicht mehr weiter warten sollten.
Wie sieht da eure Einschätzung aus? Also ist es allerhöchste Eisenbahn für diese Version oder generell? Wie sieht das aus für die einzelnen Versionen? Wer sollte sich jetzt ordentlich beeilen?
Manuel Pistner
Ja, also ich würde mal sagen, wer heute noch eine Website auf Drupal 6 hat, hat den Fokus in der Vergangenheit nicht allzu sehr auf die Drupal Installation, auf Security, auf Fortschritt und Weiterentwicklung gelegt. Deshalb würde ich sagen ist jetzt eigentlich eine große Chance. Nicht nur, weil der Security Support schon lange ausgelaufen ist, sondern weil man jetzt eben auch mit Sicherheit eine Webseite vorfindet, die nicht mehr komplett state of the art ist, was die ganzen Technologien angeht, mobile Friendly, Geschwindigkeit, et cetera.
Und wenn man heute eine Drupal 6 Website hat oder auch eine Drupal 7 Website, ist, glaube ich, mit dem Upgrade auf Drupal 9 nicht nur eine technologische Veränderung absolut wichtig, sondern ich glaube, man sollte sich dann auch mal Gedanken machen:
Welche Ziele verfolgt man eigentlich mit der Webseite, wie verfolgt man sie und auf welchen Kanälen muss denn die Seite funktionieren? Wie baue ich mein Content auf, sodass er heute überhaupt zeitgemäß ist?
Weil: heute ist Content von der Struktur her komplett anders als er damals war mit Drupal 6 und auch anders als mit Drupal 7.
Ich glaube, die Ziele, die man damals mit dem Content erreicht hat auf auf einer Website, als es noch Drupal 6 und 7 gab, die wird man heute nicht mehr mit dem gleichen Content erreichen. Und ich glaube, dass dann eher ein kompletter Relaunch nötig ist, als nur die technologische Basis zu erneuern. Das würde ich mal aus Business Sicht sehen.
Das ist ein sehr spannender Aspekt, der Content. Ich habe im Laufe der Jahre viele Migrationen gesehen und das, was halt immer von einem Projekt zum anderen übernommen wurde, waren die Inhalte, aber die Inhalte in ihrer reinen Form. Das heißt, man hat nicht angefangen, Landingpages von alten Kampagnen nachzubauen, nach dem Motto „Wir haben vor drei Jahren ne Kampagne gehabt, die Oster Kampagne, die muss dieses Jahr auch wieder laufen“ Sondern man hat sich überlegt: Was sind die essentiellen Inhalte?
Was müssen wir wirklich erhalten? Und das ist ja auch eine der Stärken von Drupal; das Drupal dieses „Content first“ Modell hat und sich als erstes den Content strukturiert, gegebenenfalls übersetzt und DANN überlegt: Wie möchte ich Content darstellen? Wie möchte ich ihn aufbereiten?
Wenn wir jetzt die aktuelle Version nehmen – das hat damals mit Drupal 6 schon angefangen, da hat man gesagt „ok. Ich habe unterschiedliche Ansicht Modi für denselben Inhalt.“ So wurden automatisch Teaser generiert.
Und dann hat man damals irgendwie noch eine mobile Version gemacht oder es kamen die ersten Seiten mit Responsive Design. Aber heute sprechen wir ja nicht mehr nur von Responsive Design Webseiten, sondern wir haben Applikationen. Wir haben integrierte Systeme. Inhalte, die ich auf der Webseite ausgebe, möchte ich verknüpfen mit meinen Kampagnen. Das heißt, hinten laufen die Sachen idealerweise in mein Analytics mit rein, in mein CRM System. Und so ist heute alles hart verdrahtet miteinander und wir wollen größtmögliche Flexibilität mit den Inhalten haben.
Und das war damals in dem Umfang noch gar nicht möglich.
Das heißt, wir haben nicht nur einen Technologie-Sprung, sondern auch von der Denkweise, von der Kultur, wie wir mit den Webseiten arbeiten. Welche essentiellen Parts in unserer Unternehmenskommunikation heute spielen.
Und dementsprechend müssen wir natürlich auch gucken: Wie bleiben wir aktuell? Und da kommt mir halt eine Sache ganz, ganz stark in den Sinn. Und zwar, das ist die Abwärtskompatibilität. Wenn ich jetzt eine Drupal 7 Seite habe, dann muss ich mir vorstellen: Drupal 7 wurde 2011 veröffentlicht.
Dann haben alle angefangen, die Module zu migrieren. Das ist fast 10 Jahre her. Das heißt, wenn ich heute noch eine Drupal 7 Seite betreibe, dann habe ich nicht nur das Problem, dass ich auf alte Technologie meine Basis setze, sondern auch, dass der Support verschwindet. Die Leute ziehen weiter, die Community zieht weiter.
Der ganze Fokus ist momentan auf Drupal 8 und 9. Dementsprechend finde ich auch ganz schwer Leute, die für mich Probleme lösen können; oder Architekturen wurden grundlegend verändert und niemand verfolgt mehgr den alten Pfad.
Wenn ich mich weiterentwickeln will mit meinem Projekt, kann ich das in der Regel in diesem alten Projekt heute gar nicht mehr, mit der alten Codebasis, und MUSS diese auf den aktuellen Stand bringen.
Johanna Anthes
Für mich ist natürlich jetzt die Frage: Wenn ich jetzt ein Drupal Projekt migrieren müsste (ich bin jetzt Product Owner oder aus Marketingsicht, als Marketing-Manager, der weiß: Okay, das muss jetzt unbedingt dieses Jahr passieren).
Gibt es – man sagt ja so gerne bei Drupal „there is a module for that“ – gibt es Tools, die mir dabei helfen können? Also ich würde ja zuerst einmal überlegen, wie kann ich das dann am einfachsten machen?
Rouven Volk
Also prinzipiell: Die erste Anlaufstelle hier wäre erstmal Drupal.org, auf Drupal.org finden wir alle relevanten Informationen für die typische Migrationsschritt. Das fängt z.B. damit an, dass ich mit dem Upgrade Status prüfen kann (also das ist ein Modul: Upgrade Status) inwieweit die Module, die ich aktuell verwende bzw. die Themes, die ich im Einsatz habe, mit der aktuellen Code Base von Drupal 9 kompatibel sind.
Das gab es auch bereits für Drupal 8. Und das war eine dieser Initiativen, wo die Community auch gesagt hat: Wir wollen den Versions Umstieg so einfach wie möglich machen. Jetzt gibt es ein weiteres Modul, das ist der Drupal Module Upgrader, und bei dem Upgrader ist quasi eine Routine hinterlegt, die deinen aktuellen Source Code, also deine aktuellen Module analysiert und guckt, ob sie denn kompatibel ist mit den neuen API Standards, mit den Spezifikationen wie wir mit Funktionen arbeiten – und dann konkrete Empfehlungen macht.
Teilweise hilft uns das Modul auch, Dinge zu automatisieren und dir dann sagt „Halt, das ist die alte Funktion, ich schreibe dir das mal automatisiert um und du brauchst es dann quasi nur noch abnicken.“ Bis hin zu: „Hier ist eine Stelle, die kann ich nicht für dich umschreiben, weil ich nicht verstehe was dort passiert“, dementsprechend setzt du deine Entwickler da mal ran, sodass die es auf den neusten Standard bringen, aber quasi mit einer direkten Verlinkung und Dokumentation und die Dinge, die sich geändert haben.
Das macht es natürlich sehr einfach, auch für die Module Upgrades für alle Module, die ich selber inhouse entwickelt habe und jetzt nicht auf Drupal.org veröffentlicht sind. Das ist natürlich ein ganz, ganz entscheidende Schritt, wenn ich auch auch wissen will, wie aufwendig wird es denn? Wie viel Aufwand hängt an dieser Migration? Was bedeutet es für die Softwareentwicklungen? Was bedeutet es aber auch für die Content Migration?
Und dementsprechend kann ich nur jedem an dieser Stelle erstmal empfehlen, sich vertraut zu machen mit den Tutorials, die es gibt auf der Seite.
Und auch mal experimentell die eigene Seite zu nehmen, diese Module zu installieren und sich so einen Report generieren zu lassen. Denn das gibt einem die beste Übersicht, wo man starten kann und vor allem auch sollte.
Manuel Pistner
Sehr guter Punkt. Die meisten Migration, die ich so erlebt habe, gerade in den letzten 10 Jahren, sind so abgelaufen, dass man sich sehr sehr viele Gedanken und Pläne gemacht hat, wie das denn alles laufen kann und analysiert bis der Arzt kommt.
Und dann hat man angefangen, mal wirklich Module zu upgraden und mal wirklich in die Praxis zu gehen. Und da hat man festgestellt „Ja gut, naja, das ist alles doch irgendwie ganz anders, als wir es uns überhaupt vorgenommen haben.“
Deshalb finde ich den Ansatz total sinnvoll, den du genannt hast, Rouven, einfach mal Drupal 9 oder 8, je nachdem wohin man migrieren will, aufzusetzen, um mal zu schauen: Was passiert, denn wenn ich die Drupal Migrations Module anwerfe, wo lande ich denn, wie sieht das Ganze denn aus? Mir mal Reports ziehe, über die Module, die Rouven genannt hat, und dann mal zu gucken: Wo stehe ich denn tatsächlich? Und von da kleine Schritte nach vorne zu gehen, statt viel zu planen und dann festzustellen „naja, wir haben eigentlich völlig an der Ist-Situation vorbeigeplant, weil wir sie gar nicht im Detail durchschaut haben.“
Also ich hab’s noch nie erlebt, dass ich ein komplettes Drupal Migrations Projekt voraus plane und es dann wirklich so funktioniert hat, wie ich es mir vorgestellt habe.
Dafür ist das Ganze einfach viel zu komplex. Und heute ist es nochmal komplexer als früher.
Wie Rouven schon gesagt hat, es gibt oft so viele Integrationen in Analytics, in CRM Systeme. In ERP Systeme, in business intelligence systeme. Manchmal E-Commerce Systeme. Das ist einfach so komplex, da kann man nur wirklich sagen „OK. Wir nehmen uns einzelne Schritte vor und schauen wie weit kommen wir iterativ statt im Wasserfall Modell“, das aus meiner Sicht komplett ausgedient hat für solche Sachen.
Rouven Volk
Es ist spannend, dass du das erwähnst, ich erinnere mich noch an ein Projekt. Da haben wir das frühzeitig erkannt. Also auch der Kunde hat es erkannt gehabt, dass wir gar nicht quasi so einen Big Bang Relaunch machen können. Also, wir haben damals eine Seite von Drupal 6 auf Drupal 7 migriert.
Und es war schon klar, wir können jetzt nicht einfach sagen „Das Projekt ist auf Eis gelegt, wir portieren alle Inhalte“, weil – es Live Geschäft weiter. Marketingkampagnen liefen, Kundendaten wurden generiert.
Das heißt, wir mussten einen Weg finden, wie wir frühzeitig sicherstellen können, dass Projekte kompatibel sind und am Tag der Umschaltung auf die neue Projektversion bereits alle Inhalte da sind oder zumindest aktuell innerhalb der letzten 24 Stunden, sodass man über ein kleines Zeitfenster halt wirklich sicherstellen kann, dass alle Inhalte migriert und verfügbar waren. Und wie wir das damals gelöst haben, war mit dem Migration Module, was uns halt erlaubt, Migration zu wiederholen.
Das heißt, dort legt man die Regeln fest, wie Daten aus einem System ins andere transferiert werden sollen. Klassischerweise hat man dort mehrere Schritte. Ich will jetzt nicht zu tiefer reingehen. Aber die einfache Idee ist: Daten aus der alten Struktur auslesen, sie umschreiben in der Mitte, damit sie kompatibel sind und die Referenzen auch behalten können, und in andere Systeme wieder einspielen.
Und wenn man diesen Prozess verfolgt, dann kann man relativ einfach auf einen täglichen Knopfdruck die Daten migrieren lassen.
Man sieht, ob irgendwo etwas klemmt oder was nicht funktioniert.
Die Entwickler können sich aus einem aktuellen Live System – was weiter läuft, bis zum Tag des Relaunch – eigentlich täglich die aktuellen Daten rüber synchronisieren und gucken, dass die Automatisierung so rund läuft, dass am Ende gar keine manuellen Migration notwendig ist.
Und das war wirklich eine Schlüssel Komponente für diesen Projekt Erfolg damals bei der Umstellung, weil zum Zeitpunkt des Go-Live haben wir innerhalb von einer Stunde die gesamte Migration durchgeführt. Die hat nicht mal 5 Minuten gedauert, weil wir halt wussten, dass wenn wir auf den Knopf drücken, alles portiert werden kann.
Das heißt, wir hatten nur die neusten Nachrichten, die neuesten Kommentare. Und da merkt man schon: Nachrichten und Kommentare – was hing noch drin? Web-Formulare. Was alles so an Daten generiert wird in so einer Website ist unglaublich! Und dementsprechend, man muss ein „Freeze“ irgendwann machen. Aber man sollte ihn so kurz wie möglich gestalten, sodass hier halt auch die Kunden bzw. das Kerngeschäft nicht drunter leiden.
Ich weiß nicht, wie es euch geht, aber wenn man jetzt sagt „Okay, wir machen jetzt Migration. Wir brauchen eine Woche dafür“ – kaum ein Unternehmen kann sich das leisten, dass die Webseite heutzutage eine Woche offline ist oder komplett eingefroren ist, sodass keine Veränderungen stattfinden. Das geht einfach nicht.
Manuel Pistner
Was du gerade gesagt hast mit dem Migrate Module. Das funktioniert bei vielen Seiten. Ich habe aber auch schon erlebt, dass es viel Hoffnung geschürt hat und am Ende große Enttäuschung gebracht hat. Nämlich genau dann, wenn die Drupal Webseite, die migriert werden sollte, einfach nur Custom Code war oder komplett die Contrib Module nicht mit Composer eingebunden wurden, sondern einfach die Module komplett verändert wurden.
Also sodass es eigentlich gar kein Drupal mehr ist, wie es von der Community kommt, sondern es ist das Drupal, wie es von der Community kommt plus einmal umgeschrieben, weil die Entwickler glaubten, „das ist alles Schrott, wir müssen es viel besser machen“ plus „alle Contrib Module, die brauchen wir eh nicht, wir bauen lieber Custom Module“ – und ich habe das früher auch gemacht, weil ich, als ich angefangen habe, gedacht habe, „ich kann es ja eh besser“. Deshalb kann ich es gar keinem böse nehmen.
Aber das führt dann eben dazu, je mehr Individualisierung und Hacks und Custom Code man hat, vielleicht sogar Custom Code, der einfach nur Plain PHP ist und mit der Drupal API gar nichts zu tun hat, mit der empfohlenen Schnittstelle, dann ist es auch mit automatisierter Migration von Inhalten nicht wirklich möglich.
Also da muss man wirklich genau hinschauen – wie hoch ist der Grad der Modifizierungen in Drupal Contrib Modulen? Dafür gibt es auch ein Modul. Ich glaube, das heißt „Modified“ oder so. Oder man muss schauen, wieviel Prozent der Funktionen sind über Custom Code abgebildet?
Johanna Anthes
Für mich wären hier so die Ohren aufgegangen, bei „manuell“ und „automatisierte“ Migration. Da würde ich ja auch sagen: „Ah, automatisiert, das klingt super, das würde ich gerne machen.“ Das heißt, ich weiß schon:
Planungsfehler Nummer 1 vermeiden: Den Ist-Zustand der eigenen Seite nicht verstehen.
Und am besten alle Standards so befolgen, dass ich bestmöglich nach der Drupal Community entwickelt habe oder habe entwickeln lassen, sodass eventuell sogar eine automatisierte Migration stattfinden kann.
Manuel Pistner
Absolut.
Rouven Volk
Das Spannende hier an der Stelle ist halt: Das Standard Migrations Modul, was mit Drupal kommt, das hilft uns, die Kern Komponenten, also was im Drupal Core enthalten ist, zu migrieren, denn das ist hoch standardisiert. Wir wissen genau, wie der Unterschied zwischen 6, 7, 8 und 9 aussieht. Das heißt, das geht sehr einfach. Das geht meistens sogar auf einen Knopfdruck und man muss es nur abnehmen. Schwierig wird es dann halt, wenn ich viele Contrib Module drin installiert habe in meinem Projekt.
Und, es ist nicht unüblich. Ich habe durchaus Projekte gesehen, da waren über 70 unterschiedliche Zusatz-Module installiert. Und dann gehts halt los, dann musst du prüfen. Stehen die in der neuen Version bereits Verfügung? Muss ich gegebenenfalls drauf warten?
Also wenn wir so über Drupal 9 nachdenken – es ist jetzt dieses Jahr an den Start gegangen – sind die Module bereits kompatibel? Und deswegen gab es ja auch eine Initiative, die bereits frühzeitig, bevor der offizielle Drupal 9 Launch kam, die gesagt hat: Okay, wir wollen jetzt schon anfangen, die Module zu migrieren und zwar die ersten wichtigsten 100, dann die wichtigsten Tausend.
Und da gab es eine riesengroße Community Initiative, die sichergestellt hat, dass alle wichtigen Module bereits zum Start von Drupal 9 verfügbar sind, damit die Leute einen nahtlosen Übergang haben und nicht erst das erste Halbjahr abwarten müssen, bis es dann mal nachgezogen wird.
Die Schwierigkeit auf der anderen Seite ist aber: Diese Module, die erzeugen Komplexität und nur weil das Modul im neuen System verfügbar ist, heißt es nicht, dass es auch kompatibel ist mit der neuen Version des anderen Moduls.
Dementsprechend muss man sich experimentell annähern. Da hilft all die Theorie nicht und das ist auch das, was Manuel eben sagte, man kann es so gut planen, wie man möchte. Die Grundlagen bleiben immer die gleichen. Man muss analysieren.
Man muss entscheiden, wie die Daten transferiert werden sollen. Wir müssen uns einen Zeitplan überlegen, aber nichts führt an der Praxis vorbei.
Das heißt, wir müssen das Prototypische implementieren, um zu wissen, was wirklich auf uns zukommt. Und ich glaube, der erste Migrations Prototyp ist immer der entscheidende Punkt für den großen Aha-Effek in jeder Projekt-Migration, wo man dann halt merkt „Oh, das wird nicht funktionieren. Und das wird nicht funktionieren.“ In der Regel sind das halt genau die Komponenten, die nicht Inhalte sind, sondern wo es dann die Kombinationen sind, wo ich eine User Experience mit Custom Modul eingebaut habe, dies so nicht 1:1 portieren kann.
Der Klassiker in dem Umfeld war damals Drupal 6 – Panel Module. Da konnte man sich wunderbare Layouts aufbauen, Inhalte platzieren, und dann hat das Panel Modul Team sich auch die Mühe gemacht, eine Migration dafür anzubieten. Also quasi von der Drupal 6 auf die Drupal 7 Version. Dann stellte sich aber heraus, dass auf einmal neue Trends aufgekommen sind. Dann kamen andere Layout Komponenten. Dann hat man angefangen z.B. manche haben damals mit der Play Suite komplexe Modelle gebaut oder mit Paragraphs, nur um ein paar zu nennen.
Dementsprechend – wenn ich jetzt mit der neuen Drupal Version zum Beispiel Paragarphs verwenden möchte, und es im alten System gar nicht drin habe, dann muss ich mir halt überlegen, dass ich auch meine Redakteure mit an Bord nehme. Ich kann die Kern-Inhalte, die Basis Komponenten, die sogenannten Entities in Drupal oder eure Inhalts-Typen transferieren. Aber am Ende muss immer noch ein Redaktionsteam drüber schauen, sagen „OK Ja, die migrierte Seite sieht gut aus für einen Menschen. Sie enthält die Komponenten, die ich haben möchte, die Orchestrierung vom Layout“ und das ist meistens der Teil, der relativ viel händische Arbeit erfordert, aber weniger für den Programmierer, sondern wirklich für die Redakteure, die mit dem System arbeiten.
Und das darf man natürlich auch nicht unterschätzen. Und auch das macht natürlich so eine Continuous Migration schwierig.
Wenn wir halt überlegen, dass wir auf den Knopf drücken wollen, und dann hoffentlich alles funktioniert. Das geht nur in den wenigsten Fällen.
Und oft ist es dann so, dass gerade im letzten Monat, bevor die Umstellung kommt, die Redakteure mit zwei Systemen arbeiten, um sicherzustellen, dass alle modernen relevanten Layouts im neuen System auch funktionieren.
Manuel, wie ist denn deine Erfahrung gewesen bei der Umstellung bei deinen Projekten? Wie viel Zeit würdest du normalerweise für eine Migration einplanen oder schätzen?
Manuel Pistner
Da passt die Antwort „Es kommt drauf an“. Tatsächlich ist es so. Es kommt drauf an, wie viel Custom Code hast du, wie viele Inhalte hast du und wie weit ist das Drupal System mit anderen Anwendungen integriert?
So, wenn ich jetzt mal sagen würde: Eine einfache Drupal Seite, die wirklich nur aus Inhalten besteht, nicht integriert ist, kein Custom Code hat, und keine Module gehackt wurden, da würde ich mal sagen, das kriegt man in einem Monat wahrscheinlich hin. Da würde ich jetzt kein großes Problem sehen.
Wenn du aber eine komplexerer Seite hast, die vielleicht auch Funktionalitäten wie einen Warenkorb hat, der dann wieder integriert ist mit einem CRM System oder einem ERP-System – da spreche ich jetzt nur über einfache Migration, also vom Warenkorb in das CRM System, nicht bidirektional – da würde ich mal sagen, ist unter drei Monaten keine Chance, realistischer sind 6 Monate.
Und naja, bei den ganz großen Seiten – mehrsprachig, verschiedene Redaktionsteams, vielleicht mehrere Sprachen, mehrere Länder und dann darauf basierend unterschiedliche Inhalte plus Integration – dann kann auch so eine Migration, die ja dann ein kompletter Relaunch ist, wenn wir von 7 auf 9 sprechen, dann kann das auch mal ein dreiviertel Jahr bis Jahr dauern.
Würdest du es auch so sehen? Oder bist du deutlich schneller?
Rouven Volk
Ja, gerade wenn wir jetzt über so Sachen wie Commerce nachdenken. Also, es gibt ja in Drupal die, ich nenne es mal die Commerce Familien, also ein Speed, die diverse Commerce Module mitbringt. Und auch da hat sich ja sehr, sehr viel getan. Also die haben ja quasi damals mit dem Relaunch auf Drupal 8 eine komplett neue Modulwelt geschaffen.
Die haben alles nochmal neu geschrieben. Und jetzt habe ich das Glück gehabt: Ich hatte bisher noch kein Projekt machen müssen, indem ich hätte Commerce migrieren müssen. Aber die Umstellung ist natürlich eine große, weil wenn alle Module umgeschrieben wurden, zu überlegen, „wie kann ich die alten Produkte quasi in die neue Welt portierenß“, das ist natürlich eine große Herausforderung.
Denn dann reden wir nicht nur über Daten, die migriert werden, sondern reden wir halt auch über ganz essentielle Business Prozesse, die daran hängen.
Da hängt meine Rechnungs-Generierung mit dran. Ich hab die Nachweispflichten, wie welche Sachen zusammengerechnet werden. Ich muss darüber nachdenken, wie ich z.B. die Umstellung mit dem Backend Systemen realisieren kann, hängt vielleicht eine Payment Provider mit dran? All diese Sachen, die da mitreinspielen. Die müssen natürlich berücksichtigt werden.
Ich glaube, der große Segen ist, für die Unternehmen, die bereits im Hintergrund ein sogenanntes Produkt Informationsmanagement System haben, ein PIM System oder DAM System, wo man halt weiß: „Informationen sind im dedizierten System gespeichert, meine Website kann diese konsumieren.“
Weil in dem Fall kann ich hingehen und sagen „Ich baue jetzt mit Drupal 9 einfach alles neu. Ich baue meine Nutzererfahrung mit Drupal 9, aber die Inhalte ziehe ich mir dynamisch über APIs.
Das ist gerade bei komplexen Projekten – und Commerce ist dafür ein gutes Beispiel – oft der einfachere Weg, als wenn ich hingehe und sage „Okay, ich habe alles in meinem Drupal drin, wie kriege ich das jetzt von der Version 7 auf Drupal 9 migriert?“
Manuel Pistner
Ja, das ist ein super wichtiger Punkt, den kann man, glaube ich, nicht genug unterstreichen, wenn man so einen monolithischen Drupal Klumpen hat, wo wirklich alles drin ist, von Commerce über CRM.
Es gibt ja für alles Module, und früher hat man es auch so gemacht. Ich meine, ich hab auch ERPAL entwickelt, über, keine Ahnung, 4 Jahre, wo wirklich alles drin war. Alles in einer Installation.
Es ist super komplex und es ist meistens auch nur so durchschnittlich gut von der Usability – verglichen mit Tools, die halt wirklich für einen bestimmten Usecase gebaut sind.
Ich glaube, da geht der Trend ganz klar hin, wenn man diese Microservices Bewegung sieht, dass man einzelne Tools und Komponenten, die in der Cloud leben, die auf eine Sache spezialisiert sind, sei es jetzt Shopify oder irgendein anderes Commerce Tool – die würde ich spezialisiert nutzen, immer darauf achten, dass sie dokumentierte, standardisierte Schnittstellen haben.
Und dann würde ich alle diese Inhalte aus den Tools in mein Drupal ziehen oder von Drupal in die Tools pushen. Also wirklich – statt alles in Drupal zu packen – über einzelne, verteilte Komponenten und in einem integrierten System arbeiten. Dann ist es auch einfacher, wenn ich Drupal migrieren muss.
Dann muss ich nicht mein Commerce neu bauen, nicht mein CRM und mein ERP und alles neu bauen, weil alles in Drupal drin ist. Sondern ich habe diese Komponenten, die sind in sich homogen und konsistent.
Und ich kann mein Drupal System – und Drupal ist ein CMS System letztendlich out of the box -in der Cloud skalierbar, flexibler, unabhängig und mit Sicherheit auch stabiler nutzen.
Rouven Volk
Manuel, du hast es ja gerade schön gesagt, dieses Zusammenspiel von den unterschiedlichen Systemen. Die Sachen auch aus dem CMS rausholen in dedizierte Systeme. Das ist auch eine Methode oder eine Strategie für Migrationen in der Zukunft. Drupal ist klassischerweise ein CMS System.
Aber wir können es ja auch nutzen um z.B. ein dediziertes Drupal zu haben, was nur unsere Inhalte speichert. Nehmen wir ein Alt-System, ein Drupal 7 oder ein irgendein CMS System, aus dem exportieren wir jetzt die Daten in eine neue Drupal 9 Installation. Und die Aufgabe dieser Drupal 9 Installation wird es nichts sein, schöne Seiten zu rendern, sondern lediglich Inhalte zu verwalten für Redakteure.
Was heißt, da drin werden Inhalte gespeichert, und dann aktivieren wir das Schnittstellen Modul, was uns erlaubt, diese Daten rauszuziehen. Und dann sind wir wirklich für die Zukunft flexibel aufgestellt, weil dann kann ich eine weitere Drupal Seite oder irgendein anderes System, was die Inhalte konsumieren kann, aufsetzen und nutze das für die Orchestrierung.
Das heißt, ich baue meine Layouts in der zweiten Installation und kann da ein schönes modernes System aufbauen lassen.
Kann mich aber auch für einen komplett anderen Pfad entscheiden, während ein anderes Team die Migration rein in dieses Content System macht. Und damit schaffe ich mit Drupal genau das, was ich im Bereich mit Medien mit einem DAM realisiere. Oder für Kundendaten mit einem CRM System.
Ich habe dann ein gezieltes System für den Inhalt. Und das ist sehr mächtig, denn ich kann das komplett auf das Ausspielen von Inhalten über eine API automatisieren.
Ich kann es gut mit einem CDM System kombinieren, was mir die statischen Assets speichert und beschleunigt. Und damit bin ich halt komplett flexibel. Ich kann jetzt dieselben Inhalte in meiner Webseite nutzen, die ich dann aber auch zum Beispiel in einer nativen App benutze oder auf irgendeinem anderen Kanal.
Und damit brauche ich dann halt auch nicht mehr meine Inhalte migrieren, denn ich habe sie jetzt in einem Upgrade-fähigen System drin mit Drupal 9 und kann vorne mein Frontend immer beliebig austauschen, so wie ich es halt im Laufe der Zeit brauche.
Und das ist für mich so ein bisschen „der heilige Gral“ der Content Migration.Also aufhören, diese großen, monolithischen Migrationen zu machen und wirklich dedizierte Systeme zu schaffen, aus denen ich mich dann per Schnittstelle bedienen kann.
Die Zukunft ist sowieso höchst personalisiert. Wenn wir heute Projekte planen, planen wir keine statischen Seiten mehr. Wir wollen Personalisierung, wir wollen relevante Inhalte. Und das schaffe ich halt nur, wenn ich ein System schaffen, wo ich mir die Sachen bei Bedarf hinzuziehen kann.
Ich glaube, das ist ein ganz, ganz wichtiger Aspekt, wenn wir jetzt darüber nachdenken, in welche Richtung die Reise gehen soll. Oder ob ich halt wirklich das, was ich jetzt die letzten zehn Jahre gemacht habe, auch die nächsten zehn Jahre machen möchte.
Manuel Pistner
Ja, das ist ein ganz wichtiger Punkt. Das, was du gerade beschrieben hast, ist, zusammengefasst, was man unter dem Begriff „Decoupled Drupal“ versteht. Also, dass du wirklich dein Frontend und alle Komponenten, die auf den Content von Drupal im Hintergrund über die Schnittstelle zugreifen, dass du die alle dezentral hast, über andere Services, über ein eigenes Frontend, über Mobile Apps, über irgendwelche Multi Channel, Omni Channel, Devices, was auch immer.
Und ich würde da gern noch eine Analogie nutzen, weil uns jetzt Corona ja allen gezeigt hat, wie wir denn Remote, also auch verteilt, arbeiten können. Ich glaube, es besteht in der Erfahrung und in dieser Art, dezentral zu denken, auch ein großer Ansatz, die Drupal Migration erheblich zu beschleunigen.
Gerade wenn man komplexe Installation hat, dann reicht es nicht, einfach Drupal Entwickler zu haben. Dann brauchst du einen Business Analyst. Du brauchst einen UX Designer, du brauchst einen System Architect, der die ganzen Schnittstellen von der Architektur her kennt. Du brauchst Qualitätssicherung, du brauchst automatisierte Tests. Et cetera. Wenn du wirklich solide, stabile Software entwickeln willst und stabile Systeme, die auch kontinuierlich ohne große Bugs weiterentwickelt werden können. Und die meisten Unternehmen, ganz egal wie groß sie sind, haben eigentlich genau diese ganzen Experten, die sie jetzt meistens schnell brauchen, gar nicht bei sich alle im Team.
Aber was uns in die Hände spielt, ist natürlich der große Freelancer Trend und der Remote Work Trend. Und so kann man sich nämlich auch on demand Virtuelle Teams aufbauen aus lokalen Mitarbeitern und Freelancer. Dann sind es hybride Teams.
Um eben immer die richtigen Experten mit den richtigen Skills, den richtigen Erfahrungen und auch der richtigen Kapazität für die Migration zu haben. Denn jeder kennt Projekte, die laufen eigentlich nicht immer gleichmäßig durch, sondern am Anfang ist meistens relativ wenig zu tun.
Dann gräbt man sich tiefer in die Details rein, die einem dann zeigen, was denn noch tatsächlich alles zu tun ist. Und dann hat man Last, Peaks und muss sein Team skalieren, entweder mit neuen Skills oder mit mehr Kapazität, damit man eben im Zeitplan bleiben kann.
Und ja, ich glaube, dass nicht nur die System Architektur in Zukunft dezentral ist, sondern auch wie die Teams arbeiten, dass es Festangestellte und Freelancer sind, global verteilt.
Und tatsächlich ist ja Drupal auch genau so dezentral in der Community entwickelt worden. Es sind ja alles „invented elsewhere“. Also Leute, die irgendwo sitzen, die sich wahrscheinlich nur selten persönlich sehen und die aber durch den hohen Teil an Eigenmotivation so ein großartiges Stück an Software entwickelt haben.
Rouven Volk
Wenn wir diesen Gedanken jetzt einen Schritt weitertragen und uns anschauen, wie die Drupal Community funktioniert – dezentral, also dass viele Leute am selben Projekt arbeiten und das komplett Zeit unabhängig, Updates kommen, jeden Tag laufen hunderte von Commitments auf Drupal.org in die Repositories der einzelnen Projekte – in dem Moment, wo ich mir ein Drupal bei mir installiere und es automatisieren, sodass es jeden Tag Updates bekommt, dann hab ich hier kein eigenständiges Projekt mehr, sondern dann bin ich Teil eines riesengroßen globalen Projektes.
Das heißt, ich habe kontinuierliche Innovation, die auch immer wieder jeden Tag bei mir ins Büro reinströmt oder in mein Projekt reinströmt.
Und ich muss mich entscheiden, wie viel von dem Ganzen ich letztendlich akzeptieren möchte, ob ich mich jetzt isoliere und sage „Nee, ich mache jetzt meinen Fix-Scope, ich will keine Veränderungen drin haben und pflege das“ – oder ob ich mich halt dafür öffne und sage „Okay, wenn ich ein dezentrales System habe, warum soll ich einen zentralen Monolithen damit aufbauen und nicht eigentlich das, was die Community mir vorgibt, für mich als Unternehmen, als Projekt Owner, adaptieren und selber leben?“
Bei dieser Flexibilität. Genau wie Manuels beschrieben hat.
Ich kann jederzeit mit jeglicher Technologie und jedem Menschen zusammenarbeiten. Die Methodik ist schon da. Sie liegt vor uns. Wir müssen sie nur anwenden. Und das ist etwas, was etwas Umdenken erfordert.
Aber ich glaube auch: Das Ausbrechen aus diesen Migrations-Gefängnis – alle fünf bis zehn Jahre einen Relaunch machen – das ist etwas, das ist sehr, sehr klassisch.
Man kann auch verstehen, wo es herkommt. Es kommt nämlich aus einer Welt, wo wir noch kein Internet hatten. Es kommt aus einer Welt, wo wir per CDs oder Disketten Softwareupdates verschickt haben. Da musste alles perfekt sein. Und diese alten Denkweisen sind heute immer noch in vielen Projekten zu finden. Und dementsprechend, wenn wir uns darauf öffnen, dann muss ich mir um die Migration keine Sorgen mehr machen, weil das haben wir jetzt gesehen mit Drupal 8 zu Drupal 9.
Es ist ein kontinuierlicher Prozess gewesen. Und die Umstellung von Drupal 8 auf Drupal 9 war lediglich eine kleine Installation des neuen Kerns, das Update der Module. Ich musste keine Inhalte mehr schnell transferieren oder migrieren, weil diese bereits standardisiert wurden. Das heißt, man hat diese Entity API geschaffen. All das, was ich früher händisch auseinandernehmen musste, das wurde jetzt automatisiert – und es ist dementsprechend ein sehr, sehr einfacher Umstieg.
Und ich glaube, das ist genau das, wo die Reise auch hingehen sollte mit allen Systemen. Dass man halt über offene Standards nachdenkt und nicht über irgendwelche Silos oder proprietären Lösungen, die man am Ende nicht migrieren kann.
Und deswegen geht man halt auch als Trend weg davon, dass man viele Custom Modules baut, sondern man eher dahingeht: Wie kann ich mit bestehenden Sachen etwas orchestrieren und ich passe sie nur oberflächlich an? Oder ich passe sie gar nicht an, sondern ich betreibe das System so wie es ist, halte es so pur wie möglich und baue meine Frontends komplett unabhängig davon und baue davon ganz viele, die alle denselben Datenstamm nutzen in der Zentrale. Und trenne quasi meine Web Application von dem, was die Redakteure machen.
Manuel Pistner
Da in Drupal ja wirklich Leute aus der ganzen Welt – ich weiß gar nicht wie viele tausende Leute zu dem Drupal Code inklusive der Module beitragen – dass das trotzdem funktioniert, ist ja für jeden, der im Büro sitzt und glaubt, dass Arbeit nur funktioniert, wenn alle ständig im Büro sind und kommunizieren, für den ist es ja ein wahres Wunder.
Aber was sorgt dafür, dass es funktioniert? Das sind die Standards, die für Klarheit sorgen, nämlich für Klarheit, wie der Beitrag von jedem einzelnen zu dem großen Ganzen zusammengetragen wird und dann was Größeres entsteht, als das, was jeder Einzelne macht.
Und das ist ja auch genau der Sinn von wirklich hoch performanten Remote Teams, die eben auch Struktur haben und wissen, wie sie arbeiten, die klare Verantwortungen haben und Kollaboration strukturiert und asynchron verlaufen kann und nicht naja, wie man es halt im Büro gewohnt ist. Die ganze Zeit kommunizieren, die ganze Zeit fragen, Kollegen unterbrechen, weil keiner Klarheit hat und keiner weiß, was eigentlich gerade getan werden muss.
Dann wäre Drupal niemals da, wo es heute ist, sondern es sind eben genau die Standards, die du eben erwähnt hast, Rouven, die dafür sorgen, dass so viele Leute auf der ganzen Welt zu einem System beitragen können und ein gemeinsames Ziel verfolgen können.
Rouven Volk
Und das ist natürlich auch genau das, was auch schon in den Achtzigern an den Universitäten gelehrt wurde.
Was ist denn Digitalisierung? Standardisierung, Automation und Integration. Der Heilige Gral, der Dreisatz der Digitalisierung.
Wenn wir das berücksichtigen in unseren Projekten, dann funktioniert es einfach. Und das hat dieses Projekt unter anderem bewiesen.
Und wir können es auch in vielen anderen Bereichen sehen, egal ob es Drupal ist oder eine andere Technologie, die oben „draufgeklebt“ wird. Am Ende ist es nur ein Brand. Und wir müssen halt schauen, wie wir die Themen, die uns als Projekteignern beschäftigen, die für uns wichtig sind, wenn wir in die Zukunft gehen wollen, dann müssen wir halt die Prioritäten richtig setzen.
Am Ende kommt es nicht darauf an, wer hat das Schönste, sondern „wer hat seine Daten nicht im Griff?“.
Das ist das, was uns immer wieder verlangsamen wird.
Johanna Anthes
Ich hätte wirklich nicht gedacht, dass unser Interview, unser Gespräch hier von „Was ist denn überhaupt Drupal Migration?“
Zu „im Grunde genommen ist das der absolute Pionier für Remote Work, New Work gewissermaßen und einer Remote Transformation!“
Das heißt, jeder, der an der Migration jetzt im ersten Moment zu knabbern hat, sollte das tatsächlich oder kann es dadurch ja eher als Chance sehen, um sich genau diesen Themen öffnen zu können.
Und zwar mit einem riesen Netzwerk, mit einem geballten Rahmen an Strukturen, Workflows, Modulen, Prozessen. Gut!
Rouven Volk
Gut zusammengefasst.
Johanna Anthes
Na, dann würde ich sagen, das ist ja ein perfektes Ende.
Das heißt: Drupal Migration sollte eigentlich mit einem großen Lächeln angetreten werden, ist der perfekte Einstieg, um für die Zukunft gewappnet zu sein. Und zwar step by step.
Nicht in einem Schlag, sondern Schritt für Schritt. Mit den entsprechenden Tipps, Best Practices und Workflows.
Ich danke euch für euer Wissen, dass ihr das mit uns geteilt habt und freue mich auf jeden Fall, wenn daraus noch weitere Fragen tiefer entstehen, bearbeitet werden, wir noch Einiges zusammenpacken in die Materialien, die hier rauspurzeln – und freue mich auf das nächste Mal, wenn wir tiefer in die Drupal Welt einsteigen.
Manuel Pistner
Vielen Dank!
Rouven Volk
War mir eine Freude, dabei zu sein!
Suchen Sie objektive Beratung zu Ihrem Drupal-Projekt?
Zukunftsfähigkeit, Sicherheit, Integrationsfähigkeit, Flexibilität – ja, das sind die großen Vorteile von Drupal in webbasierten Projekten.
Die Herausforderung ist, dass Drupal-Projekte oft in einer unübersichtlichen Menge an Anforderungen und (oftmals nutzlosen) Daten versinken.
Die Folge: Viele Unternehmen nutzen weiterhin veraltete Prozesse und verbrennen dadurch bares Geld.
Vermeiden Sie die klassische „Technologie-Baustelle“ in Ihrem Drupal-Projekt. Wir zeigen Ihnen persönlich, wie Ihr Drupal-Projekt erfolgreich wird!
