TYPO3-Projekte von Agenturen übernehmen: Checkliste und Vorgehen

Du bekommst einen Anruf. Ein Kunde, den du nicht kennst, braucht Hilfe mit seiner TYPO3-Website. Die bisherige Agentur ist raus. Vielleicht war sie zu teuer, vielleicht hat sie das TYPO3-Geschäft aufgegeben, vielleicht gab es Unstimmigkeiten. Manchmal sind die Gründe auch weniger alltäglich: Ein Freelancer geht in den Ruhestand. Oder jemand verstirbt und hinterlässt Kunden, die plötzlich ohne Ansprechpartner dastehen.

So oder so: Jemand muss das Projekt übernehmen. Und wenn du TYPO3-Integrator, Freelancer oder Teil einer kleinen Agentur bist, bist du vielleicht genau diese Person.

Dieser Artikel zeigt dir Schritt für Schritt, wie du ein fremdes TYPO3-Projekt professionell übernimmst. Dabei gibt es zwei typische Szenarien: Du übernimmst das Projekt für die laufende Betreuung und Wartung, ohne direkt ein Upgrade durchzuführen. Oder du steigst ein und bringst die Instanz im gleichen Zug auf eine aktuelle TYPO3-Version. Beides kommt in der Praxis ständig vor, und die Grenzen sind fließend: Auch bei einer reinen Übernahme kann sich schnell herausstellen, dass ein Upgrade bald nötig wird. Dieser Artikel deckt beide Wege ab. Von der ersten Einschätzung bis zum Wartungsvertrag, praxisnah, ehrlich und ohne Schönfärberei.

Für wen ist dieser Artikel? Für TYPO3-Integratoren, Freelancer, Solo-Selbstständige und kleine Agenturen, die Kundenprojekte übernehmen und eigenständig betreuen. Sowohl organisatorisch als auch technisch. Wenn du in einem größeren Team arbeitest, das eigene Prozesse für Projektübernahmen hat, wirst du hier vielleicht trotzdem Anregungen finden. Aber die Perspektive ist bewusst die des Einzelkämpfers oder kleinen Teams, das alles selbst in der Hand hat.

Das Erstgespräch: Zuhören, fragen, einschätzen

Bevor du irgendetwas Technisches machst, brauchst du ein Gespräch mit dem Kunden. Dabei geht es um zwei Dinge: Informationen sammeln und ein Gefühl für die Situation bekommen.

Frag die Eckdaten ab:

• Welche TYPO3-Version ist im Einsatz?
• Bei welchem Anbieter ist die Seite gehostet?
• Welche Extensions werden verwendet?
• Gibt es individuell angepasste Dinge?

Erwarte nicht, dass der Kunde alles beantworten kann. Viele wissen nicht, welche TYPO3-Version läuft oder was ein Sitepackage ist. Das ist normal. Du wirst dir später selbst ein Bild machen.

Die wichtigere Frage: Was ist passiert?

Warum hat der Kunde keine betreuende Agentur mehr? Die Antwort darauf verrät dir oft mehr über das Projekt als jede technische Analyse.

Es gibt viele legitime Gründe, warum ein Kunde plötzlich ohne Betreuung dasteht. Die bisherige Agentur hat das TYPO3-Geschäft aufgegeben. Ein Freelancer geht in den Ruhestand oder gibt aus persönlichen Gründen Projekte ab. Der Preis war dem Kunden auf Dauer zu hoch. Es hat menschlich nicht gepasst. Das alles kommt vor und ist in der Regel unproblematisch.

Spannend wird es bei der Art und Weise, wie der Kunde darüber spricht. Wenn jemand offen und sachlich erklärt, was passiert ist, ist das ein gutes Zeichen. Wenn der Kunde allerdings anfängt, über die bisherige Agentur zu lästern, über die Qualität der Arbeit herzuziehen oder die Schuld komplett bei der anderen Seite zu suchen, solltest du aufhorchen.

Warnsignale im Gespräch:

