Sage 100 · Development Takeover

Bestehende Sage-100-Entwicklung übernehmen und weiterentwickeln

Das Wissen ist verloren gegangen. Der Wert Ihrer Lösung muss es nicht.

Wir analysieren AppDesigner, .NET, SQL, Dienste und Schnittstellen, stellen Übernahmefähigkeit her und bestimmen den wirtschaftlich besten nächsten Schritt.

Code ReviewBuild & DeploymentAbhängigkeitenRisikobewertung
Takeover Check besprechen Lösung prüfen lassen
Softwarearchitekten analysieren Quellcode und Abhängigkeiten einer bestehenden Sage-100-Lösung
Verstehen vor Verändern Build reproduzieren Risiken priorisieren Kein Rewrite-Reflex
Unser Grundsatz

Erhalten, was gut ist. Absichern, was kritisch ist. Nur dort modernisieren, wo es einen belastbaren Grund gibt.

Wenn der Entwickler geht, verschwindet die Software nicht

Eine Sage-100-Erweiterung kann viele Jahre produktiv laufen und tief in Belegfluss, Preisfindung, Freigaben, Reporting oder Datenaustausch eingebunden sein. Verlässt der ursprüngliche Entwickler das Unternehmen oder endet die Betreuung, bleibt die Lösung geschäftskritisch – nur das Wissen darüber fehlt.

Wissen fehltDer Entwickler ist nicht mehr verfügbarDie Anwendung läuft, aber Fehler und Änderungen lassen sich nicht mehr zuverlässig bearbeiten.
Zuständigkeit fehltDie Anpassung fällt zwischen PartnerDer ERP-Support betreut den Standard, niemand übernimmt jedoch die individuelle Lösung.
Update steht anKompatibilität ist ungeklärtNiemand kann belastbar sagen, welche Komponenten mit der Zielversion funktionieren.
Quellstand unklarOrdner und Produktivversion passen nicht zusammenCode ist vorhanden, aber Build, Abhängigkeiten und installierte DLL lassen sich nicht zuordnen.
Performance sinktDatenmenge trifft alte ArchitekturAuskunft, Import, Report oder Hintergrundprozess wird mit der Zeit immer langsamer.
Änderung blockiertDie Lösung soll weiterentwickelt werdenNeue Anforderungen sind bekannt, doch Eingriffe ohne Architekturverständnis wären zu riskant.

Das Problem ist nicht automatisch schlechte Software. Es ist der verlorene Zusammenhang zwischen Geschäftsprozess, Quellcode, Daten und Betrieb. Genau diesen Zusammenhang stellen wir wieder her.

Übernahme beginnt nicht mit Programmierung

Bei einer unbekannten Bestandsentwicklung ändern wir nicht versuchsweise Code im Produktivsystem. Zuerst entsteht ein belastbares technisches Bild.

Erst wenn Komponenten, produktive Version und fachliche Aufgabe verstanden sind, lässt sich verantwortbar über Aufwand und Zielstrategie entscheiden.

Der Development Takeover Check

Die strukturierte Bestandsaufnahme trennt technische Fakten von Vermutungen. Sie zeigt nicht nur, was vorhanden ist, sondern auch, ob daraus eine wartbare und testbare Arbeitsgrundlage entstehen kann.

InventarProduktive KomponentenAppDesigner, DLLs, Dienste, Jobs, Datenbankobjekte, Schnittstellen, Konfiguration und zusätzliche Datenbanken.
GeschäftKritische ProzesseWelche Funktionen laufen täglich, erzeugen Umsatz, verarbeiten Belege oder verbinden externe Systeme?
QuellstandCode und BinärdateienIst der Quellcode vollständig und gehört er tatsächlich zur produktiv eingesetzten Version?
BuildReproduzierbarkeitLassen sich Abhängigkeiten wiederherstellen, Lösung kompilieren und Ergebnis eindeutig zuordnen?
ArchitekturDaten und AbhängigkeitenWelche Sage-Versionen, Bibliotheken, SQL-Objekte, APIs, Pfade, Konten und Zertifikate werden benötigt?
BetriebLogging und FehlerwegeWie starten Prozesse, wo entstehen Logs und wie werden Ausfälle oder fehlende Übertragungen erkannt?
Übernahmefähigkeit

Vier Ausgangslagen – vier unterschiedliche Risiken

