Modernisierung von Altsystemen
Die Anwendung modernisieren, von der alles abhängt.
Ein 2008 selbst entwickeltes „ CRM “, eine Access-Datenbank zur Abrechnungssteuerung, ein Planungstool, das ein inzwischen nicht mehr existierender Dienstleister ohne Dokumentation hinterlassen hat. Diese Anwendungen funktionieren – und genau das macht die Entscheidung so schwierig. Wir übernehmen sie, dokumentieren sie und stellen sie auf eine tragfähige Grundlage – ohne den Betrieb zu unterbrechen.
Eine Legacy-Anwendung fällt nicht aus: Vielmehr wird ihre Umgebung zu den veröffentlichten Terminen nicht mehr unterstützt. Seit dem 30. April 2026 versendet eine Anwendung, die ihre E-Mails mit Benutzername und Passwort versendet, diese nicht mehr. Am1. Oktober 2026 wird die EWS-Schnittstelle vonExchange Online standardmäßig geschlossen. Am 12. Januar 2027 Windows Server 2016 und das .NET Framework 4.6.2 am selben Tag aus dem Support genommen.
Der Zeitplan, der entscheidend ist
Was altert, ist der Boden unter ihr.
Eine Software, die vor fünfzehn Jahren geschrieben wurde, macht heute genau das, was sie gestern gemacht hat. Was sich ändert, sind das Betriebssystem, die Datenbank, die Framework-Software und die Dienste, mit denen sie kommuniziert – und für diese sind die End-of-Support-Termine veröffentlicht worden. Hier sind sie, so wie Microsoft sie angekündigt hat.
30. April 2026
Schon vorbei
14. Juli 2026
Schon vorbei
1. Oktober 2026
Wochen
10. November 2026
Wochen
12. Januar 2027
In diesem Jahr
April 2027
Nächstes Jahr
Um das Jahr 2027 herum
Im Blick behalten
9. Januar 2029
Horizont
Mindestens 2029
Eine Atempause
Diese Termine sind keine Verkaufsargumente, sondern terminliche Vorgaben. Sie bestimmen die Reihenfolge der Arbeitsschritte und schließen bestimmte Vorgehensweisen aus – man kann eine Anwendung, deren Server im Januar außer Betrieb geht, nicht innerhalb von zehn Wochen neu entwickeln. Aus diesem Grund ist unser erster Schritt eine Bestandsaufnahme und kein Architekturvorschlag.
Meine App lokalisierenWorum geht es hier?
„Überliefert“ bedeutet nicht „alt“.
Das Alter sagt nichts aus. Wir nutzen Anwendungen, die schon zwanzig Jahre alt sind und fast nichts kosten, und wir haben andere übernommen, die erst fünf Jahre alt waren und bereits unüberschaubar waren. Was zählt, sind diese fünf Anzeichen – und schon zwei davon reichen aus, damit das Thema eine Diskussion wert ist.
01
Nur eine einzige Person weiß, wie man sie wieder in Gang bringt
Wissen steckt im Kopf, nicht in einem Dokument. An dem Tag, an dem diese Person in den Urlaub fährt, den Arbeitgeber wechselt oder in den Ruhestand geht, stellt das Unternehmen fest, dass es von ihr abhängig ist und nicht von seiner Software. Das ist das häufigste Risiko, für das am wenigsten Rückstellungen gebildet werden.
02
Niemand kann sagen, was darin enthalten ist
Keine Spezifikationen, kein aktuelles Datenschema, keine Liste der Geschäftsregeln. Einfache Fragen bleiben unbeantwortet: Wie viele aktive Kunden gibt es? Welche Regel bestimmt diesen Rabatt? Warum enthält dieses Feld manchmal ein Datum? Eine Anwendung, die sich nicht beschreiben lässt, kann weder geprüft noch ersetzt werden.
03
Jede Weiterentwicklung kostet mehr als die vorherige
Die Kosten für das Hinzufügen eines Feldes haben sich innerhalb von drei Jahren verdoppelt. Jede Änderung führt zu weiteren Problemen, daher nehmen wir keine Änderungen mehr vor: Wir umgehen das Problem stattdessen mit einer Tabellenkalkulation, doppelten Eingaben und einer manuellen Bearbeitung am Freitag. Die tatsächlichen Kosten erscheinen nicht mehr auf der IT-Rechnung, sondern verteilen sich auf die Fachabteilungen.
04
Sie blockiert ein weiteres Projekt
Die Server- migration n steht noch aus, die Umstellung auf Microsoft 365 wartet, die Erneuerung der Stellen wartet – denn diese Anwendung läuft nur auf dieser Version der Windows, dieser Datenbankversion, diesem Browser. Sie ist nicht teuer: Sie kostet alle anderen Projekte.
05
Das hält vor einem Zuhörer nicht stand
Keine Nachverfolgbarkeit der Zugriffe, kein Änderungsprotokoll, gemeinsam genutzte Passwörter, unbefristete Speicherung personenbezogener Daten, eine Sicherung, die noch nie wirklich wiederhergestellt wurde. Die Frage kommt nicht mehr aus der IT: Sie kommt von einer Aufsichtsbehörde, einem Versicherer, einem Kunden, der einen Sicherheitsfragebogen verlangt, oder aus dem Datenschutzbereich.
Das Gegenteil trifft ebenfalls zu
Eine Anwendung, die zwei Tage im Jahr in Anspruch nimmt, lässt sich nicht modernisieren.
Wenn sie ihre Aufgabe erfüllt, keine Hindernisse verursacht, von zwei Personen bedient werden kann und keine sensiblen Daten speichert: Dann lässt man sie in Ruhe und notiert sich das Datum, an dem sie überprüft werden muss. Das ist eine häufige Schlussfolgerung unserer Audits, und das halten wir schwarz auf weiß fest. Ein Dienstleister, der in jeder Anwendung ein Projekt findet, hat kein Audit durchgeführt, sondern einen Kostenvoranschlag erstellt.
Die Diagnose
Fünf Fragen und eine bestimmte Laufbahn.
Es gibt sieben Möglichkeiten, eine Altanwendung zu behandeln, und bei sechs davon muss sie nicht neu geschrieben werden. Beantworten Sie fünf Fragen: Wir nennen Ihnen die von uns vorgeschlagene Vorgehensweise, den damit verbundenen zu beachtenden Punkt und eine vergleichbare veröffentlichte Ausschreibung. Sie müssen keine Kontaktdaten angeben, es wird nichts versendet und nichts gespeichert.
Beantworten Sie die fünf Fragen.
Die Schlussfolgerung wird genau hier, auf dieser Seite, formuliert. Es muss keine Adresse angegeben werden, um sie zu lesen, und manchmal lautet sie, dass man nichts tun soll.
Die Flugbahn
Aufbewahren – und für Sicherheit sorgen
Wahrscheinlich muss nichts umgeschrieben werden.
Es brennt nichts: Eine sinnvolle Investition ist kein Projekt, sondern eine datierte Bestandsaufnahme. Wir erstellen eine Bestandsliste, dokumentieren, was noch niemand schriftlich festgehalten hat, erfassen nicht mehr unterstützte Komponenten mit ihren Ablaufterminen und sichern die Umgebung der Anwendung ab – tatsächlich wiederherstellbare Backups, benutzerspezifische Zugriffsrechte, Protokollierung. Am Ende haben Sie einen Plan und einen Zeitplan, keine Baustelle.
Umzug
Erst umziehen, dann entscheiden.
Eine kurze Frist und ein Dienst, der nicht unterbrochen werden darf: Die einzig vernünftige Vorgehensweise besteht darin, die Anwendung vom Server, der abgeschaltet wird, zu entfernen, ohne sie zu verändern. Sie läuft unverändert auf einer unterstützten Plattform weiter – seien es virtuelle Maschinen Azure oder einer erneuerten lokalen Infrastruktur – mit den dazugehörigen Sicherungen und der entsprechenden Überwachung. Das verbessert die Anwendung nicht, sondern verschafft Zeit, um eine fundierte Entscheidung zu treffen.
Plattformumstellung
Den Sockel austauschen, den Code beibehalten.
Dies ist der häufigste und zugleich am meisten unterschätzte Weg. Die Geschäftslogik wird nicht neu geschrieben: Man baut das Backend neu auf, migriert die Datenbank auf eine unterstützte Version oder auf Azure SQL, ersetzt die Zugriffe, die wegfallen werden, und baut die Lieferkette neu auf. Die Anwendung erbringt denselben Dienst auf einer Grundlage, die noch zehn Jahre hält – und das zu einem Bruchteil der Kosten einer Neuprogrammierung.
Kapselung
Es hinter einer Benutzeroberfläche einsperren.
Was man nicht lesen kann, schreibt man nicht neu, und man wirft es auch nicht weg, solange es noch seinen Zweck erfüllt. Wir stellen es ordnungsgemäß über einen dokumentierten Webservice bereit und bauen dann das Neue darum herum auf: Die neuen Anwendungsfälle laufen über die Schnittstelle, der alte Kern läuft weiter und wird anschließend Stück für Stück ersetzt. Die Regel, die hier wie überall gilt: Was spezifisch ist, existiert separat, außerhalb der Anwendung, die es nutzt, und außerhalb des Systems, das die Ergebnisse verbraucht – und ist somit testbar, versionierbar und überwachbar.
Ersatz
Ein Produkt auf dem Markt – und die damit verbundene Integration.
Wenn ein Produkt den Bedarf weitgehend abdeckt, wäre eine spezifische Entwicklung eine Fehlinvestition – und das sagen wir, obwohl wir wissen, wie man so etwas umsetzt. Der Arbeitsaufwand verlagert sich dann dorthin, wo er tatsächlich anfällt: auf das Lastenheft, die vergleichende Analyse der Angebote, die Datenübernahme und die Schnittstellen zum Rest Ihres Systems. In der Regel scheitern solche Projekte genau an diesen Punkten, nicht an der Produktauswahl.
Sanierung
Sie schrittweise sanieren.
Entweder handelt es sich um eine berufsspezifische Anforderung, oder die Anwendung ist nicht mehr in der Lage, die gewünschten Aufgaben zu erfüllen: Dann muss man selbst programmieren. Meistens fügen wir keine zusätzliche Plattform hinzu – wir entwickeln die Fachschnittstelle auf Power Apps und Dataverse, der nativen Basis der Power Platform, mit einer einzigen Sicherheitslösung und bereits erworbenen Lizenzen. Wenn eine vollständig maßgeschneiderte Lösung erforderlich ist, programmieren wir sie selbst: Anwendungen, Portale, Webdienste, Verarbeitungsprozesse. Niemals in einer einzigen Lieferung: in kurzen Chargen, die jeweils in Betrieb genommen werden.
Abhebung
Vielleicht geht es darum, es auszuschalten.
Eine Anwendung, deren Wartung hohe Kosten verursacht und deren Einstellung niemanden stören würde, muss nicht modernisiert werden: Sie muss ordnungsgemäß stillgelegt werden. Das ist zwar mit Arbeit verbunden – Restnutzungen identifizieren, Daten während der gesetzlichen Aufbewahrungsfrist in lesbarer und abfragbarer Form aufbewahren, die wenigen Nutzer informieren, den Rest abschalten –, aber es handelt sich um eine Aufgabe von wenigen Wochen, nicht um ein Projekt. Wir ziehen es vor, Ihnen das hier zu sagen, anstatt Ihnen etwas anderes zu verkaufen.
Der Punkt, auf den man achten sollte
Das E-Mail-System wird Ihnen früher als alles andere den Geist aufgeben.
Dies ist derzeit die gefährlichste Abhängigkeit, da sie bereits veraltet ist. Die Basisauthentifizierung für den SMTP-Versand wurde bereits am 30. April 2026 eingestellt, und die EWS-Schnittstelle von „Exchange “ wird standardmäßig am1. Oktober 2026 geschlossen und im April 2027 endgültig abgeschaltet. Eine Anwendung, die Nachrichten versendet oder Postfächer abruft, muss auf eine moderne Authentifizierung umgestellt werden und beim Abrufen auf Microsoft Graph zurückgreifen. Das ist keine Frage der Bequemlichkeit: Es ist ein Countdown.
Die unsichtbaren Schnittstellen werden den Zeitplan bestimmen.
Was mit der Anwendung verbunden ist, wird fast nie dokumentiert: die Tabellenkalkulation eines Benutzers, die die Datenbank über ODBC ausliest, der Kopierer, der eine Datei in einem freigegebenen Ordner ablegt, das geplante Skript auf einem Rechner unter einem Schreibtisch, der nächtliche Export in die Buchhaltung. Das findet sich nicht in der Dokumentation: Das findet sich in den Protokollen und in den Netzwerkdaten. Wir suchen nach diesen Abhängigkeiten, bevor wir die Kosten berechnen, denn schon eine einzige übersehene Abhängigkeit verschiebt den Umstieg um einen Monat.
Das ist der einfachste Fall – und der, der am häufigsten übersehen wird.
Eine Anwendung ohne Benutzeroberfläche lässt sich am einfachsten verlegen: Es müssen keine Verträge mit einem anderen System neu ausgehandelt und keine Fenster aufeinander abgestimmt werden. Sie ist auch diejenige, die bei einer Bestandsaufnahme oft übersehen wird, gerade weil sie mit niemandem kommuniziert – bis zu dem Tag, an dem der Server, auf dem sie gehostet wird, außer Betrieb genommen wird und eine Abteilung feststellt, dass sie ihre Dokumente nicht mehr bearbeiten kann. Deshalb prüfen wir zunächst, wer sie tatsächlich nutzt und wie oft.
Die Datenübernahme wird die Hälfte der Arbeit ausmachen.
Zwanzig Jahre uneingeschränkte Dateneingabe führen zu Duplikaten, Feldern, die nicht mehr ihrem ursprünglichen Zweck dienen, Codes, deren Bedeutung niemand mehr kennt, und Datumsangaben in freiem Format. Wir ermitteln den tatsächlichen Durchsatz der Datenübernahme, bevor wir einen Zeitplan bekannt geben, und wenn die Messung dem Zeitplan widerspricht, wird der Zeitplan angepasst. Die Originalkopie wird aufbewahrt, jeder Durchlauf ist nachverfolgbar, und der Abgleich erfolgt gemeinsam mit Ihren Anwendern – nicht anhand eines technischen Berichts.
Ein vergleichbarer veröffentlichter Auftrag
Skripte und Tabellenkalkulationen werden durch eine Plattform ersetzt Die Bereitstellung erfolgte manuell über PowerShell, die Nummerierungspläne wurden in Excel verwaltet, und kein auf dem Markt verfügbares Tool deckte den Bedarf ab. Wir haben es selbst konzipiert und entwickelt: über 280 Standorte, ein einziges Portal, und die Bereitstellungszeit verkürzte sich von mehreren Stunden auf wenige Minuten. Das Mandat lesen Geschäftsanwendungen, die auf Azure, einschließlich der Hersteller Lokale Server am Rande ihrer Kapazität, aus der Ferne nicht zugängliche Fachanwendungen, Patientendaten, die den schweizerischen Vorschriften unterliegen. Die Kompatibilität wurde vor jeder Entscheidung mit jedem Anbieter überprüft, und die Umstellung erfolgte ohne Unterbrechung des Betriebs. Das Mandat lesen Ein neu verlegter Sockel, ohne den Betrieb jemals zu unterbrechen Wenn der Betrieb nicht einmal für eine Stunde unterbrochen werden darf, richtet sich die Vorgehensweise nach dieser Vorgabe und nicht umgekehrt: hohe Verfügbarkeit, wiederholte Testumstellungen und keinerlei Unterbrechungen für die Nutzer. Das Mandat lesen Zwei Systeme, die nichts voneinander wussten, wurden ordnungsgemäß miteinander verbunden Der häufigste Wunsch, mit dem man sich an uns wendet: das Bestehende zum Sprechen zu bringen, ohne eine der beiden Seiten zu ersetzen und ohne gegenseitige Abhängigkeit zwischen den Dienstleistern. Das Mandat lesenDiese Schlussfolgerung ist eine erste Einschätzung, keine verbindliche Zusage: Wir kennen weder Ihren Code noch Ihre Daten noch Ihre Rahmenbedingungen. Was wir Ihnen anschließend zukommen lassen, ist ein Vorschlag für die Maßnahmen – Umfang, Aufwand, Zeitplan, zu erbringende Leistungen. Die Erstellung des Angebots ist kostenlos; das Audit ist der erste Schritt des Auftrags.
Die sieben Wege
Das Umschreiben ist die letzte Option, nicht die erste.
Hier sind die sieben möglichen Szenarien mit einer Angabe zur ungefähren Dauer. Die Spalte, über die sonst niemand schreibt, ist die dritte: das, was der Verlauf nicht klärt. Diese sollte man als Erstes lesen, denn genau sie sorgt sechs Monate später für böse Überraschungen.
| Die Flugbahn | Was damit gelöst wird | Was das nicht löst | Wenn es die richtige Wahl ist |
|---|---|---|---|
| Aufbewahren und rundherum sichernEin paar Wochen | Das Risiko, ohne die Software zu verändern: tatsächlich wiederhergestellte Sicherungskopien, benutzerspezifische Zugriffsrechte, Protokollierung, schriftliche Dokumentation dort, wo bisher keine vorhanden war. | Was das nicht löst:Im Grunde gar nichts. Die Anwendung bleibt, wie sie ist, und der Stichtag steht weiterhin im Kalender. Es handelt sich um einen bewussten Aufschub, nicht um eine Entscheidung. | Sie macht ihre Arbeit, sie behindert nichts, zwei Personen können sie im Zaum halten, und der Termin liegt noch in weiter Ferne. |
| EntfernenEin paar Wochen | Die Kosten, ganz klar. Die Daten werden während der gesetzlichen Aufbewahrungsfrist in lesbarer und abfragbarer Form aufbewahrt, der Rest wird gelöscht. | Was das nicht löst: Dieverbleibenden Nutzer: Es gibt fast immer drei Personen, die das Gerät noch nutzen, und die geben das erst nach dem Ausschalten zu. Man muss sie vorher finden. | Der Dienst wurde eingestellt, in ein anderes Tool integriert oder dient nun ausschließlich der Archivabfrage. |
| UmziehenEin paar Wochen | Die Laufzeit des Servers. Die Anwendung läuft unverändert auf einer unterstützten Plattform weiter — Azure oder einer erneuerten lokalen Infrastruktur — mit Datensicherung und Überwachung. | Was dadurch nicht gelöst wird: Absolutnichts an der Anwendung – derselbe Code, dieselbe technische Schuld, dieselbe Abhängigkeit von einer Person. Und die Hosting-Kosten können steigen, wenn die Dimensionierung unverändert übernommen wird. | Ein Termin rückt näher, und der Betrieb darf nicht unterbrochen werden. Wir verschaffen uns Zeit, um eine fundierte Entscheidung zu treffen. |
| ReplateformerEin paar Monate | Die Grundlage: Umstellung des Frameworks, Aktualisierung der Datenbank auf eine unterstützte Version oder Azure SQL, Ersetzen von veralteten Zugriffsfunktionen, neu aufgebaute Lieferkette. | Was damit nicht gelöst wird: Die Ergonomieund die fehlenden Funktionen. Die Nutzer werden denselben Bildschirm sehen – und das muss man ihnen vorher sagen, sonst wird das Projekt als Misserfolg empfunden, obwohl es doch erfolgreich war. | Die Geschäftslogik ist korrekt, die Ausführungsumgebung jedoch nicht mehr. Das ist der häufigste Verlauf. |
| KapselnEin paar Monate | Die Blockade. Die Anwendung wird über einen dokumentierten Webdienst bereitgestellt; neue Anwendungsfälle laufen über die Schnittstelle, während der alte Kern weiterläuft und anschließend Stück für Stück ersetzt werden kann. | Was dadurch nicht gelöst wird: DasHerzstück, das weiterhin vorhanden ist. Wenn die Entscheidung, es zu ersetzen, nie getroffen wird, wird die Schnittstelle zu einer weiteren Ebene, die gewartet werden muss – und das Problem hat sich verdoppelt, anstatt zu verschwinden. | Der Code ist nicht lesbar, oder die Anwendung ist zu groß, um als Ganzes bearbeitet zu werden. Die Modernisierung erfolgt dann schrittweise. |
| Durch ein Produkt ersetzenEin paar Monate | Die Wartung der spezifischen Funktionen, die wieder an einen Softwarehersteller zurückgeht. Und oft handelt es sich dabei um Funktionen, deren Entwicklung niemand finanziert hätte. | Was damit nicht gelöst wird: Ihre individuellenAnforderungen. Es geht nie um das Produkt, sondern um die Lücken: Datenübernahme, Schnittstellen und die fünf Prozent der Geschäftsabläufe, die nicht in das Tool passen und die irgendwo anderweitig bearbeitet werden müssen. | Ein Produkt deckt den Bedarf mehr als ausreichend ab. Eine spezielle Entwicklung wäre daher eine Fehlinvestition, und das sagen wir auch ganz offen. |
| SanierenIn aufeinanderfolgenden Bauabschnitten | Alles: die Funktionen, die Ergonomie, der Sockel, die Rückverfolgbarkeit und die Möglichkeit, das System weiterzuentwickeln, ohne dass es dabei zu Ausfällen kommt. Das ist auch eine Gelegenheit, alles zu entfernen, was nicht mehr gebraucht wird. | Was das nicht löst: DieZeit, die dabei verstreicht. Der Beruf erfordert weiterhin Weiterentwicklungen – das ist die erste der vier unten aufgeführten Fallstricke, und genau das ist der Grund, warum die meisten Überarbeitungen scheitern. | Entweder handelt es sich um eine berufsspezifische Anforderung, oder die Anwendung kann die geforderten Aufgaben nicht mehr erfüllen. Niemals in einer einzigen Lieferung: in kleinen Chargen, die jeweils in Betrieb genommen werden. |
Diese Zeitangaben sind Größenordnungen, keine verbindlichen Angaben: Eine Anwendung mit drei Bildschirmen und eine mit dreihundert haben nichts miteinander gemeinsam. Sie dienen dazu, zu verdeutlichen, dass zwischen der ersten und der letzten Zeile ein Unterschied von zehn zu eins besteht – und dass es sich daher lohnt, vor dem Start eine Auswahl zu treffen.
Was Ihnen niemand sagt
Vier Fallstricke, und keiner davon ist technischer Natur.
Sie sind in keinem Lastenheft aufgeführt, machen leicht die Hälfte des tatsächlichen Aufwands aus und sind der Grund dafür, dass wir uns weigern, die Kosten für eine Modernisierung zu beziffern, bevor wir uns den Ist-Zustand angesehen haben.
01
Das Funktionsgel
Während einer Neuprogrammierung geht der Geschäftsbetrieb weiter: neue Tarife, neue gesetzliche Vorschriften, neue Kunden, die ein bestimmtes Format verlangen. Wenn man die alte Anwendung einfriert, hinkt die neue den Anforderungen hinterher. Wenn man sie nicht einfriert, muss man dieselbe Weiterentwicklung während der gesamten Projektdauer zweimal programmieren – in beiden Systemen.
Unsere Lösung ist struktureller Natur und nicht moralisierend: kleine Losgrößen, die jeweils in die Produktion gehen, und eine Fristsetzung, die sich am Vertrag orientiert und nicht am guten Willen. Ein Projekt, das in drei Losgrößen von jeweils zehn Wochen unterteilt ist, erfordert niemals eine zweijährige Fristsetzung.
02
Die Datenübernahme
Das ist die Hälfte des Arbeitsaufwands, und es ist immer genau diese Hälfte, die man bei der Kalkulation vergisst. Zwanzig Jahre uneingeschränkte Dateneingabe führen zu Duplikaten, Feldern, die nicht mehr ihrem ursprünglichen Zweck dienen, Codes, deren Bedeutung niemand mehr kennt, Datumsangaben im freien Format und Beträgen in zwei Währungen, ohne dass dies irgendwo vermerkt ist.
Wir messen den tatsächlichen Durchsatz, bevor wir einen Zeitplan bekannt geben: Er bestimmt – und nicht die Anzahl der Bildschirme – die Dauer eines Wechsels. Wir bewahren die Originalkopie auf, jeder Durchlauf ist wiederholbar, und die Abstimmung erfolgt mit Ihren Nutzern. Sollte die Messung dem Zeitplan widersprechen, wird der Zeitplan angepasst.
03
Die unsichtbaren Integrationen
Die Tabellenkalkulation eines Benutzers, die die Datenbank über ODBC ausliest. Der Kopierdienst, der eine Datei in einem Netzwerkordner ablegt. Das geplante Skript auf einem Rechner unter einem Schreibtisch, dessen Autor 2019 das Unternehmen verlassen hat. Der nächtliche Export in die Buchhaltung und das Postfach, das die Anwendung alle fünf Minuten abruft.
Nichts davon ist dokumentiert. Das steht nicht in einem Lastenheft, sondern findet sich in den Protokollen, den geplanten Aufgaben und den Netzwerkabläufen. Eine einzige vergessene Abhängigkeit verschiebt einen Meilenstein um einen Monat – und fast immer ist es genau diese, die an einem Freitag um 17 Uhr zu einem Anruf führt.
04
Die Abhängigkeit von einer Person
Das eigentliche Risiko liegt fast nie in der Technologie selbst: Es besteht vielmehr darin, dass das Wissen in einem einzigen Kopf steckt – sei es innerhalb oder außerhalb des Unternehmens. Eine Anwendung, deren Funktionsweise nur ein einziger Mensch versteht, ist kein Unternehmensvermögen; sie ist vielmehr eine stillschweigende Vereinbarung mit dieser Person.
Bei uns ist die Dokumentation nicht das letzte Ergebnis eines Projekts, sondern das erste. Und der Auftrag endet nicht mit der Inbetriebnahme, sondern erst mit der Übergabe der Nachweise: festgelegte Architekturentscheidungen, abgearbeitetes Abnahmeprotokoll, Übergabe des Betriebs an Ihre Teams oder Ihren üblichen Dienstleister.
Unser Ansatz
Fünf Schritte, fünf Ergebnisse, die Ihnen gehören.
In dieser Reihenfolge, ohne einen Schritt auszulassen. Jeder Schritt liefert ein Dokument, eine Konfiguration oder eine Messung – etwas, das bei Ihnen verbleibt, selbst wenn Sie uns am Ende des Schritts stoppen. Nichts wird auf der Grundlage einer Schätzung entschieden.
01
Bestandsaufnahme und Überprüfung des Ist-Zustands
Wir betrachten, was tatsächlich vorhanden ist, und nicht das, was in den Unterlagen steht: die tatsächlich installierten Versionen, die nicht mehr unterstützten Komponenten mit ihren jeweiligen Daten, das Datenschema in seiner aktuellen Form, die Volumes und die Abhängigkeiten, die niemand dokumentiert.
Dies ist der Schritt, den die meisten Projekte überspringen, und doch ist er derjenige, der alles Weitere bestimmt. Vorher steht nichts fest. Hier schreiben wir auch darüber, wenn es kein Projekt gibt, an dem wir arbeiten können.
Was wir liefern
- Anwendungsinventar: Versionen, Plattformen, Lizenzen, Volumina, Anzahl der tatsächlichen Nutzer
- Die Abhängigkeitsübersicht – Schnittstellen, geplante Aufgaben, Freigaben, direkte Zugriffe auf die Datenbank
- Das rekonstruierte Datenschema und die im Code wiedergefundenen Geschäftsregeln
- Die Fälligkeitstermine der einzelnen Komponenten und die Kosten, die bei Eintreten des jeweiligen Risikos entstehen würden
02
Die Entscheidung, Anwendung für Anwendung
Pro Anwendung ein Ablauf, der aus den sieben ausgewählt wird – und nicht für alle derselbe. Ein Bestand von zwölf Anwendungen wird in der Regel mit vier verschiedenen Abläufen bearbeitet, von denen mindestens einer darin besteht, nichts zu tun.
Alles wird festgehalten, bevor der erste Server angerührt wird – einschließlich der Optionen, die wir verworfen haben, und der Gründe dafür. Eine Architekturentscheidung, deren Gründe unbekannt sind, wiederholt sich bei jedem Personalwechsel.
Was wir liefern
- Der für jede Anwendung gewählte Ansatz sowie die verworfenen Optionen mit einer Begründung
- Die Aufteilung in Chargen, die jeweils in die Produktion übernommen werden, einschließlich der Abhängigkeiten untereinander
- Die Schätzung nach Chargen und die durch die Support-Fristen vorgegebene Reihenfolge
- Der Rückzugsplan, der vor dem ersten Umschwung und nicht währenddessen verfasst wurde
03
Zunächst die Basis, dann die erste Funktion in der Produktion
Bevor man die zweite Zeile schreibt: die Umgebungen, die Lieferkette, die Testsuiten, die Sicherheit, die Überwachung. Nichts wird manuell in die Produktion übernommen.
Dann eine voll funktionsfähige, durchgängige und tatsächlich genutzte Funktion – kein Prototyp. Das ist der einzige stichhaltige Beweis dafür, dass die Architektur funktioniert, und dieser Beweis liegt bereits zu Beginn des Projekts vor und nicht erst am Ende.
Was wir liefern
- Die Umgebungen – Entwicklung, Abnahme, Produktion – und die automatisierte Lieferkette
- Die rollenbasierte Abgrenzung, die auf Ihrem Verzeichnis basiert Entra ID, sowie die Protokollierung der Zugriffe
- Testskripte und automatisierte Tests, die das Bestehende schützen
- Eine erste Funktion in der Produktion, die von echten Menschen genutzt wird
04
Die Umstellung, schrittweise
Jede Charge folgt dem gleichen Ablauf: wiederholbare Datenübernahme, doppelte Funktionsprüfung, sofern möglich, gemeinsam mit Ihren Anwendern durchgeführtes Abnahmeprotokoll, zahlenmäßiger Abgleich zwischen Alt- und Neusystem.
Das alte System bleibt so lange in Betrieb, bis Sie es bestätigen. Es wird erst dann abgeschaltet, wenn Sie es wünschen – und nicht, wenn es unser Zeitplan vorsieht.
Was wir liefern
- Wiederherstellbare Datenübernahme unter Beibehaltung der Originalkopie
- Der Abstimmungsbericht: Was berücksichtigt wurde, was ausgeschlossen wurde und warum
- Das Rezeptheft, das gemeinsam mit Ihren Nutzern gestaltet wurde und signiert ist
- Die Betreuung der Nutzer in den ersten Tagen durch diejenigen, die das System entwickelt haben
05
Danach – und genau hier entscheidet sich der Wert
Eine Modernisierung hat keinen Sinn, wenn die Anwendung nach drei Jahren wieder unlesbar wird. Der letzte Schritt dient dazu, dies zu verhindern: eine stets aktuelle Betriebsdokumentation, die Übergabe an Ihre Teams oder Ihren üblichen Dienstleister sowie die Speicherung des Quellcodes bei Ihnen.
Anschließend übernehmen wir auf Wunsch die Weiterbetreuung – Fehlerbehebungen, Weiterentwicklungen, Versions-Updates – , auch in Umgebungen, die nicht von uns eingerichtet wurden. Wir wollen jedoch nicht dauerhaft bleiben: Unser Ziel ist es, dass Ihre Teams das Tool nach unserem Ausscheiden selbstständig verwalten können.
Was wir liefern
- Die Betriebsunterlagen und die technischen Unterlagen, die ausgehändigt und aufbewahrt werden
- Der Quellcode und das Datenmodell: Sie gehören Ihnen – ohne Abhängigkeitsklausel
- Die Weitergabe an Ihre Teams oder an Ihren üblichen Dienstleister, falls vorhanden
- Erhaltung der Betriebsbereitschaft mit einer verbindlichen Frist – sofern Sie uns damit beauftragen
Drei Auftragsformen bilden die Grundlage für diesen Ansatz: der Projektpauschalauftrag, wenn der Umfang im Voraus festgelegt werden kann; die personelle Verstärkung auf Regie-Basis, wenn Sie die Leitung übernehmen und Ihnen Personal fehlt – wir verfügen seit 2018 über die Bundesgenehmigung für die Personalvermittlung; und der Dienstleistungsvertrag, wenn es darum geht, Aufgaben zu übernehmen und langfristig zu bewältigen. Die Form wird bei der Projektdefinition festgelegt, nicht im Voraus.
Warum sollten Sie sich an uns wenden?
Beide Berufe unter einem Dach.
Genau dieser Unterschied ist bei diesem Thema entscheidend. Ein Systemintegrator, der keine eigene Entwicklung betreibt, hat nur eine Lösung anzubieten: den Austausch durch ein Produkt. Ein Entwickler, der sich mit der Infrastruktur nicht auskennt, unterschätzt die Grundlagen, die Identitäten und den Betrieb. Eine Modernisierung erfordert beide Fachkompetenzen unter einem Dach.
Wenn es auf dem Markt kein Tool gibt, das den Anforderungen entspricht, entwickeln wir es selbst – und wenn es eines gibt, sagen wir es auch. Auch aus diesem Grund bestehen zwei der sieben Wege auf dieser Seite darin, kein Projekt durchzuführen.
1995
Das Jahr, in dem wir angefangen haben. Einige der Anwendungen, die wir übernehmen, sind jünger als das Unternehmen selbst.
784
Abgeschlossene Implementierungsprojekte – vom Arbeitsplatz bis zur maßgeschneiderten Plattform
+280
Websites, die an eine Plattform angebunden sind, die wir für einen einzelnen Kunden konzipiert und entwickelt haben
Im Lieferumfang enthalten
- Beide Aufgabenbereiche unter einem Dach: Infrastruktur, Identitäten und Betrieb auf der einen Seite; Konzeption und Entwicklung auf der anderen. Bei einer Modernisierung stehen beide Bereichetäglich im Austausch.
- Das zu übernehmen, was niemand mehr beherrscht, gehört zu unseren gängigen Aufgaben – oft ist es sogar der Grund, warum wir vor Beginn eines Projekts zu einem Kunden kommen.
- Der Quellcode und die Daten gehören Ihnen, ebenso wie das Datenmodell und die Dokumentation. Es gibt keine Klausel, die Sie dazu verpflichtet, wiederzukommen.
- Teams vor Ort: Renens, Sion, Châtel-Saint-Denis. Am Abend einer Umstellung eröffnet niemand am anderen Ende der Welt ein Ticket.
- Seit 2018 verfügen wir über eine Bundesgenehmigung für die Personalvermittlung: Wir können Ihnen für die Dauer des Projekts auch einen Entwickler oder Architekten in Ihr Team entsenden.
- Seit sechzehn Jahren in Folge Microsoft-Partner: Azure, Power Platform, Dynamics 365, Microsoft 365. Bei der Modernisierung landet man fast immer bei einer dieser vier Optionen.
Häufig gestellte Fragen
Was von uns verlangt wird, bevor wir anfangen.
Die Fragen, die bei jedem ersten Date immer wieder auftauchen – mit konkreten Antworten. Eine vage Antwort nützt in dieser Phase niemandem etwas – und macht es unmöglich, uns mit anderen zu vergleichen.
Muss man alles neu schreiben?
So gut wie nie. Von den sieben möglichen Vorgehensweisen beinhalten sechs kein Neuprogrammieren: Beibehalten und Absichern der bestehenden Struktur, Entfernen, Auslagern, Umstellung auf eine andere Plattform, Kapseln oder Ersetzen durch ein handelsübliches Produkt. Eine vollständige Neuprogrammierung ist der zeitaufwendigste und risikoreichste Weg; sie ist dann gerechtfertigt, wenn die Anforderungen spezifisch für Ihr Geschäftsfeld sind und die Anwendung die geforderten Aufgaben nicht mehr erfüllen kann.
In einem Anwendungsportfolio werden üblicherweise vier verschiedene Entwicklungswege miteinander kombiniert, von denen mindestens einer darin besteht, nichts zu unternehmen.
Wie lange dauert das?
Die Prüfung eines Anwendungsbereichs dauert Wochen, nicht Monate. Danach hängt alles vom weiteren Vorgehen ab: Die Migration dauert Wochen, die Umstellung auf eine neue Plattform oder die Kapselung Monate, die Neuentwicklung erfolgt in Abschnitten von jeweils einigen Wochen, wobei jeder Abschnitt in Produktion genommen wird.
Wir geben keinen Zeitplan bekannt, bevor wir zwei Dinge ermittelt haben: die tatsächliche Geschwindigkeit der Datenübernahme und die Anzahl der zu bearbeitenden Abhängigkeiten. Das bestimmt die Dauer – viel mehr als die Anzahl der Bildschirmseiten.
Ist das Audit kostenlos?
Nein, und wir möchten diesbezüglich ganz klar sein. Die Erstellung des Angebots ist kostenlos: Umfang, Arbeitsaufwand, Zeitplan und schriftliche Leistungen – ganz unverbindlich für Sie. Das Audit hingegen ist der erste Schritt des Auftrags – hier beginnt die eigentliche Arbeit, und es handelt sich um ein Ergebnis, das Ihnen verbleibt.
Ein Dienstleister, der das Audit anbietet, stellt es anderweitig in Rechnung oder plant, die Kosten über ein Projekt abzurechnen, das er bereits abgeschlossen hat, bevor er den Umfang des Audits überhaupt erfasst hat. Wir ziehen es vor, Ihnen einen kurzen, nützlichen Schritt anzubieten, nach dessen Abschluss Sie uns beauftragen können, die Zusammenarbeit zu beenden.
Was ist, wenn der ursprüngliche Dienstleister verschwunden ist, ohne Code oder Dokumentation?
Das kommt häufig vor und verändert den Ablauf, anstatt ihn zu blockieren. Was man nicht lesen kann, schreibt man nicht um: Man beobachtet es. Die Geschäftsregeln finden sich in den Daten, in den Protokollen, in den Ausdrucken und in dem, was Ihre Benutzer wissen.
Die übliche Lösung ist danndie Kapselung: Die Anwendung wird über eine dokumentierte Schnittstelle bereitgestellt, das Neue wird darum herum aufgebaut, und der alte Kern wird anschließend Stück für Stück ersetzt. In manchen Fällen reicht bereits die Datenbank allein aus, um das Wesentliche wiederherzustellen.
Übernehmen Sie eine Anwendung, die Sie nicht selbst geschrieben haben?
Ja, und oft ist das sogar der Grund, warum wir vor Beginn eines Projekts zu einem Kunden kommen. Wir bieten Level-2- und Level-3-Support für Umgebungen und Anwendungen , die nicht von uns erstellt wurden, und verpflichten uns dabei zu bestimmten Reaktionszeiten.
Es beginnt immer mit einer Wiederaufnahmephase: Verstehen, Dokumentieren, Zugriffe und Datensicherungen absichern. Diese Phase ist mit Kosten verbunden und hat ein Ende.
Soll man in den cloud ?
Nein, nicht unbedingt, und das Gegenteil zu behaupten, ist niemandem dienlich. Der Verbleib bei einer lokalen Infrastruktur ist nach wie vor die richtige Wahl, wenn der Standort der Daten dies erfordert, wenn das Netzwerk isoliert ist, wenn industrielle oder medizinische Geräte nicht verlegt werden können oder wenn die Kosten für ein Hosting, das an die bestehende Infrastruktur angepasst ist, die Kosten für die Hardware übersteigen würden.
Was nicht mehr tragbar ist, ist, auf einer nicht mehr unterstützten Plattform zu verharren und zu hoffen, dass sich das von selbst regelt. Dazwischen gibt es gemischte Ansätze: die lokale Anwendung, die Speicherung von Daten in Azure, Identität und Zugriff in Microsoft 365.
An welchen Technologien arbeiten Sie?
Im Bereich Anwendungen und Fachschnittstellen: Power Apps model-driven, Dataverse, Power Automate und Dynamics 365 – die native Basis, ohne zusätzliche Konnektoren oder parallele Sicherheitsmaßnahmen, wobei die Lizenzen oft bereits erworben wurden. Im Bereich Dienste und Verarbeitungsprozesse: Azure Functions, Logic Apps, Service Bus, API Management, Azure SQL, Data Lake sowie die Datengateways zur lokalen Umgebung.
Und bei Bedarf eine umfassende maßgeschneiderte Lösung: Anwendungen, Portale, Erweiterungen, Webdienste, Berechnungsmodule. Die Form richtet sich nach dem Bedarf, niemals umgekehrt.
Wir haben kein internes IT-Team. Ist das ein Hindernis?
Nein, aber das verändert den Umfang des Auftrags. Er umfasst dann das, was niemand an Ihrer Stelle übernehmen wird: die Dokumentation, die Übergabe an Ihren üblichen Dienstleister, falls es einen gibt, und den Support nach der Inbetriebnahme.
Eine ehrliche Anmerkung: Wenn Ihr Unternehmen weniger als hundert Mitarbeiter hat und über keine IT-Ressourcen verfügt, ist ein Partner vor Ort – der innerhalb einer Stunde erreichbar ist, wenn ein Rechner nicht hochfährt – im Alltag die bessere Wahl. Wir konzentrieren uns weiterhin auf das Projekt selbst; diese Nähe können wir nicht ersetzen.
Wir wollen künstliche Intelligenz für unsere Daten. Müssen wir zuerst modernisieren?
Ja, und zwar in dieser Reihenfolge. Eine Anwendung, deren Daten in einem proprietären Format eingeschlossen sind – ohne Zugriffsschnittstelle, ohne dokumentiertes Schema und ohne detaillierte Berechtigungsverwaltung –, eignet sich für nichts: weder für einen Assistenten noch für ein Dashboard noch für einen einfachen, zuverlässigen Export.
Die ordnungsgemäße Darstellung der Daten ist die Grundvoraussetzung und ein Projekt für sich – oft der beste erste Schritt, da er auch für alles Weitere von Nutzen ist. Die Frage, die man sich zunächst stellen sollte, lautet nicht „Welches Modell?“, sondern „Wer darf was sehen, und wie lässt sich das nachweisen?“.
Wie stellen Sie sicher, dass wir nicht von Ihnen abhängig werden?
Durch Ergebnisse, nicht durch Versprechungen. Der Quellcode, das Datenmodell und die technische Dokumentation gehören Ihnen – ohne Bindungsklausel. Architekturentscheidungen werden mit ihrer Begründung dokumentiert. Die Lieferkette ist automatisiert und dokumentiert: Ein anderer Dienstleister muss die Arbeit übernehmen können.
Und der Auftrag endet nicht mit der Inbetriebnahme: Er endet erst mit der Übergabe der Nachweise und der Übergabe. Das steht im Angebot, nicht in einem Gespräch.
Rund um das Thema
Was bei einer Modernisierung immer eine Rolle spielt.
Eine App steht nicht für sich allein: Sie betrifft die Basis, die Identitäten, den Nachrichtenversand und die Daten. Hier sind die weiteren Bausteine, die wir setzen, und wo Sie unsere veröffentlichten Mandate nachlesen können.
Fortsetzung
Lassen Sie uns über Ihre Anwendung sprechen.
Ein paar Zeilen reichen schon aus, um loszulegen: Was sie macht, worum es geht, was Ihnen Sorgen bereitet. Wir teilen Ihnen mit, welche ähnlichen Fälle wir bereits bearbeitet haben, welchen Ansatz wir vorschlagen würden und in welcher Form wir tätig werden könnten. Die Erstellung des Angebots ist kostenlos: Umfang, Aufwand, Zeitplan und zu erbringende Leistungen – ganz unverbindlich für Sie. Das Audit ist der erste Schritt des Auftrags – hier beginnt die eigentliche Arbeit.