• Der Kunde redet abfällig über die bisherige Agentur, ohne konkrete Fakten zu nennen
• Du bekommst den Eindruck, dass nachträglich Leistungen eingefordert wurden, die vorher nie besprochen waren
• Der Kunde versucht bereits im Erstgespräch, den Preis zu drücken oder fragt nach Rabatten, bevor du überhaupt ein Angebot gemacht hast
• Die Erwartungshaltung passt nicht zum Budget ("Ich brauche jemanden, der das Projekt komplett übernimmt, aber eigentlich habe ich kein Budget dafür")
• Der Kunde kann oder will grundlegende Fragen zum Projekt nicht beantworten, obwohl er jahrelang damit gearbeitet hat

Das sind keine absoluten Ausschlusskriterien. Aber sie sind Signale, die du ernst nehmen solltest. Nicht jeder Kunde passt zu dir. Und manchmal hat die bisherige Agentur die Zusammenarbeit aus genau den Gründen beendet, die du im Erstgespräch spürst.

Hör auf dein Bauchgefühl. Wenn sich etwas komisch anfühlt, ist es meistens auch komisch. Du bist nicht verpflichtet, jedes Projekt anzunehmen. Im Gegenteil: Ein Projekt abzulehnen, das dir nur Ärger bringt, ist eine der besten Entscheidungen, die du treffen kannst.

Die technische Analyse: Bestandsaufnahme der TYPO3-Instanz

Du hast das Erstgespräch geführt und willst das Projekt übernehmen. Jetzt brauchst du Zugänge und musst dir ein genaues Bild vom Zustand der Instanz machen.

Welche Zugänge brauchst du?

Im Prinzip alles, was mit dem Projekt zu tun hat:

• Backend-Zugangsdaten
• SSH- und SFTP-Zugang zum Server
• Zugang zum Git-Repository, falls vorhanden (wenn nicht, legst du später ein eigenes an)

Domainverwaltung und DNS brauchst du nicht zwingend. Wenn der Kunde das rausgibt, kann es hilfreich sein. Wenn nicht, macht man bestimmte Dinge gemeinsam. E-Mail-Zugänge brauchst du in der Regel gar nicht.

Wichtig: Es ist nicht deine Aufgabe, dir alle Zugänge selbst zusammenzusuchen. Der Kunde sollte liefern, was du brauchst. Manchmal hat der Kunde allerdings selbst nicht alle Zugänge und muss sie erst bei der alten Agentur anfragen. Das kann dauern.

Und wenn die alte Agentur nicht kooperiert? Dann reicht in vielen Fällen der Zugang zum Hoster. Und den hat in der Regel der Endkunde selbst. Über das Hoster-Panel kannst du nach Rücksprache mit dem Kunden das SSH-Passwort zurücksetzen und dir so Zugang zum Server verschaffen. Von dort aus kommst du an die TYPO3-Instanz, die Datenbank und alles andere, was du brauchst. Das ist kein Hack, sondern ein ganz normaler Vorgang: Der Kunde ist Vertragspartner des Hosters und hat das Recht, Zugänge zu seinem eigenen Server zu verwalten. Wenn sich der alte Dienstleister also stur stellt oder schlicht nicht mehr erreichbar ist, ist der Hoster-Zugang dein Hebel.

Zusammenarbeit mit der bisherigen Agentur

Wie das läuft, hängt stark davon ab, warum die Zusammenarbeit beendet wurde. Wenn die Agentur dem Kunden aktiv mitgeteilt hat, dass sie aufhört (z.B. weil sie das TYPO3-Geschäft aufgibt), sind die meistens kooperativ und unterstützen die Übergabe. Dann lohnt es sich, direkt oder über den Kunden Kontakt aufzunehmen.

Wenn das Ganze nicht im Guten auseinandergegangen ist, wird es schwieriger. Dann musst du mit dem arbeiten, was der Kunde hat.

Schritt 1: Backend-Check

Dein erster Blick geht ins TYPO3-Backend. Dort siehst du:

• Die TYPO3-Version
• Die aktiv installierten Extensions
• Informationen über PHP-Version und Datenbank-Version
• Backend-Benutzer und Backend-Benutzergruppen

Besonders den letzten Punkt solltest du nicht übersehen: Wie viele Leute arbeiten im System? Wie oft loggen sie sich ein? Das wird später relevant, wenn du einen Redaktionsstopp für ein Upgrade planst.

Schritt 2: Server-Check