Gute BasisCode, Build und Dokumentation vorhandenPrüfen, versionieren und kontrolliert weiterentwickeln.
RekonstruierbarCode vorhanden, Build ungeklärtAbhängigkeiten und Build-Umgebung wiederherstellen.
EingeschränktNur Binärdatei oder DLL vorhandenVerhalten analysieren; Änderung kann Neuimplementierung erfordern.
Erhöhtes RisikoWeder Code noch DokumentationProzess und Datenfluss rekonstruieren, Ersatz gezielt planen.

Wir behaupten nicht, eine fremde Binärdatei ohne Quellcode beliebig weiterentwickeln zu können. Wenn technische Grundlagen oder Nutzungsrechte fehlen, benennen wir diese Grenze klar.

Quellcode ist erst wertvoll, wenn der Build reproduzierbar ist

Ein Ordner mit C#-Dateien ist noch keine belastbare Softwarebasis. SDK-Version, Bibliotheken, Konfiguration, Datenbankschema und Deployment müssen zum produktiven Stand passen.

Entwickler vergleicht Quellcode, Versionshistorie, Build und Deployment einer Bestandslösung
Quellstand, Abhängigkeiten und produktive Version müssen wieder zusammenpassen

Nach der Übernahme führen wir Quellcode und technische Artefakte Git-basiert in einer DevOps-Umgebung. Unsere Weiterentwicklungen liefern wir grundsätzlich vollständig im Sourcecode aus. Versionshistorie, Reviews und reproduzierbare Bereitstellung sind für uns kein Zusatz, sondern ein Qualitätsmerkmal.

Eine Lösung kann über viele Ebenen verteilt sein

Wer nur die sichtbare Maske betrachtet, versteht häufig nur einen Teil des Prozesses. Fachlogik kann gleichzeitig in AppDesigner, .NET, SQL und Hintergrunddiensten liegen.

Ein Dienst mit Status „Wird ausgeführt“ beweist noch nicht, dass sein Geschäftsprozess funktioniert. Ebenso kann ein unscheinbarer Trigger oder SQL-Agent-Job beim Serverumzug entscheidend sein. Deshalb inventarisieren wir die Gesamtlösung, nicht nur ihre sichtbaren Dateien.

SchnittstelleDatenfluss und OwnershipFührendes System, Mapping, externe IDs, Authentifizierung und sichere Wiederholung verstehen.
DiagnoseLogging und MonitoringVorgangskennungen, Fehlerkontext, Aufbewahrung und fehlende Übertragungen sichtbar machen.
BetriebKonten und KonfigurationServiceaccounts, Zertifikate, Connection Strings, Freigaben und feste Pfade prüfen.
PerformanceCode und SQL gemeinsam messenDatenmengen, Blocking, Pläne, I/O, Reports und Hintergrundläufe zusammen betrachten.

Technische Schulden priorisieren statt pauschal verurteilen

Alt ist nicht automatisch schlecht. Eine alte, stabile und dokumentierte Komponente kann weniger riskant sein als ein neuer, unbekannter Trigger auf einer zentralen Tabelle. Wir bewerten deshalb Wirkung und Geschäftskritikalität – nicht das Baujahr allein.

AkutFunktionaler FehlerEin Prozess funktioniert heute nicht oder liefert ein falsches Ergebnis.
RisikoFragile BetriebsbasisDie Lösung läuft, ist aber schlecht diagnostizierbar, nicht reproduzierbar oder unsicher konfiguriert.
ZukunftModernisierungsbedarfEine Komponente erschwert Updates, Erweiterungen oder den sicheren Betrieb.
PlanbarKomfortverbesserungEine Optimierung wäre sinnvoll, ist aber weder kritisch noch zeitnah erforderlich.
PriorisierungAuswirkung × Eintrittswahrscheinlichkeit × GeschäftskritikalitätDiese Einordnung verhindert Aktionismus und lenkt Budget zuerst auf die wirklich relevanten Risiken.

Behalten, weiterentwickeln, refaktorieren oder ersetzen?

Die technische Analyse endet mit einer nachvollziehbaren Strategie. Ein Rewrite ist dabei nicht der Standardweg.

