Legacy-Software modernisieren. Geschäftslogik erhalten.
Ihre Individualsoftware trägt einen wichtigen Prozess, aber kaum jemand versteht sie noch vollständig. Ich mache mit KI-gestützter Analyse nachvollziehbar, was die Anwendung tatsächlich tut, prüfe das mit Ihren Fachleuten und entscheide mit Ihnen, ob stabilisieren, schrittweise erneuern oder ablösen der wirtschaftlich sinnvolle Weg ist.
- Bestandsaufnahme von Code, Daten und Abhängigkeiten
- Geschäftsregeln dokumentiert und fachlich bestätigt
- Optionen mit Risiken statt Bauchentscheidung
- Umsetzung schrittweise, mit Tests und Rückfallweg
Die Anwendung läuft. Die Abhängigkeit wächst.
Viele Mittelständler arbeiten mit Software, die vor zehn oder zwanzig Jahren für sie gebaut wurde: eine Kalkulation, eine Auftragsverwaltung, eine Access-Datenbank, die aus einer Abteilung heraus gewachsen ist. Solche Anwendungen bezeichnet man als Legacy-Software. Sie funktionieren, oft sogar gut, und genau deshalb fasst sie niemand gern an.
Schwierig wird es, wenn mehrere Dinge zusammenkommen: Der Entwickler ist im Ruhestand oder nicht mehr erreichbar. Die Dokumentation fehlt. Die Laufzeitumgebung bekommt keine Sicherheitsupdates mehr, neue Schnittstellen lassen sich kaum anbinden, und jede Änderung fühlt sich wie ein Risiko an.
Ein kompletter Neubau ist dann selten die erste richtige Antwort. Zuerst muss klar sein, welche Regeln in der Software stecken, welche davon Ihr Geschäft wirklich braucht und welche nur historisch gewachsen sind. Erst danach lässt sich entscheiden, was mit der Anwendung passieren soll.
Wenn Individualsoftware einen wichtigen Prozess trägt
Produzierende Unternehmen
Eine eigene Anwendung trägt Kalkulation oder Arbeitsvorbereitung, häufig auf .NET-Basis. Die Sorge: Im laufenden Betrieb darf nichts kaputtgehen. Der Einstieg ist deshalb ein Teil, der die Produktion nicht unmittelbar steuert.
Technischer Großhandel
Preis- und Dispositionsregeln stecken in älteren Masken und Datenbankabfragen. Bevor über ein Standardsystem entschieden wird, sollte klar sein, welche Sonderregeln wirklich nötig sind.
Technische Dienstleister
Berichte, Prüfprotokolle und Freigaben laufen über eine gewachsene Access- oder VBA-Lösung. Hier eignet sich oft ein enger Einstieg bei einem Bericht oder einem Freigabeschritt.
E-Commerce und Portale
Ein selbst entwickeltes Bestell- oder Verwaltungsportal auf älterem PHP oder JavaScript blockiert Updates und neue Anbindungen. Wichtig sind abgegrenzte Schnittstellen und geprüfte Datenflüsse.
Kleine Softwareanbieter
Ein eigenes Produkt ist über Jahre gewachsen, Versionen und Dokumentation passen nicht mehr zusammen. Gemeinsam mit Ihrem Team untersuche ich gezielt einzelne Funktionen und dokumentiere den Bestand.
Ihre Lage ist eine andere?
Entscheidend ist nicht die Branche, sondern ob die Software einen wichtigen Prozess trägt und ob Quellcode, Exporte und Fachleute verfügbar sind. Das klären wir im Erstgespräch.
Zuerst verstehen, was Ihre Software tatsächlich tut
KI-gestützte Analyse heißt bei mir: Ein KI-Assistent liest den Quellcode und die Datenstrukturen, erklärt Zusammenhänge und verweist auf die Stellen, an denen eine Regel steht. Das spart viel Lesearbeit. Entscheidend bleibt, dass Menschen die Ergebnisse prüfen.
1. Technischen Bestand lesen
Quellcode, Datenbank, Exporte und Schnittstellen werden systematisch untersucht. Ergebnis ist eine Übersicht: Welche Module gibt es, welche Daten fließen wohin, welche Bibliotheken und Laufzeiten werden gebraucht. Jede Aussage verweist auf ihre Fundstelle.
2. Fachlich bestätigen
Eine aus dem Code abgeleitete Regel ist erst einmal eine Vermutung. Ihre Fachleute prüfen sie an echten Beispielen und Ausnahmen. So entstehen Referenzfälle: festgehaltene Eingaben mit dem erwarteten Ergebnis, gegen die später jede Änderung getestet wird.
3. Entscheiden, dann umsetzen
Mit dokumentierten Regeln und bekannten Risiken lässt sich sachlich entscheiden: weiterbetreiben, kapseln, teilweise erneuern oder ablösen. Umgesetzt wird schrittweise, Modul für Modul, mit Tests gegen die Referenzfälle.
Eine abgegrenzte Machbarkeitsanalyse mit verwertbarem Ergebnis
Nach dem kostenlosen Erstgespräch beginnt die Arbeit mit einer bezahlten Machbarkeitsanalyse. Umfang, Untersuchungsgrenzen und Abbruchkriterien legen wir vorher schriftlich fest, damit die Analyse nicht ausufert. Den Preis nenne ich nach dem Erstgespräch, wenn der Umfang klar ist.
Systemübersicht
Module, Datenbanken, Schnittstellen, Bibliotheken und Laufzeiten, dazu die Personen, die etwas über das System wissen. Was fehlt oder nicht untersucht werden konnte, steht ausdrücklich dabei.
Beschriebene Geschäftslogik
Die wichtigsten Regeln des untersuchten Bereichs in verständlicher Sprache, mit Fundstelle und dem Vermerk, ob sie fachlich bestätigt oder noch offen ist.
Risiken und offene Fragen
Fehlende Tests, veraltete Komponenten, unklare Rechte, kritische Datenflüsse. Jeweils mit der Folge für Ihren Betrieb und dem, was zur Klärung nötig ist.
Optionen mit Pilotvorschlag
Die sinnvollen Wege im Vergleich, mit Aufwandstreibern und Risiken. Dazu ein Vorschlag, mit welchem abgegrenzten Modul ein Pilot beginnen könnte, oder die Empfehlung, die Software vorerst weiterzubetreiben.
Die Sprache allein entscheidet nicht
Ob sich eine Anwendung gut modernisieren lässt, hängt weniger von der Programmiersprache ab als davon, ob Quellcode, Datenbank, die Werkzeuge zum Erstellen des Programms (Build-Umgebung) und Fachwissen verfügbar sind. Diese Ausgangslagen kommen häufig vor:
.NET-Framework-Anwendungen
Interne Fach- und Desktop-Anwendungen in C# oder VB.NET. Ziel kann ein aktuelles .NET sein oder eine Web-Anwendung für einzelne Module. Zu prüfen sind Windows-Abhängigkeiten und eingebundene Komponenten.
JavaScript, TypeScript, Electron
Portale, Oberflächen und Desktop-Werkzeuge auf älteren Bibliotheken, auch Desktop-Programme auf Web-Technik (Electron). Häufig lässt sich die Fachlogik herauslösen und in eine aktuelle Anwendung überführen.
Ältere PHP- und Java-Anwendungen
Portale, Shop-Ergänzungen und Verwaltungsanwendungen, deren Laufzeitversion keine Sicherheitsupdates mehr erhält. Typisch ist ein schrittweiser Umbau statt eines großen Wechsels.
Access und VBA
Abteilungsdatenbanken mit Formularen, Berichten und Makros. Die Objektdefinitionen lassen sich als Text exportieren und untersuchen. Ziel kann eine zentrale Datenbank mit Web-Oberfläche sein, manchmal auch ein gepflegter Weiterbetrieb.
Visual Basic 6 und Delphi
Gewachsene Windows-Fachanwendungen. Sinnvoll nur, wenn der Quellcode vollständig vorliegt; eingebundene Fremdkomponenten (Steuerelemente, Bibliotheken) prüfe ich im Einzelfall vorab.
COBOL, RPG, FoxPro, Low-Code
Hier biete ich Analyse und Dokumentation nach einer gesonderten Vorprüfung an, aber keine Migration von Großrechner- oder Spezialsystemen. Dafür braucht es spezialisierte Teams und Testsysteme.
So könnte eine Modernisierung aussehen
Die folgenden Beispiele sind frei erfunden. Sie beschreiben typische Ausgangslagen und zeigen, wie ein Vorgehen aussehen könnte. Es handelt sich nicht um Kundenprojekte.
- Fiktives Beispiel
Kalkulation in der Fertigung
Fiktiver Maschinenbauzulieferer, etwa 180 Beschäftigte
- Bestand
- Selbst entwickelte Kalkulationsanwendung, .NET Framework mit SQL-Datenbank
- Problem
- Der Entwickler geht in den Ruhestand. Zuschlagsregeln für Sonderanfertigungen kennt nur er.
- Möglicher Ansatz
- Analyse der Kalkulationsmodule, Regeln mit Arbeitsvorbereitung und Vertrieb an Beispielaufträgen bestätigen, Referenzfälle festhalten.
- Mögliches Ziel
- Kalkulation als eigenständiges Modul in aktuellem .NET oder als Web-Anwendung mit Schnittstelle zum ERP
- Möglicher Nutzen
- Die Kalkulationslogik wäre dokumentiert und prüfbar, die Abhängigkeit von einer Person geringer.
- Grenzen und Voraussetzungen
- Setzt vollständigen Quellcode und Fachleute mit Zeit für die Prüfung voraus. Produktionssteuernde Funktionen bleiben zunächst unberührt.
- Fiktives Beispiel
Sonderpreise im Großhandel
Fiktiver technischer Großhändler, etwa 90 Beschäftigte
- Bestand
- Ergänzung zur Warenwirtschaft in Visual Basic 6 für Kundenpreise und Staffeln
- Problem
- Die Entwicklungsumgebung ist veraltet, Änderungen an Preisregeln dauern lange, ein Systemwechsel steht im Raum.
- Möglicher Ansatz
- Preisregeln aus dem Code ableiten, mit Vertrieb und Einkauf abgleichen, unnötige Sonderfälle aussortieren.
- Mögliches Ziel
- Entscheidungsvorlage: Standardsystem mit wenigen Erweiterungen oder kleine eigene Preisanwendung
- Möglicher Nutzen
- Die Auswahl eines Nachfolgesystems könnte sich auf die tatsächlich benötigten Regeln stützen.
- Grenzen und Voraussetzungen
- Fremdkomponenten und Datenbankzugriffe müssen vorab geprüft werden; ohne vollständigen Quellcode bleibt die Analyse lückenhaft.
- Fiktives Beispiel
Prüfberichte beim Dienstleister
Fiktives Prüf- und Ingenieurbüro, etwa 40 Beschäftigte
- Bestand
- Access-Datenbank mit VBA für Prüfprotokolle und Berichte
- Problem
- Mehrere Personen arbeiten gleichzeitig, die Datei wird langsam und fehleranfällig, Auswertungen sind mühsam.
- Möglicher Ansatz
- Export der Formulare, Abfragen und Module, Datenmodell bereinigen, einen Berichtsprozess als Pilot herauslösen.
- Mögliches Ziel
- Zentrale Datenbank mit browserbasierter Oberfläche, Access zunächst parallel
- Möglicher Nutzen
- Mehrbenutzerbetrieb und Auswertungen könnten verlässlicher werden, ohne alles auf einmal umzustellen.
- Grenzen und Voraussetzungen
- Makros und Office-Verhalten sind kontextabhängig. Fachliche Freigaben im Prüfprozess müssen besonders sorgfältig getestet werden.
- Fiktives Beispiel
Bestellportal im Onlinehandel
Fiktiver B2B-Onlinehändler, etwa 60 Beschäftigte
- Bestand
- Eigenes Kundenportal auf einer PHP-Version ohne Sicherheitsupdates
- Problem
- Neue Zahlungs- und Versandanbindungen scheitern an der alten Basis, Updates traut sich niemand zu.
- Möglicher Ansatz
- Datenflüsse und Schnittstellen dokumentieren, Anmeldung und Bestellstrecke mit Referenzfällen absichern, schrittweiser Umbau.
- Mögliches Ziel
- Aktuelle Laufzeitversion oder neue Web-Anwendung, Modul für Modul mit klaren Schnittstellen
- Möglicher Nutzen
- Das Portal könnte wieder aktualisierbar werden; neue Anbindungen ließen sich gezielt ergänzen.
- Grenzen und Voraussetzungen
- Bestellungen und Kundendaten dürfen nicht gefährdet werden: Umstellung nur mit Testumgebung, Datenabgleich und Rückfallweg.
- Fiktives Beispiel
Dokumentation für ein eigenes Produkt
Fiktiver Softwareanbieter, etwa 25 Beschäftigte
- Bestand
- Desktop-Werkzeug auf Electron-Basis mit JavaScript-Bibliotheken aus mehreren Jahren
- Problem
- Ein Teil des Teams ist gewechselt, Versionen und Dokumentation passen nicht zusammen, eine Funktion verhält sich unerklärlich.
- Möglicher Ansatz
- Gezielte Untersuchung dieser Funktion gemeinsam mit dem Team, Abhängigkeiten inventarisieren, Bestandsdokumentation aufbauen.
- Mögliches Ziel
- Aktualisierte Bibliotheken, getrennte Fachlogik, dokumentierter Build
- Möglicher Nutzen
- Das Team könnte das Produkt wieder mit mehr Sicherheit weiterentwickeln.
- Grenzen und Voraussetzungen
- Die Analyse ersetzt keine Produktverantwortung. Bei großen, für die Auslieferung stark komprimierten (minifizierten) Beständen wird der Umfang vorab eng abgegrenzt.
Nicht jede Altsoftware muss neu gebaut werden
Welcher Weg sinnvoll ist, entscheidet sich am Vergleich über denselben Zeitraum: Analyse, Entwicklung oder Kauf, Datenübernahme, Tests, Parallelbetrieb, Schulung, Wartung und das verbleibende Risiko.
Stabilisieren
Die Anwendung erfüllt ihren Zweck, eine große Investition lohnt sich voraussichtlich nicht. Dann verbessern wir Dokumentation, Tests und Betrieb und senken so die Abhängigkeit.
Kapseln
Die Fachlogik ist wertvoll, aber die Verbindung zu anderen Systemen fehlt. Eine Schnittstelle um das Altsystem herum macht seine Daten und Funktionen nutzbar, ohne es umzubauen.
Teilweise erneuern
Einzelne Funktionen sind abgrenzbar. Sie werden nacheinander ersetzt, während der Rest weiterläuft. Das ist häufig ein risikoarmer Weg zu einer neuen Lösung.
Standardsoftware
Der Bedarf ist weitgehend Standard, und die Besonderheiten lassen sich sinnvoll reduzieren. Dann ist ein käufliches System oft günstiger und langlebiger als eine Eigenentwicklung.
Neu entwickeln
Anforderungen und bestehende Architektur passen nicht mehr zusammen. Eine Neuentwicklung muss sich gegen Gesamtaufwand und Übergangsrisiko behaupten und wird trotzdem schrittweise eingeführt.
Was KI-gestützte Analyse leisten kann und was nicht
Sie kann …
- großen, schlecht dokumentierten Code deutlich schneller lesbar machen als reine Handarbeit
- Zusammenhänge zwischen Modulen, Daten und Schnittstellen sichtbar machen
- Regeln mit Fundstelle beschreiben, sodass Fachleute sie gezielt prüfen können
- bei der Umsetzung Code erzeugen und ändern, der gegen Referenzfälle getestet wird
Sie kann nicht …
- eine Altsoftware vollautomatisch und fehlerfrei in eine neue übertragen
- fachliche Bedeutung garantieren: Eine plausible Erklärung kann falsch sein
- fehlende Quellen, Tests oder Fachleute ersetzen
- Verantwortung für Abnahme, Datenrichtigkeit und Betrieb übernehmen
Deshalb trenne ich in jedem Ergebnis drei Dinge: was technisch gefunden wurde, was fachlich bestätigt ist und was noch offen ist.
Von der Bestandsaufnahme zur kontrollierten Übergabe
- Schritt 01
Erstprüfung und Rechte
Geschäftsprozess, Ziele und Verantwortliche klären. Dazu die Frage, wem der Quellcode gehört und welche Nutzungsrechte bestehen. Davon hängt ab, wie tief untersucht werden darf.
- Schritt 02
Inventarisierung
Quellcode, Programme, Bibliotheken, Datenbanken und Schnittstellen erfassen. Ein unveränderlicher Stand wird gesichert, damit alle Befunde nachvollziehbar bleiben.
- Schritt 03
Rekonstruktion
Technische Befunde mit KI-Unterstützung dokumentieren und mit Ihren Fachleuten an Beispielen prüfen. Daraus entstehen Referenzfälle.
- Schritt 04
Zielbild und Strategie
Optionen vergleichen, Zielarchitektur skizzieren, Reihenfolge und Abbruchkriterien festlegen. Sie entscheiden auf Basis einer schriftlichen Vorlage.
- Schritt 05
Pilotmodul
Ein abgegrenzter Teil wird umgesetzt und gegen die Referenzfälle getestet, mit vorher vereinbarten Abnahmekriterien.
- Schritt 06
Schrittweise Umsetzung
Weitere Module folgen nacheinander. Daten werden abgeglichen, ein Rückfallweg bleibt bis zur Abnahme bestehen.
- Schritt 07
Übergabe
Dokumentation, Betrieb und Zuständigkeiten werden übergeben. Quellcode und Zugänge liegen bei Ihnen, damit auch ein anderer Entwickler übernehmen kann.
Untersucht wird in einer getrennten Testumgebung, nicht am Produktivsystem. Analyse, Pilot und Umsetzung werden getrennt beauftragt; nach jeder Stufe können Sie neu entscheiden.
Kann die Analyse gefördert werden?
Die Analyse- und Beratungsphase kann unter Umständen über die BAFA-Förderung für Unternehmensberatung bezuschusst werden. Das hängt von Ihrem Unternehmen und den aktuellen Förderbedingungen ab und muss vor Auftragsbeginn geprüft werden. Für Programmierung und Umsetzung gilt diese Förderung in der Regel nicht.
Zur BAFA-FörderungWann die Modernisierung passt und wann nicht
Das passt, wenn …
- Eine Individualsoftware trägt einen Prozess, der für Ihr Geschäft wichtig ist
- Quellcode, Datenbank oder Exporte sind zugänglich
- Fachleute, die den Prozess kennen, können Zeit für Prüfungen einplanen
- Sie wollen erst verstehen und dann entscheiden, statt sofort neu zu bauen
Das passt eher nicht, wenn …
- Erwartet wird eine vollautomatische Übertragung ohne fachliche Mitwirkung
- Es geht um Großrechner-Kernsysteme, etwa bei Banken oder Versicherungen
- Die Software steuert sicherheitskritische Anlagen oder Medizingeräte
- Die Rechte an der Software sind unklar und lassen sich nicht klären
Wenn Sie unsicher sind, klären wir das im Erstgespräch.
Das könnte Sie auch interessieren
Der Überblick: Software-Implementierung
Wie die Modernisierung in die Kette aus Prozess, Architektur, Umsetzung, Go-live und Betrieb passt.
Wenn Altdaten mitkommen: Datenmigration
Profiling, Mapping, Bereinigung und Testlauf, damit beim Wechsel keine Daten verloren gehen.
Das Ziel: eigene Web-App
Wenn am Ende eine neue Anwendung steht: Grundsätze, Vorgehen und wem der Code gehört.
Altsystem anbinden: API-Integration
Wenn das Altsystem bleibt, aber über eine Schnittstelle mit anderen Systemen sprechen soll.
Häufige Fragen zur Softwaremodernisierung
Legacy-Software ist Software, die weiter im Einsatz ist, obwohl ihre Technik veraltet ist oder sie sich nur noch schwer pflegen lässt. Oft ist sie für einen bestimmten Prozess entwickelt worden und enthält Regeln, die sonst nirgends dokumentiert sind. Alt heißt dabei nicht automatisch schlecht: Viele dieser Anwendungen erfüllen ihren Zweck zuverlässig.
Nein, nicht verlässlich. KI-Assistenten können Code lesen, erklären und neuen Code erzeugen, und das beschleunigt die Arbeit. Ob die neue Software fachlich dasselbe tut wie die alte, zeigt aber erst ein Test gegen festgehaltene Referenzfälle, die Ihre Fachleute bestätigt haben. Deshalb biete ich einen begleiteten, schrittweisen Prozess an und keine Knopfdruck-Migration.
KI-Assistenten können die meisten textbasierten Programmiersprachen lesen, darunter C#, VB.NET, Java, PHP, JavaScript und TypeScript, Visual Basic, Delphi/Pascal oder COBOL. Lesen ist aber nicht dasselbe wie sicher umbauen: Dafür braucht es passende Compiler, Laufzeiten, Datenbanken und Tests. Schwerpunkt meiner Umsetzung sind .NET-, JavaScript-/TypeScript-, PHP- und Java-Bestände; Access, VBA, Visual Basic 6 und Delphi prüfe ich im Einzelfall. Großrechner- und Spezialsysteme untersuche und dokumentiere ich nach Vorprüfung, migriere sie aber nicht.
Dann wird es schwieriger, aber nicht in jedem Fall aussichtslos. Bei manchen Technologien, etwa .NET- oder JavaScript-Anwendungen, lassen sich aus den ausgelieferten Programmdateien technische Zusammenhänge untersuchen, sofern sie nicht bewusst verschleiert wurden. Ob das zulässig ist, hängt von Ihren Rechten an der Software ab, denn das Urheberrecht erlaubt das Zurückübersetzen von Programmcode (Dekompilierung) nur in engen Grenzen. Ohne diese Rechte beschränke ich mich darauf, das Verhalten der Anwendung zu beobachten und zu testen und Daten und Schnittstellen auszuwerten. Wie weit das trägt, zeigt erst eine Vorprüfung; vorher sage ich nichts zu.
Nicht automatisch. Hat ein externer Dienstleister die Software entwickelt, haben Sie die Rechte, die im damaligen Vertrag vereinbart wurden; das Recht, den Code zu bearbeiten, liegt nicht immer bei Ihnen. Haben eigene Angestellte sie im Rahmen ihrer Arbeit geschrieben, liegen die Rechte in der Regel beim Unternehmen. Deshalb ist die Frage nach Verträgen und Rechten der erste Schritt jeder Analyse. Die rechtliche Bewertung übernimmt Ihr Anwalt, eine Rechtsberatung gebe ich nicht.
Das ist der Normalfall bei älterer Individualsoftware. Bevor etwas geändert wird, halten wir deshalb Referenzfälle fest: typische Eingaben, Sonderfälle und das Ergebnis, das die alte Software dafür liefert. Gegen diese Fälle wird jede neue Version geprüft. Kritische Funktionen gehen ohne bestandene Prüfung nicht in den Betrieb.
Nein. Häufig ist es sinnvoller, sie zu stabilisieren oder über eine Schnittstelle anzubinden und nur einzelne Teile zu erneuern. Welcher Weg passt, ist das Ergebnis der Machbarkeitsanalyse. Wenn Weiterbetrieb die wirtschaftlichere Lösung ist, sage ich das.
Das legen wir vor Beginn schriftlich fest: welche Unterlagen ich erhalte, mit welchen Werkzeugen und wo sie verarbeitet werden und ob echte Daten überhaupt nötig sind. Für die Analyse genügen meist bereinigte Testdaten. Die Einzelheiten bespreche ich gern im Erstgespräch.
Das hängt von Größe und Zustand des Bestands, der Verfügbarkeit von Quellcode und Fachleuten, der Datenlage und dem gewählten Weg ab. Deshalb steht hier kein Betrag. Den Preis der Machbarkeitsanalyse nenne ich nach dem Erstgespräch; für Pilot und Umsetzung gibt es danach ein eigenes schriftliches Angebot.
Ich verantworte Analyse, Dokumentation, Planung und Umsetzung. Sie benennen Fachleute, die Regeln und Ergebnisse prüfen, und entscheiden über Anforderungen und Abnahme. Sicherheitskritische Steuerungen oder Medizingeräte übernehme ich nicht; bei anderen regulierten Teilen müssen zusätzliche Spezialisten hinzukommen.
Die Analyse- und Beratungsphase kann unter Umständen über die BAFA-Förderung für Unternehmensberatung bezuschusst werden. Ob das in Ihrem Fall möglich ist, prüfen wir vor Auftragsbeginn. Programmierung und Umsetzung sind in der Regel nicht förderfähig.
Klären Sie zuerst, welcher Weg für Ihre Software sinnvoll ist.
Im kostenlosen Erstgespräch sprechen wir über Ihre Anwendung, den Prozess dahinter und das, was sich ändern soll. Danach wissen Sie, ob eine Machbarkeitsanalyse sinnvoll ist. 30 Minuten, unverbindlich.
Welche Anwendung möchten Sie zukunftsfähig machen?
Zwei bis drei Sätze genügen: Was macht die Anwendung, wer nutzt sie, und was soll sich ändern? Bitte senden Sie mit der ersten Anfrage keinen Quellcode, keine Zugangsdaten und keine vertraulichen Unterlagen.
Persönliche Begleitung durch Timo Rüdiger- Unverbindliche Anfrage
- Keine vertraulichen Unterlagen für den Erstkontakt nötig
Lieber direkt Kontakt aufnehmen?