Als Nächstes brauchst du Zugang zum Server. Und hier kommt ein Punkt, der für mich fast ein Killerkriterium ist: Kein SSH-Zugang? Großes Problem.

Ohne SSH ist professionelles Arbeiten mit TYPO3 extrem mühsam. Klar, das Install-Tool erreichst du auch über das Backend. Aber sobald du Konfigurationsanpassungen auf Serverebene vornehmen, CLI-Befehle ausführen oder Dateien effizient verwalten willst, ist die Konsole um ein Vielfaches komfortabler als der Umweg über FTP. Und spätestens wenn du automatisierte Deployments nutzen willst, geht das ohne SSH-Zugang und die Möglichkeit, SSH-Keys einzurichten, schlicht nicht. Wenn der Hoster keinen SSH-Zugang anbietet und auch kein Upgrade in einen höheren Tarif möglich ist, sage ich dem Kunden klar: Du musst den Hoster wechseln. Das ist kein heikles Thema, das ist einfach eine technische Notwendigkeit.

Weitere Server-Themen, die du prüfen solltest:

• PHP-Version: Ist sie aktuell genug für die Ziel-TYPO3-Version? Manchmal schalten Hoster veraltete PHP-Versionen ab, die die aktuelle TYPO3-Installation noch braucht. Dann wird ein Upgrade unausweichlich.
• PHP-Konfiguration: Memory Limit, Maximum Execution Time und ähnliche Einstellungen. TYPO3 braucht gewisse Mindestparameter, damit es stabil läuft. Manche Hoster erlauben Anpassungen, manche nicht.
• Composer auf dem Server: Muss nicht zwingend vorhanden sein. Wenn du ein Deployment mit GitHub Actions oder GitLab CI aufsetzt, wird das Projekt in einem Docker-Container gebaut und von dort hochgeladen. Dann brauchst du Composer auf dem Server gar nicht.

Prüfe bei Hosting-Problemen immer zuerst, ob ein Tarifwechsel beim bestehenden Hoster möglich ist. Erst wenn das nicht geht, empfiehlst du einen Umzug.

Schritt 3: Code-Analyse

Jetzt wird es richtig spannend. Auf dem Server schaust du dir die Instanz im Detail an:

• Composer-basiert oder Legacy? Ist es eine moderne Composer-Installation oder noch eine Classic-Installation mit Symlinks?
• Sitepackage: Wie ist es aufgebaut? TypoScript, TSConfig, eigene ViewHelper?
• Custom Extensions: Was machen sie? Sind sie simpel (z.B. TCA-Erweiterungen der tt_content- oder pages-Tabelle) oder komplex? Wie viel eigener PHP-Code steckt drin?
• Installierte Extensions: Gibt es veraltete oder nicht mehr gepflegte Extensions, die bei einem Upgrade Probleme machen?
• Composer Patches: Wurden Patches angewendet, die eventuell nicht mehr nötig sind?

Wichtig: Vergiss das Backend nicht! Gerade bei nicht ganz aktuellen TYPO3-Instanzen ist oft viel TypoScript und TS-Config in der Datenbank verstreut. Das wird leicht übersehen, wenn man nur den Dateisystem-Code analysiert.

Nimm dir für eine saubere Code-Analyse ein paar Stunden Zeit und schau wirklich in jede relevante Datei rein. Das klingt aufwendig, spart dir aber später viel Ärger. Dokumentiere, was du findest. Besonders vorhandene Probleme solltest du festhalten, damit du sie später klar vom eigenen Arbeitsumfang abgrenzen kannst.

Schritt 4: Sicherheits-Check

Gerade bei Projekten, die längere Zeit nicht gepflegt wurden, solltest du einen Blick auf die Sicherheit werfen. Prüfe, ob für die installierte TYPO3-Version und die verwendeten Extensions bekannte Sicherheitslücken existieren. Die TYPO3 Security Bulletins sind dafür die erste Anlaufstelle.