01BehaltenDie Lösung erfüllt ihren Zweck, ist nachvollziehbar und benötigt aktuell keine wesentliche Änderung.
02WeiterentwickelnArchitektur und Datenmodell sind tragfähig; neue Anforderungen können kontrolliert darauf aufbauen.
03RefaktorierenFunktional richtig, technisch punktuell verbessern – etwa Logging, SQL, Konfiguration oder Deployment.
04ErsetzenNur wenn die vorhandene Basis technisch oder wirtschaftlich nicht verantwortbar weitergeführt werden kann.

Eine Teilmodernisierung schützt funktionierende Bestandteile und reduziert Projektrisiko. Vor allem bei älteren Office-Line-, Access- oder VBA-Lösungen prüfen wir außerdem, welche Funktionen heute überhaupt noch gebraucht oder bereits durch Sage-Standard ersetzt werden.

Geschäftsprozess zuerst, kritische Funktionen zuerst

Der technische Name einer DLL erklärt selten ihre tatsächliche Bedeutung. Erst der Geschäftsprozess zeigt, welches Risiko ein Ausfall besitzt.

Bei großen Altlandschaften nehmen wir zuerst umsatzkritische Abläufe, tägliche Automatisierungen, externe Schnittstellen sowie beleg- und buchungsrelevante Prozesse auf. Selten genutzte Komfortfunktionen folgen später – oder entfallen bewusst.

So läuft die technische Übernahme ab

SystembildKomponenten und AbhängigkeitenAppDesigner, DLLs, Dienste, SQL, Jobs, Schnittstellen und Fremdsysteme nachvollziehbar zusammenführen.
ArbeitsbasisQuellcode- und BuildbewertungVollständigkeit, Version, Abhängigkeiten, Reproduzierbarkeit und Testfähigkeit einordnen.
RisikobildBetrieb, Updates und PerformanceDiagnosefähigkeit, technische Schulden und erkennbare Blocker priorisieren.
RoadmapDer wirtschaftlich beste nächste SchrittBehalten, weiterentwickeln, refaktorieren, teilmodernisieren oder kontrolliert ersetzen.

Warum Appontes?

Sage & BWLProzesse hinter dem Code verstehenWarenwirtschaft, Rechnungswesen, xRM und Schnittstellen fachlich einordnen.
EntwicklungAppDesigner, .NET und SQL aus einer HandVerteilte Logik über mehrere technische Ebenen hinweg analysieren und weiterentwickeln.
DiagnosePerformance und Betrieb mitdenkenCode, Ausführungspläne, Blocking, I/O, Dienste und Datenmengen gemeinsam untersuchen.
GrundhaltungKein „Rewrite by default“Investiertes Prozesswissen schützen und nur mit belastbarer Begründung ersetzen.

Aus einer unbekannten Anpassung wird wieder ein betreubares Produkt

01TransparenzSie wissen, welche Komponenten produktiv arbeiten und welche Prozesse davon abhängen.
02SupportfähigkeitVersion, Betrieb, Logs, Quellcode und Deployment sind nachvollziehbar.
03PlanbarkeitUpdates und neue Funktionen bauen auf einer bewerteten technischen Basis auf.
Passende Themen
FAQ

Häufig gestellte Fragen

