Custom-Software vs Standard-Software — Entscheidungs-Leitfaden für den Mittelstand 2026

Die Entscheidung zwischen Custom-Software und Standard-Software ist in den meisten mittelständischen Unternehmen weniger eine technologische als eine strategische Weichenstellung — und sie wird häufig zu früh getroffen, ohne saubere Kosten-Modellierung. Wer ein Standard-ERP einführt, ohne den eigenen Differenzierungs-Prozess sauber abzugrenzen, finanziert über fünf Jahre teure Anpassungen, die mit jeder Vendor-Version brüchig werden. Wer umgekehrt eine Eigenentwicklung startet, weil ein einzelner Workshop-Tag das Standard-Produkt als "zu unflexibel" abgestempelt hat, läuft Gefahr, ein zweites Buchhaltungssystem zu bauen, das nach drei Jahren ungepflegt am Rand der IT-Landschaft hängt. Dieser Leitfaden zeigt, wie Sie die Frage strukturiert angehen, welche Kosten- und Risiko-Faktoren in die Bewertung gehören und welche Hybrid-Modelle sich in der mittelständischen Praxis bewährt haben. Für die Einordnung in die Gesamtstrategie siehe unseren Leitfaden Softwareentwicklung für den Mittelstand.

Worüber wir reden — Begriffe, Kosten-Hebel und Risiko-Rahmen

Bevor man Custom und Standard gegeneinander stellt, lohnt sich eine kurze Begriffsklärung — die Gespräche in Geschäftsführungs-Runden kranken erfahrungsgemäß daran, dass jeder etwas anderes meint. Mit Standard-Software meinen wir kommerzielle Produkte, die ein definiertes Anwendungs-Feld in einer am Markt ausgereiften Form abdecken: Finanzbuchhaltung wie DATEV, ERP wie SAP S/4HANA, Microsoft Dynamics 365 oder Sage, CRM wie Salesforce oder HubSpot, HR-Suiten wie Personio oder SAP SuccessFactors. Diese Produkte sind durch Hersteller-Roadmaps gepflegt, durch eine Anwender-Community erprobt und durch Zertifizierungen regulatorisch abgesichert.

Custom-Software meint individuell entwickelte Anwendungen — entweder vollständig aus dem Code-Stand Null oder auf Basis von Frameworks wie Next.js, Spring Boot, Django oder .NET. Maßgeblich ist nicht die Bibliotheks-Auswahl, sondern dass Anforderungen, Datenmodell und Roadmap vom Unternehmen selbst kontrolliert werden. Wir grenzen Custom in diesem Artikel auch von Low-Code ab — letzteres ist eine eigene Kategorie mit eigenem Trade-off-Profil, siehe dazu unseren Vergleich Low-Code vs Custom-Code.

Eine dritte Kategorie, die oft unterschätzt wird, ist die Hybrid-Architektur — also Standard-Software für Commodity-Domänen plus individuelle Module für den differenzierenden Prozess, sauber über APIs verbunden. In der mittelständischen Realität ist das in den meisten Fällen die richtige Zielarchitektur, nicht eine Entweder-Oder-Entscheidung.

Wann Standard-Software absolut richtig ist

Es gibt Bereiche, in denen jede Diskussion über Eigenentwicklung Geld- und Zeitverschwendung wäre. Die Faustregel: wenn der zu unterstützende Prozess nicht zum Verkaufs-Versprechen an Ihre Kunden gehört und gleichzeitig ein reifer Markt etablierter Lösungen existiert, ist Standard fast immer die richtige Antwort. Drei Domänen sind hier besonders deutlich.

Finanzbuchhaltung und steuerliche Pflichten. Niemand in Deutschland sollte 2026 noch erwägen, ein eigenes Buchhaltungs-System zu bauen. DATEV, SAP, Sage und Lexware haben jahrzehntelange Pflege in deutsche Steuer-Regeln investiert, GoBD-Konformität, Schnittstellen zu Finanzämtern, Wirtschaftsprüfer-akzeptierte Audit-Trails und automatische Anpassungen an Gesetzesänderungen. Eine Eigenentwicklung müsste all das erst aufholen — ohne Mehrwert für Ihre Kunden.