Schau dir auch das Dateisystem genauer an: Liegen PHP-Dateien im System, die nicht zu TYPO3 gehören? Besonders der fileadmin-Ordner ist ein Ort, an dem sich gerne Dateien ansammeln, die dort nichts zu suchen haben. Wenn du solche Dateien findest, prüfe, was sie tun. Oft sind es harmlose Überbleibsel aus früheren Projektphasen: alte Testskripte, ausgelagerte Hilfsfunktionen oder vergessene Uploads. Aber manchmal haben sie spezielle Funktionen, die nicht zwingend direkt mit TYPO3 zu tun haben müssen. Ein gesundes Maß an Misstrauen ist hier angebracht.

Schritt 5: Nutzungsrechte und Lizenzen prüfen

Ein Punkt, der bei Projektübernahmen fast immer übersehen wird: Wem gehören eigentlich die Assets und der Code, mit denen du arbeitest?

Bei übernommenen Projekten ist die Rechtslage oft unklar. Stockfotos können an den Account der alten Agentur gebunden sein. Webfonts laufen über Lizenzen, die der Kunde nie selbst abgeschlossen hat. Gekaufte Extensions oder Plugins sind möglicherweise auf die bisherige Agentur registriert. Und bei individuell entwickeltem Code (Custom Extensions, eigene ViewHelper, Skripte) stellt sich die Frage, ob die Nutzungsrechte vertraglich beim Kunden liegen oder bei der Agentur verblieben sind.

Das wird spätestens dann zum Problem, wenn du Teile der Infrastruktur austauschst, eine Extension ersetzen willst oder das Projekt auf einen neuen Server umziehst. Wenn Lizenzen an alte Accounts gebunden sind und niemand mehr Zugriff hat, stehst du vor einem Problem, das sich nicht mit Code lösen lässt.

Was du konkret prüfen solltest:

• Stockfotos: Welches Lizenzmodell wurde verwendet? Sind die Bilder über einen Account der alten Agentur lizenziert?
• Webfonts: Laufen die Lizenzen über den Kunden oder über die Agentur? Sind sie noch gültig?
• Gekaufte Extensions und Plugins: Auf wessen Namen sind sie registriert? Hat der Kunde Zugang zu den Lizenzschlüsseln?
• Individuell entwickelte Erweiterungen: Gibt es einen Vertrag, der dem Kunden die Nutzungsrechte am Code einräumt?
• Externe Inhalte: Texte von Textern, Fotos von Fotografen. Liegen die Nutzungsrechte beim Kunden?

Die entscheidende Frage lautet: Hat der Kunde die notwendigen Nutzungsrechte an allen eingesetzten Assets und am Code?

In vielen Fällen weiß der Kunde das selbst nicht. Frag trotzdem nach und dokumentiere den Status. Wenn etwas unklar ist, halte das in deinem Ist-Zustand-Protokoll fest. Du musst das Problem nicht sofort lösen, aber du solltest wissen, dass es existiert.

Wenn die Lage wirklich unübersichtlich ist: Ein kurzes Gespräch mit einem auf IT-Recht spezialisierten Anwalt kann sich lohnen. Besonders bei größeren Projekten mit vielen externen Zulieferern. Das ist kein Aufwand, den du bei jedem Projekt brauchst. Aber wenn Lizenzsituationen kompliziert sind oder du den Verdacht hast, dass Rechte nicht sauber übertragen wurden, ist eine professionelle Einschätzung die sicherste Option.

Fehlende Dokumentation ist der Normalfall

Eine Sache, die du sofort akzeptieren solltest: Projektspezifische Dokumentation von der Vorgängeragentur gibt es in den meisten Fällen nicht. Keine Deployment-Anleitung, keine Beschreibung der Custom Extensions, keine Architektur-Entscheidungen. Damit rechne ich immer. Ich bin eher überrascht, wenn es so etwas gibt. TYPO3 selbst und die meisten öffentlichen Extensions sind natürlich dokumentiert. Aber wie das konkrete Projekt aufgebaut ist, warum bestimmte Entscheidungen getroffen wurden und wie das Deployment funktioniert, das steht nirgends.

Genau deshalb ist die eigene Analyse so wichtig. Du bist die einzige Person, die sich ein vollständiges Bild macht.

Custom Extensions und PHP: Wo sind deine Grenzen?

Das ist ein Thema, bei dem Ehrlichkeit gegenüber dir selbst wichtig ist.

