Systemwechsel: der Aufwand steckt nicht in den Inhalten
Texte und Bilder sind an einem Tag umgezogen. Templates, Rechtemodell, Adressstruktur und die Gewohnheiten der Redaktion sind es nicht, und genau daran hängt der Zeitplan.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Migrationsangebote rechnen den billigsten Posten aus und lassen die teuren offen
In fast jedem Angebot für einen Systemwechsel steht eine Zeile Migration der Inhalte mit einer Zahl daneben. Diese Zahl ist meistens sogar richtig, denn Texte und Bilder umzuziehen ist ein Skript und ein Tag zum Nachsehen. Was daneben nicht steht: das Template, das im Zielsystem neu entsteht, die Liste der Inhaltselemente, die jemand festlegen muss, das Rechtemodell, die vollständige Karte der alten Adressen und die Schnittstellen, die am alten Auftritt hängen, also Formulare, Newsletter, Suche und Auswertung.
Teuer wird das nicht durch die Höhe der Rechnung, sondern durch die Reihenfolge. Der Stichtag steht früh im Kalender, weil eine Kampagne daran hängt, die Adressliste wird auf danach vertagt, und in der Woche nach dem Umschalten sucht jemand in den Zugriffsprotokollen nach Fehlerseiten, statt sie vorher zu vermeiden. Die Sichtbarkeit, die dabei wegbricht, kommt nicht durch bessere Texte zurück, sondern erst, wenn die Weiterleitungen stehen, die von Anfang an hätten stehen sollen.
Der zweite wiederkehrende Fehler ist der Auftrag, den alten Auftritt eins zu eins nachzubauen. Damit wandern auch die Seitentypen mit, die seit Jahren niemand mehr anlegt, und das Zielsystem arbeitet gegen euch, weil sein Modell anders geschnitten ist als das, was ihr nachbaut. Ein Wechsel ist der einzige Moment, in dem sich Seitentypen und Inhaltselemente ohne Diskussion streichen lassen, und wer ihn verstreichen lässt, zahlt für die Altlasten ein zweites Mal.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die beiden Systeme an sechs Fragen aus der Umsetzung
Die Urteile gelten für den Wechsel und nicht für das System an sich. Ein schlechtes Urteil heißt hier, dass dieser Posten in dieser Richtung die meiste Zeit frisst, unabhängig davon, ob die Systemwahl richtig war. Lies die Tabelle deshalb zweimal, einmal für das System, aus dem ihr herauswollt, und einmal für das, in das ihr hineinwollt.
WordPress
als Ausgangssystem gut auszulesen, als Zielsystem in Tagen aufgebaut, mit einem erheblichen Teil der Konfiguration in der Datenbank
TYPO3
als Ausgangssystem nur über die Datenbank vollständig zu greifen, als Zielsystem mit eigenem Sitepackage, dafür mit Konfiguration in Dateien
| Entscheidungsfrage | WordPress | TYPO3 |
|---|---|---|
| Wie kommen die Inhalte aus dem alten System heraus? | Stärke Der Kern bringt ein Exportwerkzeug mit, das Beiträge, Seiten und die Verweise auf Medien als XML ausgibt, dazu eine REST-Schnittstelle für den gezielten Zugriff. Für ein Skript, das Inhalte in ein anderes System schreibt, ist das eine brauchbare Grundlage. | Kommt darauf an Der Kern kann Inhalte exportieren, aber in einem eigenen Format und für den Weg von TYPO3 nach TYPO3. Wer in ein anderes System umzieht, liest in der Regel direkt aus der Datenbank und muss dabei Übersetzungen, Versionen und Arbeitsbereiche auseinanderhalten. |
| Was passiert mit den bestehenden Adressen? | Kommt darauf an Für einen geänderten Kurznamen leitet der Kern noch selbst weiter. Ein Verzeichnis, in das ihr mehrere tausend Adressen aus einem Altsystem eintragt und pflegt, gehört nicht dazu und kommt über eine Erweiterung oder über den Webserver. | Stärke Weiterleitungen sind Teil des Kerns, mit eigener Verwaltung im Backend, und beim Ändern eines Seitenpfads entsteht der Eintrag automatisch. Für den Umzug lässt sich die Liste der alten Adressen einspielen. |
| Wie viel Arbeit steckt im neuen Template? | Stärke Ein gekauftes oder angepasstes Theme steht in Tagen, und der Blockeditor bringt das Markup für die übliche Auszeichnung mit. Der Preis ist, dass ihr das ausgelieferte Markup nur begrenzt in der Hand habt. | Schwäche Vor der ersten Seite steht ein eigenes Sitepackage mit Fluid-Templates, TypoScript und der Festlegung, welche Inhaltselemente es geben soll. Das ist ein Projekt für sich und der größte einzelne Posten in jedem Wechsel Richtung TYPO3. |
| Wie führt ihr den Umbau durch Git, Testumgebung und Livebetrieb? | Schwäche Ein erheblicher Teil der Konfiguration liegt in der Datenbank, von Menüs über Widgets bis zu den Einstellungen der Erweiterungen. Ein Abgleich zwischen Testumgebung und Livebetrieb ist damit nie ein reiner Dateiabgleich und braucht Disziplin oder zusätzliche Werkzeuge. | Stärke Installation und Erweiterungen laufen über Composer, die Konfiguration der Website und TypoScript liegen als Dateien im Repository. Was Aussehen und Verhalten bestimmt, lässt sich damit versionieren und wie Code ausrollen. |
| Wie gut haltet ihr das ausgelieferte Markup barrierefrei? | Kommt darauf an Überschriftenstruktur, Beschriftungen und Fokusreihenfolge entstehen im Theme und in den Blöcken. Ein gutes Theme nimmt euch viel ab, ein schlechtes liefert Markup, das ihr nur über Filter wieder einfangt. | Kommt darauf an Das Markup kommt aus euren eigenen Fluid-Templates. Ihr habt es damit vollständig in der Hand und tragt genauso vollständig die Verantwortung dafür, einschließlich der Ausgabe der mitgelieferten Inhaltselemente. |
| Was kostet der Betrieb nach dem Wechsel? | Kommt darauf an Häufige kleine Aktualisierungen, vieles davon automatisch. Der Aufwand entsteht bei den Erweiterungen: Jede braucht eine verantwortliche Person und die Frage, ob der Auftritt ohne sie noch funktioniert. | Kommt darauf an Innerhalb einer LTS-Version unspektakulär, beim Sprung auf die nächste ein geplantes Vorhaben, weil eigene Templates und Erweiterungen mitziehen müssen. Dafür wisst ihr Jahre vorher, wann es ansteht. |
Wie kommen die Inhalte aus dem alten System heraus?
Der Kern bringt ein Exportwerkzeug mit, das Beiträge, Seiten und die Verweise auf Medien als XML ausgibt, dazu eine REST-Schnittstelle für den gezielten Zugriff. Für ein Skript, das Inhalte in ein anderes System schreibt, ist das eine brauchbare Grundlage.
Der Kern kann Inhalte exportieren, aber in einem eigenen Format und für den Weg von TYPO3 nach TYPO3. Wer in ein anderes System umzieht, liest in der Regel direkt aus der Datenbank und muss dabei Übersetzungen, Versionen und Arbeitsbereiche auseinanderhalten.
Was passiert mit den bestehenden Adressen?
Für einen geänderten Kurznamen leitet der Kern noch selbst weiter. Ein Verzeichnis, in das ihr mehrere tausend Adressen aus einem Altsystem eintragt und pflegt, gehört nicht dazu und kommt über eine Erweiterung oder über den Webserver.
Weiterleitungen sind Teil des Kerns, mit eigener Verwaltung im Backend, und beim Ändern eines Seitenpfads entsteht der Eintrag automatisch. Für den Umzug lässt sich die Liste der alten Adressen einspielen.
Wie viel Arbeit steckt im neuen Template?
Ein gekauftes oder angepasstes Theme steht in Tagen, und der Blockeditor bringt das Markup für die übliche Auszeichnung mit. Der Preis ist, dass ihr das ausgelieferte Markup nur begrenzt in der Hand habt.
Vor der ersten Seite steht ein eigenes Sitepackage mit Fluid-Templates, TypoScript und der Festlegung, welche Inhaltselemente es geben soll. Das ist ein Projekt für sich und der größte einzelne Posten in jedem Wechsel Richtung TYPO3.
Wie führt ihr den Umbau durch Git, Testumgebung und Livebetrieb?
Ein erheblicher Teil der Konfiguration liegt in der Datenbank, von Menüs über Widgets bis zu den Einstellungen der Erweiterungen. Ein Abgleich zwischen Testumgebung und Livebetrieb ist damit nie ein reiner Dateiabgleich und braucht Disziplin oder zusätzliche Werkzeuge.
Installation und Erweiterungen laufen über Composer, die Konfiguration der Website und TypoScript liegen als Dateien im Repository. Was Aussehen und Verhalten bestimmt, lässt sich damit versionieren und wie Code ausrollen.
Wie gut haltet ihr das ausgelieferte Markup barrierefrei?
Überschriftenstruktur, Beschriftungen und Fokusreihenfolge entstehen im Theme und in den Blöcken. Ein gutes Theme nimmt euch viel ab, ein schlechtes liefert Markup, das ihr nur über Filter wieder einfangt.
Das Markup kommt aus euren eigenen Fluid-Templates. Ihr habt es damit vollständig in der Hand und tragt genauso vollständig die Verantwortung dafür, einschließlich der Ausgabe der mitgelieferten Inhaltselemente.
Was kostet der Betrieb nach dem Wechsel?
Häufige kleine Aktualisierungen, vieles davon automatisch. Der Aufwand entsteht bei den Erweiterungen: Jede braucht eine verantwortliche Person und die Frage, ob der Auftritt ohne sie noch funktioniert.
Innerhalb einer LTS-Version unspektakulär, beim Sprung auf die nächste ein geplantes Vorhaben, weil eigene Templates und Erweiterungen mitziehen müssen. Dafür wisst ihr Jahre vorher, wann es ansteht.
Was passt wann
- Wenn ihr von WordPress nach TYPO3 wechselt
- legt das Sitepackage als eigenes Vorhaben neben den Umzug und beginnt sofort mit der Adressliste, denn beide liegen auf dem kritischen Pfad und beide brauchen Entscheidungen aus der Fachabteilung.
- Wenn ihr von TYPO3 nach WordPress wechselt
- steckt der Aufwand im Auslesen der Datenbank samt Übersetzungen und in einem Rechte- und Freigabemodell, das ihr im Zielsystem nachbauen müsst, statt es mitzunehmen.
- Wenn der Auslöser ein unübersichtlicher Auftritt ist und nicht das System
- verschiebt der Wechsel das Problem nur. Dann sind das Ausmisten der Erweiterungen und ein neues Template der kürzere Weg, und er kostet einen Bruchteil.
Fünf Posten, die in Migrationsangeboten regelmäßig fehlen
- 01 Die Inhalte sind der billigste Posten, meist ein Skript und ein Tag zum Prüfen.
- 02 Das Template entsteht neu, denn kein Theme überlebt den Wechsel des Systems.
- 03 Jede alte Adresse braucht ein Ziel, auch Bilder und PDF-Dokumente.
- 04 Das Rechtemodell wird neu geschnitten und nicht aus dem Altsystem kopiert.
- 05 Formulare, Newsletter, Suche und Auswertung hängen als eigene Aufgaben daran.
Was ihr nach dieser Rechnung belastbar planen könnt
Ein Wechsel wird planbar, sobald ihr ihn in Posten zerlegt, die sich einzeln zählen lassen. Vier davon kann euch niemand abnehmen, weil sie Entscheidungen sind und keine Technik: welche Inhaltstypen es künftig gibt, wer was bearbeiten darf, welche alte Adresse wohin zeigt und wann das alte System aufhört, die Wahrheit zu sein.
Den Bestand zählen, bevor jemand schätzt
Zählt Seiten, Inhaltselemente je Typ, Dateien in der Ablage, Sprachen und Formulare. Diese fünf Zahlen sind die Grundlage jeder Schätzung, und sie zeigen fast immer, dass ein Drittel der vorhandenen Typen nur ein einziges Mal benutzt wurde.
Die Adressliste vor dem Umbau ziehen
Ein Crawl des laufenden Auftritts, der Export aus der Search Console, die Zugriffsprotokolle des Webservers und die Sitemap ergeben zusammen die Liste. Sie entsteht am Anfang und nicht am Ende, weil ihr Umfang die Dauer des Umbaus mitbestimmt.
Das Template als eigenes Vorhaben führen
Ein Sitepackage in TYPO3 und ein Theme samt erlaubten Blöcken in WordPress sind kein Anhängsel des Umzugs, sondern der größte einzelne Posten. Wer beides in denselben Zeitraum legt wie den Inhaltsimport, verschiebt am Ende beides.
Das Rechtemodell neu schneiden statt zu übertragen
Das gewachsene Modell im Altsystem ist die Summe alter Ausnahmen. Beim Wechsel werden Konten ohnehin neu angelegt, also beschreibt ihr vorher in einer Tabelle, welche Gruppe welchen Bereich bearbeiten darf, und setzt nur diese Tabelle um.
Die Schnittstellen einzeln auflisten
Formulare mit ihren Empfängern, Newsletter, Auswertung, interne Suche, Kartendienst, Anmeldung über ein Fremdsystem. Jede dieser Verbindungen ist eine eigene kleine Migration mit eigenem Test, und jede fällt nach dem Umschalten still aus, wenn sie niemand geprüft hat.
Einen Stichtag mit Rückweg festlegen
Ihr braucht ein Datum, ab dem im Altsystem nichts mehr geändert wird, einen letzten Abgleich der Inhalte danach und einen beschriebenen Weg zurück für die ersten Tage. Ohne diesen Rückweg wird jede Kleinigkeit am Umschalttag zur Grundsatzfrage.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was umzieht, was neu entsteht und was verschwindet
Der Umzug zerfällt in drei Gruppen, und nur die erste ist ein Datenproblem. Umziehen lassen sich Texte, Bilder, Dokumente und die Verweise zwischen ihnen. In WordPress liefert das Exportwerkzeug des Kerns dafür eine XML-Datei, in TYPO3 führt der vollständige Weg über die Datenbank, weil Übersetzungen, Versionen und Arbeitsbereiche in eigenen Feldern stehen. In beiden Richtungen schreibt jemand ein Skript, das ein Inhaltselement der einen Welt auf ein Inhaltselement der anderen abbildet, und dieses Skript läuft nicht einmal, sondern so oft, bis eine Stichprobe von dreißig Seiten ohne Nacharbeit durchgeht.
Neu entsteht alles, was den Inhalten Form gibt: das Template, die Liste der erlaubten Inhaltselemente, das Rechtemodell und die Konfiguration. Diese Gruppe ist der eigentliche Umfang des Vorhabens. Der Auftrag, das alte Aussehen pixelgenau nachzubauen, ist dabei der teuerste Weg, weil ihr das Modell des Zielsystems gegen euch arbeiten lasst: In TYPO3 endet das in Inhaltselementen, die eine freie Fläche nachbilden sollen, in WordPress in einem Bausatz aus gesperrten Blöcken, den danach niemand mehr anfassen mag.
Und eine Gruppe zieht gar nicht um: die Benutzerkonten. Passwörter bleiben in der Regel zurück, weil beide Systeme sie in eigenen Verfahren und eigenen Tabellen ablegen, also legt ihr die Konten im Zielsystem neu an und die Redaktion vergibt einmal ein neues Passwort. Das klingt nach einem Ärgernis und ist in Wahrheit die beste Gelegenheit des ganzen Projekts: Rechte, die vor vier Jahren als Ausnahme vergeben wurden, müssen jetzt nicht abgeschafft, sondern nur nicht wieder vergeben werden.
Die Adressliste ist das eine Artefakt, an dem die Sichtbarkeit hängt
Die Liste entsteht aus vier Quellen, weil keine davon für sich vollständig ist: ein Crawl des laufenden Auftritts, der Export der Adressen aus der Search Console über die letzten Monate, die Zugriffsprotokolle des Webservers und die vorhandene Sitemap. Die Sitemap allein reicht nicht, denn genau die Adressen, die intern niemand mehr verlinkt, die aber in Lesezeichen, in fremden Verweisen und im Index einer Suchmaschine weiterleben, stehen dort längst nicht mehr drin. Aus den Protokollen kommen zusätzlich die Dateien, an die im Redaktionssystem niemand denkt.
Danach wird abgebildet, und zwar eins zu eins, wo es geht. Für Seiten ohne Nachfolger gilt: das nächstgelegene Ziel mit derselben Absicht, nicht die Startseite, denn eine Sammelweiterleitung auf die Startseite behandelt eine Suchmaschine wie eine Fehlerseite. In dieselbe Liste gehören die Dateien, also PDF-Dokumente und Bilder mit eigener Adresse. Und die Regeln für den abschließenden Schrägstrich, für Groß- und Kleinschreibung und für Adressen mit Parametern schreibt ihr einmal auf, bevor drei Leute drei Varianten anlegen und sich die Weiterleitungen gegenseitig aufheben.
Eingetragen wird die Liste als dauerhafte Weiterleitung, also mit dem Status 301. In TYPO3 gibt es dafür ein Modul im Backend, das dieselben Einträge verwaltet, die das System beim Ändern eines Seitenpfads selbst anlegt; in Richtung WordPress läuft die Liste über den Webserver oder über eine Erweiterung. Vor dem Umschalten geht ein Skript die alte Adressliste gegen die Testumgebung durch und schreibt zu jeder Adresse den Status auf. Nach dem Umschalten ist die Zahl der Fehlerseiten die eine Kennzahl, auf die in den ersten Tagen jemand täglich schaut.
Das Template ist der größte einzelne Posten
Richtung TYPO3 heißt das Sitepackage: Fluid-Templates für die Seitentypen, TypoScript für die Konfiguration, Backend-Layouts für die Spalten und eine Festlegung, welche Inhaltselemente es überhaupt geben soll. Die entscheidende Frage dabei ist nicht die Gestaltung, sondern diese Liste, denn sie bestimmt, was die Redaktion danach bauen kann und was nicht. Kommt die Liste zu spät, entsteht das übliche Ergebnis: ein Element namens Freier Inhalt, in das alles hineinwandert, und damit genau die Beliebigkeit, gegen die ihr gewechselt seid.
Richtung WordPress steht dieselbe Entscheidung an anderer Stelle, nämlich in der Frage, welche Blöcke erlaubt sind und welche Vorlagen es gibt. Ein gekauftes Theme bringt euch schnell ans Ziel und sein Markup gleich mit, und beides gehört zusammen bewertet: Was ihr an Aufbauzeit spart, holt ihr später über Anpassungen wieder heraus, wenn die Ausgabe nicht zu eurem Auftritt passt.
In beiden Richtungen wird das Markup ohnehin neu geschrieben, und das macht den Wechsel zum günstigsten Zeitpunkt für zwei Dinge, die sonst nie Budget bekommen: eine saubere Überschriftenstruktur mit Beschriftungen und sichtbarem Fokus, und das Streichen der Seitentypen, die niemand mehr benutzt. Zählt vor dem Umbau, wie oft jeder Typ tatsächlich vorkommt. Was unter fünf Vorkommen liegt, wird beim Umzug zu einem allgemeinen Typ zusammengefasst, statt in der neuen Welt ein zweites Mal gebaut zu werden.
Konfiguration in Dateien gegen Konfiguration in der Datenbank
Dieser Unterschied entscheidet, wie der Umbau organisiert werden kann. In TYPO3 liegen Site-Konfiguration, TypoScript und die Definition der Datensätze als Dateien im Repository, und die Installation läuft über Composer. Damit ist der Zielzustand ein Zweig im Versionsverwaltungssystem, der geprüft, zusammengeführt und ausgerollt wird, und die Testumgebung unterscheidet sich vom Livebetrieb nur in den Inhalten. In WordPress liegt ein erheblicher Teil derselben Entscheidungen in der Datenbank, von Menüs und Widgets bis zu den Einstellungen jeder Erweiterung, und damit in derselben Datenbank wie die Inhalte.
Für den Wechsel folgt daraus eine unangenehme Eigenschaft: Ihr könnt in Richtung WordPress nicht gleichzeitig die Konfiguration aus der Testumgebung und die Inhalte aus dem Livebetrieb übernehmen, weil beides in denselben Tabellen steht. Der übliche Ausweg ist ein Inhaltsstopp vor dem Umschalten, dazu WP-CLI für alle Schritte, die sich wiederholen müssen, damit der Aufbau der Zielumgebung ein Skript ist und keine Klickstrecke, an die sich hinterher niemand erinnert.
Legt deshalb vor dem ersten Import schriftlich fest, wo bei euch die Grenze zwischen Inhalt und Konfiguration verläuft, und zwar je System. Ohne diese eine Seite Papier passiert in jedem zweiten Projekt derselbe Unfall: Ein zweiter Import überschreibt die Konfiguration, die zwei Wochen Arbeit war, oder umgekehrt wird eine Datenbank zurückgespielt und nimmt die Inhalte von drei Redaktionstagen mit.
Der Stichtag und die vier Wochen danach
Ein Umschalttag hat vier feste Bestandteile: ein Datum, ab dem im Altsystem nichts mehr geändert wird, ein letzter Abgleich der Inhalte, die zwischen Hauptimport und Stichtag entstanden sind, das Umschalten selbst über die Namensauflösung oder einen vorgeschalteten Server, und das Altsystem, das danach nur noch gelesen und nicht mehr bearbeitet werden kann. Der letzte Punkt ist der wichtigste, denn ein Altsystem, in dem weiter geschrieben wird, erzeugt innerhalb von Tagen zwei Wahrheiten.
In den Tagen danach schaut jemand auf vier Dinge: die Fehlerseiten in den Zugriffsprotokollen, die Meldungen in der Search Console, die Formulare und die Auswertung. Formulare sind dabei der häufigste stille Ausfall, weil sie nach dem Umzug technisch funktionieren, die Nachrichten aber an eine Adresse gehen, die im alten System hinterlegt war. Prüft deshalb nicht, ob das Formular absendet, sondern ob die Nachricht ankommt, und zwar bei der Person, die sie bearbeiten soll.
Das Altsystem bleibt danach noch eine Weile intern erreichbar, weil in den ersten Wochen regelmäßig jemand etwas nachschlagen will, was im neuen Auftritt bewusst nicht mehr steht. Setzt für die Abschaltung ein Datum, sonst läuft es zwei Jahre weiter, wird nicht mehr aktualisiert und ist dann genau die Installation, über die jemand hereinkommt. Ein abgeschaltetes Altsystem mit einem letzten Datenbankabzug im Archiv ist der saubere Abschluss des Vorhabens.
Dazu passende Kurse
Wer nach dem Wechsel selbst pflegen und nicht für jede Kleinigkeit anrufen will, sollte vorher wissen, wie sich eine WordPress-Installation im Alltag pflegen lässt .
In die andere Richtung gilt dasselbe, denn wer den Aufbau aus Seitenbaum, Fluid-Templates und Rechten kennenlernen will, beurteilt ein Migrationsangebot anders als jemand, der nur die Oberfläche kennt.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
Die Schulung ist gerade für Einsteiger oder Entwickler*innen mit eingestaubtem Basiswissen sehr hilfreich.
Ich bin sehr glücklich Franz als Trainer gehabt zu haben. Er hat offensichtlich unglaublich viel Wissen zu den Themen, und schafft es, dieses auch interaktiv und verständlich weiterzugeben.
Häufige Fragen
Was passiert beim Wechsel mit unseren Adressen und der Sichtbarkeit?
Können wir beide Systeme eine Zeit lang parallel betreiben?
Was wird aus den Benutzerkonten der Redaktion?
Was ist mit Formularen, Newsletter und Auswertung?
Passt thematisch dazu
Steht bei euch kein Neubau an, sondern die Frage, ob eine bestehende TYPO3-Installation bleibt oder weicht, dann entscheiden die Posten, die in keinem Migrationsangebot stehen über die Kosten: Datenmodell, Übersetzungen, Rechte und die alten Adressen.
Diese Seite setzt voraus, dass die Systemfrage entschieden ist. Wenn sie bei euch noch offen ist, klärt zuerst welches der beiden Systeme zu einer Redaktion passt , denn davon hängt ab, ob sich der Umzug überhaupt rechnet.
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Webentwicklung-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Den Umzug planen, solange der Stichtag noch verschiebbar ist
Bei cmt lassen sich beide Seiten getrennt lernen, die tägliche Redaktionsarbeit und der Aufbau dahinter, damit im Umzug nicht ausgerechnet die Leute raten müssen, die danach jeden Tag damit arbeiten.