Lohnabrechnung und Personalwesen. Sozialversicherungs-Beiträge, Lohnsteuer-Tabellen, ELSTAM, Mitbestimmungs-Themen — das Regelwerk ändert sich mehrmals jährlich. Anbieter wie DATEV LODAS, Personio oder SAP SuccessFactors halten das nach. Eine Eigenentwicklung wäre ein Vollzeit-Job allein für die regulatorische Pflege.

Klassisches CRM und Standard-Vertriebs-Pipeline. Wer Kontakte, Opportunities und Aktivitäten verwalten will, findet bei HubSpot, Pipedrive, Salesforce oder Microsoft Dynamics ausgereifte Funktionalität samt Integrationen zu E-Mail, Telefonie und Kalender. Hier eine eigene Lösung zu bauen, lohnt nur, wenn das Vertriebs-Modell selbst so unüblich ist, dass kein Standardprodukt es ohne tiefes Customizing trifft.

Gemeinsamer Nenner dieser drei Domänen: hohe regulatorische Pflege, breite Funktions-Tiefe, und Prozesse, die Ihre Kunden weder sehen noch bewerten. Investitionen in diese Bereiche sind hygienisch — sie schaffen keinen Wettbewerbs-Vorsprung, sie vermeiden nur Probleme. Genau deshalb ist Standard hier richtig.

Wann Custom-Software gewinnt

Auf der anderen Seite gibt es Domänen, in denen Standard-Software die falsche Wahl ist — selbst wenn es im Markt etwas Vergleichbares gibt. Die entscheidende Frage ist nicht "gibt es ein Produkt?", sondern "ist dieser Prozess Teil unseres Differenzierungs-Versprechens?". Drei Konstellationen sprechen klar für Custom.

Der Prozess ist Ihr Verkaufs-Argument. Wenn Kunden Ihre Auftragsabwicklung, Ihre Konfigurations-Logik oder Ihr Kundenportal als Grund nennen, mit Ihnen zu arbeiten, dann gehört dieser Prozess nicht in eine fremde Roadmap. Sobald Sie Funktionen erst bekommen, wenn der Standard-Hersteller sie priorisiert, verlieren Sie Reaktions-Geschwindigkeit gegen Wettbewerber, die ihren eigenen Stack pflegen.

Die Geschäftslogik ist unüblich. Manche Mittelständler haben Prozesse, die in keinem Standardprodukt sauber abbildbar sind — Sondertarife, Mehr-Mandanten-Konstrukte mit eigener Preis-Logik, branchenspezifische Zertifizierungs-Workflows, regulatorische Sonderfälle. Wer hier Standard-Software erzwingt, verbringt drei Jahre mit Workarounds, die mit jedem Vendor-Update neu validiert werden müssen.

Sie wollen Datenhoheit und Roadmap-Kontrolle. Custom-Software bedeutet, dass Daten-Modell, Schnittstellen und Roadmap in Ihrer Hand bleiben. Sie entscheiden, wann Funktionen kommen, wie Datenexport funktioniert, in welcher Cloud die Anwendung läuft. Bei Standard-Software hängen Sie an der strategischen Ausrichtung des Herstellers — wenn der Vendor eine Plattform abkündigt, eine Migration erzwingt oder Preise verdoppelt, haben Sie wenig Hebel.

Wichtig: Custom heißt nicht "von Grund auf neu". In modernen Custom-Projekten besteht ein erheblicher Teil aus Open-Source-Bibliotheken, Cloud-Bausteinen und etablierten Frameworks. Was Sie selbst bauen, ist die Geschäftslogik und das Datenmodell — nicht das Authentifizierungs-System oder die Datenbank-Engine.

Hybrid — der häufigste Mittelweg

In der mittelständischen Praxis ist die häufigste sinnvolle Architektur weder reines Custom noch reines Standard, sondern eine bewusste Kombination. Standard-Software übernimmt Commodity-Domänen — Buchhaltung, Lohn, Standard-CRM, vielleicht ein Basis-ERP. Individuelle Module bilden den differenzierenden Geschäftsprozess ab — Konfigurator, Kundenportal, branchenspezifische Auftragsabwicklung. Verbunden wird beides über offene APIs, einen iPaaS-Connector wie Workato oder n8n, oder eine eigene Integrations-Schicht.