Einfache Extensions (TCA-Erweiterungen, eigene ViewHelper, kleine Anpassungen) kann ein Integrator mit etwas Erfahrung in der Regel selbst in eine neue TYPO3-Version migrieren. Tools wie Rector und Fractor helfen dabei enorm.

Komplexe Extensions (z.B. auf dem Niveau der News-Extension von Georg Ringer) sind eine andere Hausnummer. Wenn du dich da nicht sehr gut auskennst, lass die Finger davon.

Wenn du eher neu in der Branche bist: Hol dir immer eine zweite Meinung von jemandem, der sich auskennt. Das ist keine Schwäche, das ist professionell.

Externe Hilfe organisieren

Wenn du merkst, dass die PHP-Anforderungen eines Projekts deine Fähigkeiten übersteigen, hast du drei Optionen:

1. Das Projekt abgeben an jemanden, der mehr Erfahrung hat
2. Einen Entwickler projektbasiert dazuholen
3. Eine dauerhafte Zusammenarbeit mit einem erfahrenen Entwickler aufbauen

Wie du jemanden findest? Dein Netzwerk ist hier Gold wert. Wer in der TYPO3-Community aktiv ist, kennt Leute. Wer auf Events geht, Slack-Channels nutzt oder im Forum aktiv ist, findet Ansprechpartner.

Für die Zusammenarbeit bei einmaligen Projekten läuft es meistens auf Stundenbasis: Du zeigst dem Entwickler, was du hast, und bittest um eine Einschätzung und ein Angebot. Die Kosten gibst du an deinen Kunden weiter.

Mein Rat: Kommuniziere das offen. Sag dem Kunden, dass du einen spezialisierten Entwickler dazuholst. Der Kunde hat davon nur Vorteile: ein zusätzlicher Experte am Projekt. Manche scheuen sich davor, das transparent zu machen. Ich halte das für unnötig.

Projekt lokal aufsetzen und Infrastruktur schaffen

Die bisherigen Schritte gelten für jede Projektübernahme. Das Gleiche gilt für die folgenden: Unabhängig davon, ob du ein Upgrade durchführst oder das Projekt in der aktuellen Version weiterbetreibst, brauchst du ein Backup, eine lokale Entwicklungsumgebung und ein sauberes Deployment.

Backup erstellen

Bevor du irgendetwas am Projekt änderst: Erstelle ein vollständiges Backup. Datenbank und Dateien. Bei einem Projekt, dessen Infrastruktur du noch nicht im Detail kennst, ist das nicht optional, sondern Pflicht. Dieses Backup ist dein Sicherheitsnetz für alles, was danach kommt.

Lokale Entwicklungsumgebung aufsetzen

Leg dir eine lokale Kopie der Instanz mit DDEV an. Wenn bereits ein Git-Repository existiert und du Zugriff darauf hast, klonst du das Repository und brauchst nur noch die Datenbank und gegebenenfalls die Dateien aus dem fileadmin-Ordner per rsync zu übertragen. Ohne Git-Repository holst du dir alle Dateien per rsync vom Server. Bei sehr großen Projekten mit mehreren Gigabyte im fileadmin-Ordner hilft die Extension filefill, die fehlende Dateien bei Bedarf automatisch vom Live-Server nachlädt.

Wenn das Projekt bisher nicht in einem Git-Repository liegt, ist jetzt der richtige Zeitpunkt: Repository anlegen und den aktuellen Stand committen. Ab hier arbeitest du versioniert und kannst jede Änderung nachvollziehen. Das klingt selbstverständlich, aber bei übernommenen Projekten ohne Repository wird dieser Schritt gerne vergessen. Falls du mit Git noch nicht sicher arbeitest, findest du in meinem Videokurs Git Grundlagen für TYPO3 Integratoren einen praxisnahen Einstieg, der genau auf TYPO3-Projekte zugeschnitten ist.

Deployment aufsetzen

Wenn die lokale Instanz läuft, baust du in der Regel auch ein Deployment auf. Mein Setup: Deployer in Kombination mit GitHub Actions. Das Projekt wird in einem Docker-Container bei GitHub gebaut und von dort per Deployer auf den Server hochgeladen. Git für die Versionierung ist dabei selbstverständlich. Composer muss bei diesem Setup auf dem Zielserver nicht installiert sein, weil der komplette Build-Prozess bereits in der CI/CD-Pipeline stattfindet. Wie du dieses Setup Schritt für Schritt einrichtest, zeige ich in meinem Videokurs Deployment mit GitHub Actions und Deployer.

