IT Due Diligence: Wie Sie ein Tech-Team bei Uebernahmen und Investitionen bewerten
Wenn ein Unternehmen uebernommen wird oder Investoren einsteigen, steht die Technologie-Abteilung selten im Mittelpunkt der Pruefung. Umsatzzahlen, Marktposition, rechtliche Risiken — das alles wird gruendlich analysiert. Doch das Tech-Team? Oft ein blinder Fleck. Ein Fehler, der Millionen kosten kann.
Dieser Guide zeigt Ihnen, was eine fundierte Technical Due Diligence umfasst, welche Red Flags Sie sofort erkennen muessen und wie ein externer Recruiting-Partner Luecken nach der Uebernahme schliesst.
Warum IT Due Diligence entscheidend ist
Bei 70% aller gescheiterten Uebernahmen im Tech-Bereich spielen Probleme in der Technologie-Organisation eine zentrale Rolle. Nicht weil die Software schlecht ist — sondern weil das Team, das sie gebaut hat, nicht so aufgestellt ist, wie der Kaeufer es erwartet hat.
Eine IT Due Diligence geht ueber den Code hinaus. Sie bewertet die Menschen, die Prozesse und die Faehigkeit des Teams, das Produkt in Zukunft weiterzuentwickeln. Denn am Ende kaufen Sie nicht nur Software — Sie kaufen die Faehigkeit, diese Software am Leben zu halten und auszubauen.
Investoren wie Venture-Capital-Fonds und Private-Equity-Gesellschaften wissen das laengst. Bei SaaS-Deals mit Bewertungen ueber EUR 10 Mio. ist eine Technical Due Diligence Standard. Aber auch bei kleineren Uebernahmen — etwa wenn ein Mittelstaendler ein Software-Startup kauft — sollte sie zum Pflichtprogramm gehoeren.
Die 5 Saeulen der Tech-Team-Bewertung
Eine gruendliche IT Due Diligence untersucht das Tech-Team in fuenf zentralen Dimensionen. Jede einzelne kann den Wert des Unternehmens massiv beeinflussen.
Team-Zusammensetzung & Struktur
Wie ist das Team aufgebaut? Gibt es eine klare Hierarchie mit Tech Lead, Engineering Manager und CTO — oder macht der Gruender alles selbst? Wie gross ist das Team im Verhaeltnis zur Produktkomplexitaet?
Bei einem SaaS-Produkt mit 50.000 Nutzern und nur 3 Entwicklern sollten Alarmglocken laeuten. Entweder ist das Produkt technisch trivial — oder das Team ist chronisch unterbesetzt und hat Shortcuts genommen, die spaeter teuer werden.
Pruefen Sie: Organigramm, Rollen und Verantwortlichkeiten, Team-Groesse vs. Produkt-Scope, Verhaeltnis Senior zu Junior, Freelancer-Anteil, Standorte und Zeitzonen.
Skill Gaps & Kompetenzluecken
Hat das Team die Faehigkeiten, die es braucht um das Produkt in den naechsten 3-5 Jahren weiterzuentwickeln? Wenn das Produkt auf Kubernetes laeuft aber niemand im Team DevOps-Erfahrung hat, ist das ein stilles Risiko.
Besonders kritisch: Wenn wichtige Kompetenzen nur bei einzelnen Personen liegen. Das fuehrt direkt zur naechsten Saeule — dem Key Person Risk.
Key Person Risk
Haeufigster Deal-KillerIn fast jedem Startup und vielen Mittelstaendlern gibt es eine Person, ohne die nichts geht. Der Entwickler, der das gesamte Backend gebaut hat. Der DevOps-Engineer, der als Einziger die Infrastruktur versteht. Der CTO, der alle Architekturentscheidungen im Kopf hat — undokumentiert.
Wenn diese Person nach der Uebernahme geht — und das passiert haeufiger als man denkt — steht das gesamte Produkt still. Bei PE-Deals rechnen erfahrene Investoren den Key-Person-Abschlag direkt in die Bewertung ein: Typischerweise 10-25% Bewertungsreduktion pro kritischer Einzelperson.
Warnung: Fragen Sie nicht nur “Wer koennte gehen?” sondern “Was passiert, wenn Person X morgen nicht mehr da ist?” Wenn die Antwort “Dann haben wir ein ernstes Problem” ist, haben Sie Ihren groessten Risikofaktor gefunden.
Tech-Stack-Alter & Modernisierungsbedarf
Ein Tech-Stack ist kein Wein — er wird mit dem Alter nicht besser. Wenn ein Produkt auf PHP 5.6, jQuery und einem selbstgebauten Framework aus 2014 laeuft, muessen Sie die Modernisierungskosten einkalkulieren. Das kann schnell 6-12 Monate Entwicklungszeit bedeuten — ohne neue Features.
Aber auch das Gegenteil ist ein Risiko: Ein Startup, das bei jeder neuen Technologie sofort umstellt, hat moeglicherweise ein Frankenstein-System aus 15 verschiedenen Frameworks und Sprachen, das niemand vollstaendig ueberblickt.
Tech-Stack-Bewertungsmatrix
Technical Debt — die versteckte Hypothek
Technical Debt ist der Unterschied zwischen dem Code, den ein Team haette schreiben sollen, und dem Code, den es tatsaechlich geschrieben hat. In jedem Unternehmen gibt es davon etwas. Die Frage ist: Wie viel, und wie teuer wird die Tilgung?
Typische Indikatoren fuer hohe Technical Debt: Keine automatisierten Tests, fehlende oder veraltete Dokumentation, monolithische Architektur die laengst haette aufgeteilt werden muessen, keine CI/CD-Pipeline, manuelle Deployment-Prozesse, “nur Hans weiss wie das funktioniert”.
Bei der Due Diligence sollten Sie die Debt quantifizieren: Wie viele Entwickler-Monate braucht es, um den Code auf einen wartbaren Stand zu bringen? Bei stark verschuldeten Codebasen kann das 30-50% der Entwicklungskapazitaet im ersten Jahr nach der Uebernahme binden.
Red Flags: Wann Sie genauer hinschauen muessen
Nicht jedes Problem in einem Tech-Team ist ein Deal-Breaker. Aber bestimmte Muster deuten auf systemische Probleme hin, die nach der Uebernahme teuer werden.
Hohe Fluktuation im Tech-Team
Mehr als 20% Abgaenge pro Jahr deuten auf kulturelle oder kompensatorische Probleme hin. Fragen Sie nach den Gruenden — und pruefen Sie die Antworten.
CTO oder Lead-Entwickler kuendigt vor dem Deal
Wenn Schluesselpersonen den Exit des Gruenders als Anlass nehmen zu gehen, ist das ein Zeichen fuer geringe Loyalitaet zum Unternehmen selbst — nur zum Gruender.
Kein einziger automatisierter Test
In 2026 ist fehlende Testabdeckung ein Zeichen fuer systematischen Qualitaetsmangel. Jede Aenderung am Code wird zum Risiko.
Dokumentation existiert nicht oder ist 2+ Jahre alt
Veraltete Doku ist schlimmer als keine Doku — sie fuehrt in die Irre. Beides signalisiert: Das Team hat nicht genug Kapazitaet (oder Disziplin) fuer nachhaltige Arbeit.
Grosser Freelancer-Anteil ohne Wissenstransfer
Wenn 50%+ des Teams aus Freelancern besteht die nach dem Deal abziehen, verlieren Sie die Haelfte Ihres institutionellen Wissens. Sofort.
Monolithisches System ohne Skalierungsplan
Ein Monolith ist per se kein Problem. Aber ein Monolith ohne Plan fuer die naechsten Wachstumsphasen ist eine tickende Zeitbombe.
Keine klare Deployment-Pipeline
Manuelle Deployments bedeuten: Jedes Release ist ein Risiko. Rollbacks sind schwierig. Feature-Velocity leidet massiv.
Abhaengigkeit von einem einzigen Cloud-Anbieter ohne Exit-Plan
Vendor Lock-in ist akzeptabel wenn bewusst. Aber ohne Exit-Strategie sind Sie Preiserhoehungen schutzlos ausgeliefert.
Was kostet es, Luecken nicht zu schliessen?
Die Kosten einer unvollstaendigen IT Due Diligence werden oft erst Monate nach dem Deal sichtbar — wenn es zu spaet ist, den Kaufpreis nachzuverhandeln.
Typische Kosten unentdeckter Tech-Risiken
Dagegen stehen die Kosten einer gruendlichen Technical Due Diligence: EUR 15.000-50.000 fuer ein externes Assessment, abhaengig von der Unternehmensgroesse. Eine Investition, die sich bei jedem einzelnen der oben genannten Risikoszenarien sofort amortisiert.
IT Due Diligence Checkliste: 20 Fragen die Sie stellen muessen
Verwenden Sie diese Checkliste als Ausgangspunkt fuer Ihre Technical Due Diligence. Jede unbeantwortete Frage ist ein potenzielles Risiko.
Team
- ☐Wie ist das Team strukturiert (Rollen, Hierarchie)?
- ☐Welche Positionen sind aktuell unbesetzt?
- ☐Wie hoch ist die Fluktuation der letzten 24 Monate?
- ☐Welche Mitarbeiter haben Kuendigungsklauseln oder Earn-Outs?
- ☐Gibt es dokumentierte Onboarding-Prozesse?
Skills
- ☐Welche Technologien setzt das Team ein?
- ☐Gibt es Kompetenzluecken in kritischen Bereichen?
- ☐Wie hoch ist der Freelancer-Anteil?
- ☐Gibt es ein Weiterbildungsbudget und wird es genutzt?
- ☐Koennte das Team eine Tech-Stack-Migration durchfuehren?
Risiko
- ☐Wer sind die Key Persons und was passiert wenn sie gehen?
- ☐Gibt es Single Points of Failure in der Architektur?
- ☐Wie ist die Testabdeckung (Unit, Integration, E2E)?
- ☐Gibt es bekannte Sicherheitsluecken?
- ☐Existiert ein Disaster-Recovery-Plan?
Zukunft
- ☐Passt der aktuelle Tech-Stack zur Produkt-Roadmap?
- ☐Wie lange wuerde ein komplettes Re-Write dauern?
- ☐Gibt es eine Skalierungsstrategie fuer 10x Wachstum?
- ☐Welche technischen Schulden sind dem Team bewusst?
- ☐Ist die Infrastruktur reproduzierbar (IaC)?
Nach der Uebernahme: Wie ein Recruiting-Partner Luecken schliesst
Die Due Diligence identifiziert die Probleme. Aber wer loest sie? In den meisten Faellen braucht das uebernommene Unternehmen schnell neue Mitarbeiter — sei es weil Key Persons gehen, Skill Gaps geschlossen werden muessen oder das Team fuer die Skalierung vergroessert werden soll.
Genau hier wird ein spezialisierter IT-Recruiting-Partner zum entscheidenden Faktor fuer den Erfolg der Uebernahme.
Key-Person-Replacement
Wenn der CTO oder Lead-Architekt geht, brauchen Sie innerhalb von 4-8 Wochen einen Nachfolger der die Architektur versteht und das Team fuehren kann. Das ist kein Job fuer eine Stellenanzeige auf LinkedIn — das erfordert aktive Suche in spezialisierten Netzwerken.
Skill-Gap-Closing
Die Due Diligence hat ergeben, dass DevOps- und Security-Kompetenz fehlen? Ein Recruiting-Partner mit Multi-Market-Zugang findet diese Spezialisten schneller als Ihre interne HR-Abteilung, die den DACH-Markt bereits abgesucht hat.
Team-Skalierung
Post-Acquisition heisst oft: schnelles Wachstum. Statt 5 Entwickler brauchen Sie 15. In 6 Monaten. Das erfordert parallele Suche in mehreren Maerkten, standardisierte Technical Screenings und effizientes Onboarding.
Freelancer-zu-Festanstellung-Conversion
Wenn grosse Teile des Teams aus Freelancern bestehen, muessen diese entweder in Festanstellungen konvertiert oder durch festangestellte Mitarbeiter ersetzt werden. Beides erfordert Fingerspitzengefuehl und Geschwindigkeit.
Kultur-Integration
Nach einer Uebernahme ist die Kultur fragil. Neue Hires muessen nicht nur fachlich passen, sondern auch die Bruecke zwischen alter und neuer Unternehmenskultur schlagen koennen. Das erfordert ein tiefes Verstaendnis beider Seiten.
Warum NexaTalent fuer Post-Acquisition-Recruiting
Uebernahmen erfordern Geschwindigkeit, Praezision und Diskretion. Genau dafuer ist NexaTalent gebaut.
Fazit: Das Tech-Team ist der wahre Wert
Code kann umgeschrieben werden. Infrastruktur kann migriert werden. Aber ein eingespieltes Tech-Team, das weiss wie das Produkt funktioniert, warum bestimmte Entscheidungen getroffen wurden und wie man es weiterentwickelt — das kann man nicht einfach ersetzen.
Deshalb ist die IT Due Diligence keine optionale Zusatzleistung, sondern ein essenzieller Teil jeder Uebernahme oder Investition im Tech-Bereich. Und deshalb muessen die Ergebnisse nicht in einer Schublade verschwinden, sondern in einen konkreten Personalplan muenden.
Bewerten Sie das Team mit der gleichen Gruendlichkeit wie die Bilanz. Identifizieren Sie Risiken bevor sie zu Kosten werden. Und haben Sie einen Plan, wie Sie Luecken schnell und praezise schliessen — mit einem Partner, der den IT-Markt kennt.
Uebernahme geplant? Tech-Team-Luecken schliessen?
Wir unterstuetzen Sie bei der Bewertung und Besetzung Ihres Tech-Teams — vor, waehrend und nach der Transaktion. Erfolgsbasiert, 4 Maerkte, muttersprachliches Screening.
Kostenlose Erstberatung