Drei Architektur-Prinzipien entscheiden über den Erfolg solcher Hybrid-Modelle. Erstens: Stammdaten-Hoheit klar geregelt — welches System ist führend für Kunden, welches für Artikel, welches für Mitarbeitende. Zweitens: asynchrone Kopplung wo möglich, damit eine kurze Auszeit des CRM nicht den Konfigurator lahmlegt. Drittens: dokumentierte Datenflüsse mit Monitoring, damit ein versehentlich abgeschalteter Job nicht erst nach drei Wochen bemerkt wird, wenn Rechnungen fehlen.

Die schlechte Variante dieser Architektur sehen wir leider oft: Standard-ERP, daneben fünf Excel-Tabellen, ein Access-Tool aus 2014 und ein selbstgebautes PHP-Portal ohne Dokumentation. Solche gewachsenen Hybriden sind kein Hybrid, sondern ein Schatten-Monolith — und sie sind ein typischer Anlass für eine Legacy-Modernisierung.

Bewertungs-Framework — vier Dimensionen

Damit die Entscheidung nicht in einem Bauchgefühl endet, hilft ein einfaches vierdimensionales Bewertungs-Raster. Jede Dimension lässt sich für den konkreten Prozess auf einer Skala von eins bis fünf einschätzen — die Summe gibt eine Indikation, in welche Richtung der Prozess gehört.

• Differenzierungs-WertWie stark trägt dieser Prozess zu Ihrem Wettbewerbs-Vorteil bei? Eins = Commodity, fünf = zentrales Verkaufs-Versprechen. Hohe Werte sprechen für Custom.
• Standard-ReifegradWie gut deckt der reife Standard-Markt Ihren Bedarf ab? Eins = kein passendes Produkt am Markt, fünf = etabliertes Produkt deckt 90 Prozent ohne Customizing. Hohe Werte sprechen für Standard.
• Veränderungs-FrequenzWie oft muss sich der Prozess in den nächsten fünf Jahren ändern? Eins = stabil, fünf = monatliche Anpassungen. Hohe Werte sprechen für Custom mit eigener Roadmap.
• Build-vs-Buy-TCOWie verhalten sich Lizenz-Kosten plus Customizing einer Standard-Lösung über fünf Jahre zu Build- plus Wartungs-Kosten einer Eigenentwicklung? Wenn die Standard-TCO mehr als 60 Prozent der Custom-TCO erreicht, kippt die Rechnung schnell Richtung Custom.

Faustregel aus unserer Beratungs-Praxis: wenn Differenzierungs-Wert und Veränderungs-Frequenz zusammen über sieben liegen UND der Standard-Reifegrad unter drei, gehört der Prozess fast immer in eine Custom-Lösung. Liegt der Standard-Reifegrad über vier und der Differenzierungs-Wert unter drei, ist Standard fast immer richtig. In der breiten Mitte ist Hybrid die typische Antwort.

Echte Zahlen — Lizenz vs Build über fünf Jahre

Die Wirtschaftlichkeits-Rechnung ist der Punkt, an dem viele Entscheidungen wackeln, weil die Zahlen nicht sauber gegenübergestellt werden. Die folgende Tabelle zeigt typische Spannen für ein mittelständisches Szenario — ein abteilungs-übergreifendes Anwendungs-System mit etwa 80 internen Nutzern und einer mittleren Komplexität. Sie ist als Orientierung gedacht, präzise Zahlen brauchen eine kurze Scope-Klärung. Für eine vertiefende Kosten-Modellierung siehe unsere Übersicht Softwareentwicklungs-Kosten 2026.