Das Upgrade: Planung und Durchführung

Nicht jede Projektübernahme beinhaltet ein Upgrade. Wenn die TYPO3-Version noch aktuell genug ist und der Support nicht ausläuft, kannst du das Projekt einfach in der aktuellen Version weiterbetreiben und das Upgrade auf einen späteren Zeitpunkt verschieben. Alles, was ab hier folgt, betrifft den Fall, dass ein Upgrade Teil der Übernahme ist.

Redaktionsstopp vereinbaren

Bevor du mit dem eigentlichen Upgrade startest, muss der Redaktionsstopp stehen. Der Grund ist einfach: Wenn der Kunde zwischen dem Zeitpunkt, an dem du die Datenbank für das Upgrade ziehst, und dem Go-Live weiter im Backend arbeitet, hast du unterschiedliche Datenstände. Das willst du vermeiden.

Bei Projekten, wo nicht täglich mehrere Leute im System arbeiten, ist ein mehrtägiger Stopp in der Regel kein Problem. Lege den Zeitraum am besten in eine Phase, in der wenig passiert: Betriebsferien, Sommerferien, Brückentage. In der Regel findet sich ein passender Zeitraum.

Wenn ein Redaktionsstopp nicht möglich ist, musst du mit Datenbankdifferenzen umgehen. Entweder pragmatisch: Der Kunde dokumentiert seine Änderungen und pflegt sie nach dem Go-Live selbst nach. Oder du ziehst die Datenbank regelmäßig neu herunter und führst die Upgrade-Schritte (Upgrade-Wizards, Datenbankstruktur-Anpassungen) erneut durch. Das ist manchmal etwas Fummelei, aber machbar. Ein paar kleine Shell-Skripte, die den Datenbank-Pull, den Import in DDEV und das erneute Durchlaufen der Upgrade-Wizards automatisieren, können den Aufwand hier deutlich reduzieren.

Wenn der Redaktionsstopp steht, ziehst du eine frische Kopie der Datenbank und startest das Upgrade lokal: Sitepackage bereinigen, eigene Extensions anpassen, das eigentliche Versions-Upgrade durchführen.

Upgrade über mehrere Versionen

Ein wichtiger Praxistipp: Teste das Frontend erst in der Zielversion.

Wenn du z.B. von TYPO3 10 auf 14 aktualisierst, interessiert dich nicht, ob das Frontend in Version 11, 12 oder 13 funktioniert. In den Zwischenversionen achtest du nur darauf, dass die Datenbank sauber mitgenommen wird und im Backend alles passt: Content-Elemente in den richtigen Spalten, Upgrade-Wizards durchgelaufen, keine kritischen Fehler.

Erst in der Zielversion wird das Frontend getestet. Das spart enorm viel Zeit.

Testen

Wenn das Upgrade in der Zielversion steht, testest du das Frontend. Klassisch: einmal komplett durchklicken. Für einen systematischen Abgleich nutze ich ein eigenes Tool auf Basis von Backstop.js, das die komplette Website im Frontend durchtestet und mit der Live-Seite vergleicht. So stelle ich sicher, dass nichts übersehen wird.

Nach dem Deployment muss auch der Kunde selbst testen: Backend-Login, Inhalte prüfen, Frontend durchklicken. Je nach Projekt kann es sinnvoll sein, das Ganze zunächst auf einer Staging-Umgebung bereitzustellen, bevor die Live-Seite ersetzt wird. Das lohnt sich aber nicht bei jedem Projekt.

KI als Werkzeug beim Upgrade

KI-Tools können beim Upgrade unterstützen, aber nur unter bestimmten Voraussetzungen. Einzelne Codeschnipsel ohne Kontext bei ChatGPT reinzuschmeißen und "Lös mal dieses Problem" zu schreiben, funktioniert in der Regel nicht.