Kann Appontes eine fremde Sage-100-Individualentwicklung übernehmen? +
Grundsätzlich ja, sofern die notwendigen technischen Voraussetzungen und Nutzungsrechte vorhanden sind. Wir beginnen mit einer Bestandsaufnahme und prüfen Komponenten, Quelltexte, Buildfähigkeit, Datenmodell und Abhängigkeiten.
Was passiert, wenn der ursprüngliche Entwickler nicht mehr erreichbar ist? +
Wir rekonstruieren die Lösung aus den verfügbaren Informationen: installierte Komponenten, Quellcode, AppDesigner-Pakete, Datenbankobjekte, Dienste, Logs und Prozesswissen der Anwender.
Was passiert, wenn kein Quellcode vorhanden ist? +
Dann können wir Verhalten, Schnittstellen und technische Umgebung analysieren. Eine Binärdatei lässt sich jedoch nicht automatisch sicher weiterentwickeln. Betroffene Komponenten müssen gegebenenfalls kontrolliert neu implementiert oder ersetzt werden.
Reicht ein vorhandener Quellcodeordner für die Übernahme aus? +
Nicht unbedingt. Entscheidend ist, ob Projekt, Abhängigkeiten und Konfiguration vollständig sind und ob sich daraus die aktuell produktive Version reproduzierbar erstellen lässt.
Übernimmt Appontes AppDesigner-Lösungen? +
Ja. Wir analysieren AppDesigner-Metadaten, Datenquellen, Dialoge, Makros, Geschäftsprozesse und Abhängigkeiten zu .NET-Komponenten oder SQL-Objekten.
Können bestehende .NET-DLLs weiterentwickelt werden? +
Wenn passender Quellcode, erforderliche Abhängigkeiten und Nutzungsrechte vorhanden sind, ist das grundsätzlich möglich. Zuerst prüfen wir Versionsstand, Buildfähigkeit und produktiv eingesetzte Binärdateien.
Prüft Appontes auch SQL-Objekte? +
Ja. Eigene Tabellen, Views, Stored Procedures, Functions, Trigger und SQL-Agent-Jobs können wesentliche Teile der Geschäftslogik enthalten und gehören zur technischen Analyse.
Können bestehende Schnittstellen übernommen werden? +
Ja. Wir analysieren Datenfluss, führende Systeme, Mapping, externe IDs, Authentifizierung, Wiederholbarkeit, Fehlerbehandlung, Logging und Monitoring.
Muss die bestehende Lösung neu entwickelt werden? +
Nein. Eine Neuentwicklung ist nur eine mögliche Strategie. Wenn die vorhandene Basis tragfähig ist, bevorzugen wir Erhalt, gezielte Weiterentwicklung oder Teilmodernisierung.
Kann Appontes eine langsame Bestandsentwicklung optimieren? +
Ja. Wir betrachten Anwendungscode, SQL-Abfragen, Datenmengen, Ausführungspläne und die SQL-Server-Umgebung gemeinsam, um den tatsächlichen Engpass zu finden.
Können ältere Office-Line-, Access- oder VBA-Anpassungen übernommen werden? +
Sie können technisch und fachlich aufgenommen werden. Danach entscheiden wir, ob Weiterbetrieb, Teilmodernisierung, Überführung in AppDesigner oder .NET oder ein kontrollierter Ersatz sinnvoll ist.
Ist eine Übernahme vor einem Sage-Update sinnvoll? +
Ja. Vor einem Versionswechsel wird sichtbar, welche individuellen Komponenten, Datenbankobjekte, Dienste und Schnittstellen getestet oder angepasst werden müssen.
Arbeitet Appontes mit einem Testsystem? +
Bei relevanten Änderungen und komplexen Lösungen ist eine geeignete Testumgebung ein zentraler Bestandteil des kontrollierten Vorgehens. Das Produktivsystem ist kein Entwicklungssystem.
Kann Appontes nur die Entwicklung übernehmen, während unser Sage-Partner bleibt? +
Grundsätzlich ja. Bei klarer technischer und organisatorischer Aufgabenverteilung können wir gezielt als Entwicklungspartner ergänzen.
Unterstützt Appontes unsere internen Entwickler? +
Ja. Wir arbeiten als Sparringspartner für Sage-Architektur, AppDesigner, .NET, SQL, APIs, Debugging, Performance und Updatefragen.
Kann eine unbekannte Lösung zunächst nur bewertet werden? +
Ja. Genau dafür dient der Development Takeover Check. Auf seiner Grundlage entscheiden Sie anschließend, ob und in welchem Umfang eine technische Übernahme erfolgen soll.
Was ist der Unterschied zum Sage 100 Health Check? +
Der Development Takeover Check fokussiert eine konkrete Individualentwicklung oder Entwicklungslandschaft. Der Health Check betrachtet die gesamte Sage-100-Umgebung einschließlich Betrieb, Backup, Infrastruktur und Updatefähigkeit.
Was ist der beste erste Schritt? +
Beschreiben Sie die betroffene Anpassung, ihre geschäftliche Aufgabe und die vorhandenen Unterlagen. Danach legen wir den sinnvollen Umfang der technischen Bestandsaufnahme fest.
Der erste Schritt ist Transparenz

Ist Ihre Bestandsentwicklung verantwortbar übernahmefähig?

Schildern Sie uns die betroffene Lösung und die vorhandenen Unterlagen. Wir klären, welcher Prüfrahmen sinnvoll ist – bevor Änderungen am Produktivsystem beginnen.

Übernahme besprechen Ausgangslage senden