Kosten-Block	Standard-Software (5 J)	Custom-Software (5 J)
Lizenz oder Build	80.000–180.000 €	180.000–350.000 €
Einführung / Customizing	60.000–200.000 €	im Build enthalten
Wartung / Pflege (5 Jahre)	70.000–200.000 €	140.000–280.000 €
Schulung und Change-Management	20.000–60.000 €	15.000–40.000 €
Migrations-Risiko bei Vendor-Wechsel	hoch (50.000–250.000 €)	gering (Code im Eigenbesitz)
Summe Gesamtkosten 5 Jahre	230.000–640.000 €	335.000–670.000 €

Die Spannen überlappen erheblich — das ist kein Zufall, sondern die Realität. Standard-Software wirkt anfangs günstiger, weil die Lizenz-Kosten transparent sind und der Customizing-Aufwand unterschätzt wird. Custom wirkt anfangs teurer, weil die Build-Kosten sichtbar in der Investitions-Rechnung stehen. Über fünf Jahre nähern sich die Zahlen an. Ab Jahr sechs kippt die Rechnung in vielen Fällen Richtung Custom, weil die Standard-Lizenzen weiterlaufen, während der Custom-Build amortisiert ist und nur noch Pflege anfällt.

Vendor-Lock-in vs Code-Ownership

Ein Kostenblock, der in den meisten Vergleichs-Tabellen unterschlagen wird, ist das Wechsel-Risiko. Bei Standard-Software ist das Datenmodell, die Workflow-Logik und oft auch die Reporting-Definition an den Hersteller gebunden. Wenn dieser Preise verdoppelt, eine Plattform abkündigt oder unter neuer Eigentümerschaft strategisch umschwenkt, haben Sie zwei Optionen: zahlen oder migrieren. Die Migration ist regelmäßig teuer und mehrjährig — sechs- bis siebenstellige Migrations-Projekte sind im Mittelstand keine Seltenheit.

Bei Custom-Software gehört Ihnen der Code, das Datenmodell und das gesamte geistige Eigentum. Vendor-Wechsel kann hier zwei Dimensionen betreffen: den Cloud-Anbieter und das Entwicklungs-Team. Beide sind beherrschbarer als bei Standard, wenn die Architektur sauber ist — portable Container, dokumentierter Code, gepflegte Tests und ein Build-Prozess, den ein neues Team in vier Wochen verstehen kann.

Bei reinem Standard lässt sich Lock-in nie vollständig vermeiden, aber durch drei Praktiken deutlich reduzieren: vertragliche Datenexport-Pflichten mit maschinenlesbarem Format, eine eigene Adapter-Schicht in der Integrations-Architektur statt direkter Vendor-Kopplung, und regelmäßige Markt-Reviews alle drei Jahre mit dokumentierter Wechsel-Schätzung.

Wartungs-Aufwand Custom realistisch

Eine häufige Fehl-Annahme bei Custom-Projekten ist, dass nach dem ersten Release die Kosten weitgehend wegfallen. Das Gegenteil ist der Fall. Realistisch sind 15 bis 25 Prozent der ursprünglichen Build-Kosten pro Jahr für Pflege — und das ist kein Aufschlag für Pannen, sondern Substanz-Arbeit: Sicherheits-Updates der Bibliotheken, Aktualisierungen der Laufzeit-Umgebungen, Anpassungen an externe API-Änderungen, Bugfixes aus dem Betrieb, kleinere Verbesserungen aus dem Anwender-Feedback.

Wer mit niedrigeren Zahlen plant — viele Anbieter rechnen mit 8 bis 10 Prozent —, erlebt nach zwei bis drei Jahren typischerweise einen Modernisierungs-Stau. Veraltete Bibliotheken mit bekannten Sicherheits-Mängeln, ungepflegte Build-Pipelines, fehlende Test-Abdeckung, ein eingefrorenes Frontend in einer drei Versionen alten Framework-Generation. Der "günstige" Build wird dann zur teuren Modernisierung — siehe wieder unsere Legacy-Modernisierungs-Strategien.

Bei Standard-Software liegen die laufenden Lizenz- und Wartungs-Kosten meist zwischen 18 und 22 Prozent des Lizenz-Listenpreises pro Jahr — also in einer ähnlichen Größenordnung. Der Unterschied liegt eher in der Steuerungs-Tiefe als im absoluten Aufwand: bei Standard zahlen Sie eine fixe Quote und bekommen Hersteller-Updates, bei Custom entscheiden Sie selbst, welche Themen priorisiert werden.