Deutlich wertvoller sind Tools wie Codex von OpenAI oder Claude Code, die das gesamte Projekt sehen und verstehen. Wenn man diesen Tools zusätzlich gezielt Wissen mitgibt (Dokumentationen, Anweisungen, Kontext), können die Ergebnisse richtig gut sein.

Aber: Vertraue nie blind den Angaben einer KI. Prüfe immer, was sie dir liefert. Halluzinationen sind real und können dich teuer zu stehen kommen.

Aufwandsschätzung und Preisgestaltung

Wie lange dauert das alles?

Bei einer reinen Projektübernahme ohne Upgrade ist der Aufwand deutlich geringer: Analyse, lokale Kopie aufsetzen, Deployment einrichten, Wartungsvertrag aufsetzen. Das kann je nach Projektgröße an einem Tag erledigt sein.

Für kleinere, überschaubare Projekte mit einem Upgrade von einer relativ aktuellen Version (z.B. 12 auf 13 oder 14) kannst du mit zwei bis drei Arbeitstagen rechnen. Bei einem Upgrade von TYPO3 7 oder 8 auf eine aktuelle Version ist der Aufwand deutlich höher.

Faustregel für den Puffer: 50 bis 100 % der Erstschätzung oben drauf. Es wird nie exakt so kommen, wie du es dir vorstellst. Manchmal geht es glatter als erwartet. Aber plane lieber großzügig.

Festpreis oder Stundensatz?

Ich tendiere zum Festpreis. Der basiert intern natürlich auf einer kalkulierten Stundenanzahl plus Puffer, aber der Kunde bekommt eine klare Zahl.

Eine wichtige Frage dabei: Was ist das Budget des Kunden? Das bestimmt mit, wie sauber du das Projekt übernimmst. Baust du alles um, was möglich ist? Oder nur das, was nötig ist? Beides ist legitim, aber es muss vorher klar sein.

Analyse-Stunden abrechnen?

Die Analyse rechnest du dem Kunden in der Regel nicht direkt ab. Aber du kannst den Aufwand im Angebot unterbringen und nachträglich verrechnen. Ob vollständig oder anteilig, musst du selbst entscheiden. Natürlich besteht das Risiko, dass der Kunde das Angebot nicht annimmt und du die Stunden investiert hast. Das ist ein normales Geschäftsrisiko.

Nach dem Go-Live: Wartung und Nachbetreuung

Go-Live-Checkliste

Trotz aller Tests übersieht man manchmal etwas. Mach dir eine Checkliste für Dinge, die du nach jedem Go-Live prüfst:

• E-Mail-Versand: Funktionieren Kontaktformulare und Benachrichtigungen?
• Bildkonvertierung: Werden Bilder korrekt verarbeitet?
• Cronjobs und Scheduler-Tasks: Laufen sie durch?
• Backups: Sind sie eingerichtet und getestet?

Wartungsvertrag anbieten

Ein Wartungsvertrag ist aus mehreren Gründen sinnvoll. Für den Kunden bedeutet er Sicherheit: Die Website bleibt aktuell und gepflegt. Für dich bedeutet er eine regelmäßige Einnahmequelle.

Was rein sollte:

• Patch- und Minor-Updates (TYPO3 und Extensions)
• Regelmäßige Prüfung auf Sicherheitsupdates
• Monitoring der Server-Konfiguration

Was nicht rein sollte:

• Major-Upgrades (z.B. von TYPO3 14 auf 15). Die sind in der Regel aufwendiger und sollten als separates Projekt angeboten werden.

Abrechnung kann monatlich, halbjährlich oder jährlich erfolgen.

Verantwortlichkeiten klären

Wenn du vorher eine saubere Analyse gemacht hast, kennst du die vorhandenen Probleme. Dokumentiere sie und besprich sie vorab mit dem Kunden:

• Müssen diese Probleme im Rahmen der Übernahme gelöst werden?
• Wenn ja: Ist das im Budget abgedeckt, oder braucht es externe Hilfe?
• Wenn nein: Dann bleibt es dokumentiert, aber es ist nicht dein Problem.

Halte den dokumentierten Ist-Zustand schriftlich fest und lass den Kunden das bestätigen. Das muss kein juristisches Dokument sein, aber eine klare, schriftliche Aufstellung der vorhandenen Probleme, die beide Seiten kennen und akzeptieren. Damit sicherst du dich ab, falls später die Frage aufkommt, ob ein Problem schon vor deiner Übernahme bestand oder erst danach entstanden ist.

Diese Transparenz schützt dich vor unangenehmen Diskussionen im Nachhinein.

Die wichtigste Lektion: Hör auf dein Bauchgefühl

Zum Schluss noch etwas Persönliches. Ich habe einmal ein Projekt übernommen, obwohl ich im Kundengespräch das Gefühl hatte, dass der Kunde schwierig werden könnte. Ich habe mein Bauchgefühl ignoriert. Das war ein Fehler.

Wenn du im Erstgespräch Zweifel hast, nimm sie ernst. Nicht jeder Kunde passt zu dir, und nicht jedes Projekt ist die Mühe wert. Manche denken, sie können es sich nicht leisten, einen Kunden abzulehnen, weil sie das Geld brauchen. Aber ist ein Projekt wirklich das Geld wert, wenn es dir über Wochen Energie raubt, du dich über jede E-Mail ärgerst und am Ende trotzdem kein zufriedener Kunde dabei rauskommt? Du kannst es dir leisten, Nein zu sagen. Oft ist das die klügere Entscheidung.

Zusammenfassung: Deine Checkliste

Erstgespräch

• [ ] Grundinfos zum Projekt erfragen (TYPO3-Version, Hoster, Extensions)
• [ ] Hintergründe verstehen: Warum braucht der Kunde jemand Neues?
• [ ] Warnsignale ernst nehmen und Bauchgefühl beachten

Zugänge sichern

• [ ] Backend-Zugangsdaten
• [ ] SSH-/SFTP-Zugang
• [ ] Git-Repository (oder eigenes anlegen)
• [ ] Optional: Domainverwaltung/DNS

Technische Analyse

• [ ] Backend: TYPO3-Version, Extensions, Backend-Benutzer, Aktivität
• [ ] Server: SSH, PHP-Version, PHP-Konfiguration, Datenbank-Version
• [ ] Code: Composer oder Legacy? Sitepackage-Qualität? Custom Extensions?
• [ ] TypoScript und TS-Config in der Datenbank prüfen
• [ ] Extensions auf Upgradefähigkeit prüfen
• [ ] Sicherheits-Check: Bekannte Schwachstellen, verdächtige PHP-Dateien, fileadmin prüfen
• [ ] Vorhandene Probleme dokumentieren
• [ ] Ist-Zustand schriftlich festhalten und vom Kunden bestätigen lassen

Aufwand und Angebot

• [ ] Aufwand schätzen (inkl. 50-100 % Puffer)
• [ ] Budget und Umfang mit dem Kunden klären
• [ ] Externe Hilfe einplanen, falls Custom Extensions zu komplex sind

Projekt lokal aufsetzen

• [ ] Vollständiges Backup erstellen (Datenbank + Dateien)
• [ ] Lokale Kopie mit DDEV anlegen
• [ ] Git-Repository anlegen, falls nicht vorhanden
• [ ] Deployment aufsetzen (z.B. Deployer + GitHub Actions)

Upgrade durchführen (falls nötig)

• [ ] Redaktionsstopp mit dem Kunden vereinbaren
• [ ] Frische Datenbank ziehen und Upgrade lokal durchführen
• [ ] Frontend erst in Zielversion testen
• [ ] Kunden auf Staging oder Live testen lassen

Nach dem Go-Live

• [ ] Go-Live-Checkliste abarbeiten (E-Mail, Bilder, Cronjobs, Backups)
• [ ] Wartungsvertrag anbieten (Patch/Minor-Updates)
• [ ] Verantwortlichkeiten für vorhandene Probleme klären

Checkliste, Vorlagen und Bewertungsmatrix zum Mitnehmen

Du willst die Checkliste nicht nur lesen, sondern direkt in deinem nächsten Projekt einsetzen? Hol dir die erweiterte Version: mit Bewertungsspalten für Zustand, Aufwand und Priorität pro Checkpoint. Dazu eine fertige Vorlage für das Ist-Zustand-Protokoll. Alles als editierbares Google Doc, das du dir kopieren und für dein Projekt anpassen kannst.

Zurück