Migrations-Pfade in beide Richtungen

Die Welt zerfällt nicht in "wir haben uns einmal entschieden". Mittelständler bewegen sich regelmäßig in beide Richtungen — und beide Pfade haben charakteristische Stolpersteine. Drei typische Konstellationen.

Standard ablösen. Wer von einem langjährig genutzten Standard-Produkt zu einer Custom-Lösung wechselt, unterschätzt regelmäßig den Daten-Migrations-Aufwand. Was im alten System sauber zusammengewachsen ist — historische Belege, Sonderfälle, vor zehn Jahren konfigurierte Workflows — muss in die neue Welt überführt werden, mit Validierung, Abnahme und Parallelbetrieb. Faustregel: Daten-Migration ist regelmäßig 20 bis 35 Prozent des gesamten Projekt-Aufwands.

Custom modernisieren. Wer eine gewachsene Eigenentwicklung modernisiert, steht vor der Wahl: schrittweise Strangler-Fig-Pattern mit parallelem Aufbau neuer Module oder Big-Bang-Neubau. In der Mittelstands-Praxis ist die schrittweise Variante fast immer richtig — sie liefert nach drei bis sechs Monaten erste produktive Verbesserungen statt eines zwei Jahre langen Black-Box-Projekts.

Hybrid neu schneiden. Wer eine gewachsene Hybrid-Landschaft saniert, beginnt mit einem ehrlichen Inventar: welcher Prozess läuft tatsächlich wo, welche Daten sind führend, welche Excel-Brücken laufen unbemerkt im Hintergrund. Erst danach lässt sich entscheiden, welche Teile in Standard wandern, welche in neue Custom-Module gehen und welche stillgelegt werden können.

Reepa-Methodik bei der Entscheidung

In unseren Beratungs-Mandaten arbeiten wir die Custom-vs-Standard-Frage in einem fünfstufigen Vorgehen ab. Die Stufen lassen sich in der Regel in vier bis acht Wochen abschließen, abhängig von der Größe der betroffenen Anwendungs-Landschaft.

Prozess-Inventar. Wir kartieren die betroffenen Geschäftsprozesse mit Fachbereich und IT gemeinsam, dokumentieren Datenflüsse und Schnittstellen und markieren Schmerzpunkte. Ergebnis ist eine sortierte Liste der Prozesse mit Differenzierungs-Wert und aktueller Lösungs-Lage.

Markt-Scan. Für jeden Prozess prüfen wir den Standard-Markt — welche Produkte gibt es, wie reif sind sie, welche Referenzen gibt es im deutschen Mittelstand, welche typischen Customizing-Quoten berichten Anwender. Daraus ergibt sich der Standard-Reifegrad pro Prozess.

TCO-Modellierung. Wir rechnen für die strittigen Prozesse ein Fünf-Jahres-Szenario in beiden Richtungen — Standard plus Customizing gegen Custom-Build plus Pflege. Annahmen werden explizit dokumentiert, damit die Geschäftsführung nachvollziehen kann, an welcher Stelle die Rechnung wackelt.

Architektur-Skizze. Wir entwerfen die Ziel-Architektur — welche Domänen kommen in Standard, welche in Custom, wie sieht die Integrations-Schicht aus, welche Stammdaten-Hoheit liegt wo. Dazu eine grobe Migrations-Reihenfolge mit Risiko-Annotation.

Roadmap und Quick-Wins. Aus der Architektur leiten wir eine Umsetzungs-Roadmap über 18 bis 36 Monate ab, mit klar definierten Quick-Wins in den ersten 90 Tagen, damit das Vorhaben Schwung gewinnt und früh sichtbare Ergebnisse liefert.

Die Methodik ist bewusst pragmatisch — wir liefern eine Entscheidungs-Vorlage, nicht ein 200-seitiges Strategie-Papier, das in der Schublade verstaubt. In der Regel ist die Geschäftsführung nach Stufe drei in der Lage, eine fundierte Build-oder-Buy-Entscheidung zu treffen.

Häufige Fragen