Sage 100 Migration, Versionswechsel und Serverumzug

Warum eine Sage-Migration mehr als ein Update ist

Eine typische Sage-100-Landschaft besteht nicht aus „dem Sage-Server“.

Sie ist vielmehr ein Zusammenspiel mehrerer technischer Ebenen:

Wird nur eine dieser Ebenen betrachtet, können nach einem scheinbar erfolgreichen Umzug Fehler auftreten, die erst Stunden oder Tage später sichtbar werden.

Der Login funktioniert. Der Artikelstamm öffnet sich. Ein Auftrag lässt sich erfassen.

Aber vielleicht wird nachts kein Lagerbestand mehr übertragen. Vielleicht archiviert DocuWare keine Rechnung. Vielleicht zeigt Power BI noch auf die alte Datenbank. Vielleicht fehlt ein SQL-Agent-Job, den seit Jahren niemand mehr bewusst wahrgenommen hat.

Genau deshalb beginnt eine professionelle Sage-100-Migration nicht mit dem Setup. Sie beginnt mit einer Inventur.

Typische Szenarien für eine Sage-100-Migration

Wir unterstützen unter anderem bei folgenden Vorhaben:

Nicht jedes Projekt benötigt jeden dieser Schritte. Aber vor dem Umzug sollte bekannt sein, welche davon tatsächlich relevant sind.

Technischer Stand August 2026: Die recherchierten Systemvoraussetzungen der Sage 100 V9.0.11 vom April 2026 führen Windows Server 2022 und Windows Server 2025 für relevante Sage-Serverrollen sowie Microsoft SQL Server 2019, 2022 und 2025 in den aufgeführten Editionen als unterstützte Datenbankplattformen. Welche Kombination für ein konkretes Projekt zulässig und sinnvoll ist, prüfen wir immer gegen die Systemvoraussetzungen der tatsächlich geplanten Zielversion – nicht gegen eine pauschale Serverliste.

Die Sage-Systemvoraussetzungen selbst haben sich mit den Releases mehrfach verändert. Deshalb gehört die Prüfung des exakten Zielstands ausdrücklich zur Projektvorbereitung.

Erst Inventur, dann Migration

Was ist heute wirklich im Einsatz?

Vor einem Versionswechsel oder Serverumzug erstellen wir zunächst ein technisches Bild der vorhandenen Umgebung.

Das klingt selbstverständlich. In der Praxis ist genau diese Bestandsaufnahme jedoch häufig der wichtigste Teil des Projekts.

Denn über Jahre entstehen in ERP-Systemen Abhängigkeiten, die nicht zwingend in einer zentralen Dokumentation stehen.

Ein Entwickler hat vor sechs Jahren einen SQL-Agent-Job eingerichtet.

Eine Schnittstelle liest jede Nacht eine View aus.

Ein Dienst überwacht ein Importverzeichnis.

Ein Report benötigt eine zusätzliche DLL.

Der Rechnungsversand nutzt einen bestimmten SMTP-Relay.

Ein Power-BI-Dataset verwendet einen hart hinterlegten Servernamen.

Eine Zusatzlösung schreibt Dateien auf eine Freigabe.

Eine AppDesigner-Lösung verteilt Komponenten auf Clients oder Server.

Was nicht bekannt ist, kann bei der Migration auch nicht bewusst geprüft werden.

Unsere Bestandsaufnahme

Sage 100

Wir erfassen unter anderem:

• installierte Sage-100- bzw. Office-Line-Version
• Patch- und LiveUpdate-Stand
• globale Sage-Datenbank und Mandantendatenbanken
• vorhandene Mandanten
• eingesetzte Module
• Warenwirtschaft
• Rechnungswesen
• Sage 100 xRM
• Benutzer
• Rollen und Berechtigungen
• Besonderheiten bei Anmeldung und Authentifizierung
• zentrale Konfigurationen
• relevante Dateipfade und Freigaben

Anpassungen und Entwicklung

Wir prüfen:

• AppDesigner-Lösungen
• kundenspezifische Metadaten
• individuelle Masken und Dialoge
• Individualentwicklungen
• Sage-SDK-Erweiterungen
• Zusatzlösungen anderer Hersteller
• Assemblies und DLLs
• zusätzliche EXE-Dateien
• Konfigurationsdateien
• eigene Tabellen
• Views
• Stored Procedures
• Funktionen
• Trigger
• weitere individuelle Datenbankobjekte

Gerade bei AppDesigner-Lösungen darf die Betrachtung nicht bei den Metadaten enden. Die offizielle technische Sage-Dokumentation beschreibt beispielsweise ausdrücklich die Verteilung zusätzlicher Dateien und ausführbarer Komponenten über AppDesigner-Lösungen sowie unterschiedliche Installationsziele. Solche Abhängigkeiten gehören deshalb in die Migrationsinventur.

Automatisierung

Wir suchen gezielt nach Prozessen, die im normalen Sage-Client nicht sichtbar sind:

• SQL-Agent-Jobs
• Zeitpläne
• Wartungsjobs
• Windows-Dienste
• geplante Windows-Aufgaben
• Import- und Exportprozesse
• Dateiüberwachungen
• Batch- oder PowerShell-Skripte
• externe Programme
• Hintergrundverarbeitung

Schnittstellen

Wir dokumentieren, welche Systeme Daten mit Sage 100 austauschen und in welcher Richtung.

Zum Beispiel:

• Salesforce ↔ Sage 100
• DocuWare ↔ Sage 100
• ITscope ↔ Sage 100
• Praxedo ↔ Sage 100
• Webshops
• EDI
• E-Procurement
• cXML
• EDIFACT
• openTRANS
• individuelle REST- und Web-APIs
• Dateiimporte und -exporte
• Fremddatenbanken
• weitere ERP-, CRM-, DMS- und Logistiksysteme

Mehr zu unserer Arbeit mit Sage-100-Schnittstellen und Systemintegration.

Belegdruck und Reporting

Wir betrachten unter anderem:

• individuelle Beleglayouts
• Rechnungen
• Auftragsbestätigungen
• Lieferscheine
• Bestellungen
• Mahnungen
• individuelle Reports
• Druckerzuordnungen
• PDF-Erzeugung
• Versandwege
• Datenquellen
• Excel-Auswertungen
• individuelle Reportinglösungen
• Power BI auf Basis von Sage-100-Daten

Infrastruktur

Zur Inventur gehören ebenfalls:

• Windows-Server-Versionen
• SQL-Server-Version und Edition
• SQL-Instanzen
• Sage Applikationsserver
• Terminalserver / Remote Desktop Services
• virtuelle Maschinen
• CPU und RAM
• Storage
• Disk-I/O
• Netzwerk
• Latenzen
• DNS
• Firewall
• Freigaben
• Servicekonten
• NTFS-Berechtigungen
• Zertifikate
• Backupkonzept
• Wiederherstellbarkeit der Sicherungen
• Virenscanner / EDR
• Microsoft-365-/E-Mail-Konfiguration

So entsteht vor der eigentlichen Migration eine technische Landkarte des Systems.

Was muss eigentlich alles mit?

Die Antwort lautet fast nie: „nur die Datenbank“.

Eine Sage-100-Installation verteilt ihre Funktionalität auf mehrere Ebenen.

Genau hier unterscheidet sich ein kontrollierter Systemumzug von einem reinen Datenbank-Restore.

Sage läuft – aber …

Nach einem unvollständig geplanten Umzug kann Sage 100 auf den ersten Blick völlig normal aussehen.

Und trotzdem funktionieren entscheidende Prozesse nicht.

Sage läuft – aber der Rechnungsdruck funktioniert nicht.

Sage läuft – aber DocuWare archiviert keine Belege mehr.

Sage läuft – aber ein SQL-Agent-Job fehlt.

Sage läuft – aber die Schnittstelle zum Webshop verarbeitet keine Aufträge.

Sage läuft – aber der Windows-Dienst einer Zusatzlösung wurde nicht eingerichtet.

Sage läuft – aber der SMTP-/Microsoft-365-Versand funktioniert nicht.

Sage läuft – aber Power BI zeigt weiterhin auf die alte Datenbank.

Oder:

Sage läuft – aber ein nächtlicher Import verbindet sich noch mit dem alten SQL Server.

Sage läuft – aber ein Report benötigt eine DLL, die auf dem neuen Terminalserver fehlt.

Sage läuft – aber ein externes System scheitert an einem geänderten Zertifikat oder Firewall-Port.

Die entscheidende Aussage lautet deshalb:

Ein erfolgreicher Login ist noch kein erfolgreicher Systemumzug.

Wir testen nicht nur, ob Sage startet. Wir prüfen, ob die relevanten Geschäftsprozesse Ende-zu-Ende funktionieren.

Sage Office Line → Sage 100

Alte Installation – aber oft hochgradig geschäftskritisch

Bei älteren Installationen ist häufig noch die Bezeichnung Sage Office Line im Unternehmen etabliert.

Office Line und Sage 100 gehören zur selben Produktlinie; die spätere Produktgeneration wurde unter dem Namen Sage 100 weitergeführt. Dadurch handelt es sich fachlich nicht automatisch um eine komplette ERP-Neueinführung. Dennoch kann der technische Abstand zwischen einer alten Office Line und einer aktuellen Sage 100 erheblich sein.

Gerade bei solchen Umgebungen finden wir häufig:

• über viele Jahre gewachsene Individualentwicklungen
• ältere Zusatzlösungen
• historische VBA-/Access-Anpassungen
• eigene Datenbanktabellen
• Trigger und Stored Procedures
• individuell entwickelte Belege
• alte Schnittstellen
• feste Servernamen
• alte UNC-Pfade
• lokale Komponenten auf Arbeitsplatz- oder Terminalservern
• historisch gewachsene Berechtigungen

Deshalb prüfen wir zunächst Ausgangsversion und Zielversion und bestimmen anschließend den technisch sinnvollen Migrationsweg.

Abhängig vom vorhandenen Stand kann eine Migration mehrere technische Schritte erfordern.

Was wir nicht tun:

„Wir installieren erst einmal die aktuelle Version und schauen anschließend, was passiert.“

Stattdessen wird vorab geklärt:

1. Welcher Ausgangsstand liegt tatsächlich vor?
2. Welche Update- bzw. Migrationsschritte sind für diesen Stand erforderlich?
3. Welche Anpassungen sind noch relevant?
4. Welche davon müssen modernisiert werden?
5. Welche Drittanbieterprodukte stehen für die Zielversion zur Verfügung?
6. Welche Prozesse können im Testsystem vollständig verifiziert werden?
7. Wie sieht der Cutover auf das Produktivsystem aus?

Mehr dazu in unserem Fachbeitrag: Von der Sage Office Line zur Sage 100.

Eine produktive Sage-100-Umgebung ist kein Testsystem

Das ist für uns ein zentraler Grundsatz.

Eine produktive Sage-100-Umgebung ist kein Testsystem.

Ein Versionswechsel, bei dem erst im Produktivsystem festgestellt wird, ob eine Zusatzlösung startet, ein Report funktioniert oder eine Schnittstelle kompatibel ist, verlagert das Projektrisiko direkt in den Geschäftsbetrieb.

Unser bevorzugter Ablauf:

Ein gutes Testsystem ist kontrolliert isoliert

Eine Kopie der Produktivdatenbank allein macht noch kein sicheres Testsystem.

Wir prüfen beispielsweise, ob im Testsystem:

• produktive E-Mails deaktiviert oder umgeleitet sind
• Schnittstellen nicht unkontrolliert Echtdaten übertragen
• Webshops keine Testaufträge als reale Aufträge erhalten
• EDI-Nachrichten nicht produktiv versendet werden
• DMS-Systeme nicht unbeabsichtigt Testbelege archivieren
• geplante Jobs kontrolliert deaktiviert oder angepasst wurden
• produktive Dateiablagen geschützt sind
• externe APIs mit Testendpunkten oder kontrollierten Einstellungen betrieben werden

Zusatzlösungen und Individualentwicklungen

„Ist kompatibel“ reicht uns als Aussage nicht immer aus

Bei individualisierten Sage-Systemen legen wir für relevante Erweiterungen idealerweise eine technische Migrationsmatrix an.

Bei AppDesigner und Individualentwicklung betrachten wir unter anderem:

• verwendete Metadaten
• Abhängigkeiten zwischen Lösungen
• externe DLLs
• Deployment zusätzlicher Dateien
• Datenbankobjekte
• API-Aufrufe
• Pfade
• Service-Endpunkte
• Benutzerrechte
• technische Änderungen zwischen Ausgangs- und Zielversion

Die Sage-Dokumentation zeigt selbst, dass AppDesigner weit über eine reine Maskenanpassung hinausgeht und unter anderem Datenquellen, Geschäftsprozesse, Oberflächenelemente und die Einbindung beziehungsweise Verteilung zusätzlicher Komponenten betrifft.

Genau deshalb verbinden wir bei Appontes Sage-Fachwissen mit eigener Softwareentwicklung.

Schnittstellen: Der ERP-Umzug endet nicht an der Sage-Grenze

Viele Sage-100-Systeme bilden heute den Kern einer größeren Anwendungslandschaft.

Ein Serverumzug kann daher Auswirkungen auf Systeme haben, die selbst gar nicht migriert werden.

Beispiel:

Ändert sich der Sage- oder SQL-Server, können beispielsweise betroffen sein:

• Hostnamen
• SQL-Verbindungsstrings
• DNS
• IP-Adressen
• Firewallregeln
• Portfreigaben
• Servicekonten
• Zertifikate
• API-Endpunkte
• Freigaben
• Import-/Exportverzeichnisse
• Zugangsdaten
• geplante Aufgaben

Deshalb testen wir eine Schnittstelle nicht nur mit „Ping erfolgreich“.

Wir prüfen den konkreten Prozess:

Quelle → Übertragung → Sage-Verarbeitung → Ergebnis → Rückmeldung

Beispiele unserer Integrationskompetenz:

• Salesforce und Sage 100
• DocuWare und Sage 100
• ITscope und Sage 100
• Praxedo und Sage 100
• Power BI und Sage 100
• Sage-100-Schnittstellen im Überblick

Belegdruck und Reporting

Ein Auftrag ist erst vollständig getestet, wenn auch sein Ergebnis stimmt

Gerade beim Versions- oder Serverwechsel sollte Belegdruck nicht auf einen Testdruck nach dem Go-Live reduziert werden.

Wir prüfen relevante Belegarten bereits im Testsystem.

Zum Beispiel:

• Angebot
• Auftragsbestätigung
• Lieferschein
• Rechnung
• Gutschrift
• Bestellung
• Mahnung
• individuelle Auswertungen

Dabei geht es nicht nur darum, ob eine PDF-Datei erzeugt wird.

Wir vergleichen unter anderem:

• Layout
• Logo und Briefpapier
• Schriftarten
• Seitenumbrüche
• Barcodes
• individuelle Felder
• Datenquellen
• kundenspezifische Logik
• Drucker
• Versand
• Archivierung
• E-Mail-Anhänge

Dasselbe gilt für Reporting.

Wenn Excel, Power BI oder eine individuelle BI-Lösung auf Sage-Daten zugreift, muss nach der Migration klar sein:

• Wo liegt die neue Datenquelle?
• Wurden Servernamen geändert?
• Sind Berechtigungen vorhanden?
• Funktioniert das Refresh?
• Sind Gateways betroffen?
• Liefern Berichte dieselben fachlichen Ergebnisse?

Mehr zu Power BI und Sage 100.

SQL Server: Die Datenbank ist das Fundament

Eine Sage-100-SQL-Migration ist mehr als Backup und Restore

Ein Datenbankbackup auf einem neuen SQL Server wiederherzustellen ist technisch schnell erledigt.

Damit ist die SQL-Server-Migration jedoch nicht zwingend vollständig.

Wichtige Fragestellungen sind beispielsweise:

Datenbanken

• Sind alle relevanten Datenbanken vorhanden?
• Sind Sicherung und Restore verifiziert?
• Passen Datenbankeinstellungen zum Zielsystem?
• Welcher Compatibility Level wird verwendet?
• Gibt es Besonderheiten bei Collation oder Datenbankoptionen?
• Gibt es individuelle Datenbankobjekte?

SQL-Server-Ebene

Bestimmte Komponenten befinden sich nicht einfach innerhalb der Mandantendatenbank.

Dazu können gehören:

• SQL-Logins
• Berechtigungen
• SQL-Agent-Jobs
• Job-Zeitpläne
• Credentials und Proxies
• Linked Server
• Backupjobs
• Wartungspläne
• serverweite Einstellungen

Wenn Verschlüsselungsmechanismen wie TDE eingesetzt werden, sind darüber hinaus Schlüssel und Zertifikate Bestandteil der Migrationsplanung.

Performance

Ein neuer SQL Server sollte passend konfiguriert werden.

Wir betrachten unter anderem:

• verfügbare CPU-Ressourcen
• RAM
• SQL Server max server memory
• TempDB
• Storage-Latenzen
• Daten- und Log-Dateien
• Wait Statistics
• ressourcenintensive Abfragen
• Ausführungspläne
• Indizes
• Parallelität
• Backup- und Wartungsstrategie

Dabei gilt:

Wir ändern Einstellungen nicht nach pauschalen Internet-Checklisten.

Eine Konfiguration sollte zur tatsächlichen Last, zur Sage-Umgebung und zur verwendeten SQL-Server-Version passen.

Mehr dazu: Sage 100 Performance & SQL Server.

Sage Applikationsserver

Ein häufig unterschätzter Bestandteil der Gesamtperformance

Bei aktuellen Sage-100-Installationen ist auch der Sage Applikationsserver ein zentraler Bestandteil der Architektur.

Ein Serverwechsel ist deshalb eine gute Gelegenheit, seine Konfiguration bewusst zu prüfen statt bestehende Einstellungen ungeprüft auf neue Hardware zu übertragen.

Zu unserer Betrachtung gehören beispielsweise:

• installierte Sage-Version
• ServiceDomains
• Pooling
• parallele Last
• CPU
• Arbeitsspeicher
• Dienstkonten
• Startverhalten
• Netzwerkverbindungen
• Erreichbarkeit des SQL Servers
• STS
• BlobStorage
• Event Logs
• individuelle Anwendungen, die den Applikationsserver verwenden

Die offiziellen Systemvoraussetzungen behandeln den Applikationsserver als eigene Serverrolle mit eigenen Ressourcenanforderungen. Die Dimensionierung muss deshalb zur tatsächlichen Benutzerzahl und Last passen.

Mehr zu unserer spezialisierten Analyse: Sage 100 Applikationsserver optimieren.

Performance vor und nach der Migration messen

Der neue Server ist schneller – oder?

Neue Hardware allein ist kein belastbarer Nachweis für bessere ERP-Performance.

Ein neuer Prozessor kann schneller sein, während der Storage langsamer reagiert.

Ein SQL Server kann mehr RAM besitzen, aber ungünstig konfiguriert sein.

Die virtuelle Maschine kann leistungsfähig aussehen, aber durch Host-Überbuchung oder Storage-Latenzen ausgebremst werden.

Der Applikationsserver kann auf der neuen Infrastruktur anders reagieren als erwartet.

Deshalb arbeiten wir bei geeigneten Projekten mit einer Performance-Baseline.

Vor der Migration

Wir erfassen möglichst reproduzierbar:

• SQL-Performance
• relevante SQL-Wartezeiten
• I/O-Latenzen
• Sage-relevante Laufzeiten
• Netzwerk-Latenzen
• Windows- und Application-Server-Performance-Counter
• typische Benutzerprozesse
• auffällige Hintergrundprozesse

Nach der Migration

Wir führen dieselben Messungen erneut durch.

Gleicher Vorgang. Gleiche fachliche Ausgangslage. Gleiche Messmethodik.

So wird aus:

„Gefühlt ist das neue System schneller.“

eine belastbarere Aussage:

„Dieser konkrete Vorgang benötigt auf dem Zielsystem unter vergleichbaren Bedingungen weniger Zeit.“

Beispiel einer Baseline

Die folgenden Werte sind ausschließlich illustrative Beispielwerte. Sie sind keine Aussage über ein konkretes Kundensystem und ausdrücklich keine Ergebnis- oder Performancegarantie.

Entscheidend ist nicht, genau diese Verbesserungen zu erreichen.

Entscheidend ist, Abweichungen sichtbar zu machen.

Ein neuer Server sollte nicht nur neuer sein. Wir prüfen, ob Ihre Sage 100 darauf tatsächlich mindestens genauso gut oder besser läuft.

Mehr dazu: Sage-100-Performance systematisch messen.

Infrastruktur: Windows Server, RDS, Virtualisierung und Hosting

Eine Sage-100-Migration ist häufig gleichzeitig ein Infrastrukturprojekt.

Beispiele:

Windows Server

Beim Wechsel auf einen neuen Windows Server prüfen wir nicht nur die reine Betriebssystemkompatibilität.

Relevant sind auch:

• Rollen und Features
• .NET-Komponenten
• Dienstkonten
• Berechtigungen
• Freigaben
• Firewall
• Zertifikate
• DNS
• Virenscanner
• Backupagenten
• Druck
• Monitoring

Terminalserver / RDS

Bei einer RDS-Migration kommen zusätzliche Abhängigkeiten hinzu:

• Sage-Clientinstallation
• Benutzerprofile
• Drucker
• Office-Komponenten
• lokale und Netzwerkpfade
• Rechte
• Drittanbieterprogramme
• Zusatzlösungen
• PDF-Druck
• Benutzerkonfiguration

Physisch → virtuell

Die Sage-Systemvoraussetzungen erlauben virtualisierte Systeme unter der Voraussetzung, dass die benötigten Ressourcen entsprechend bereitgestellt werden; Sage weist dabei auch auf die Problematik von Überprovisionierung hin.

Deshalb betrachten wir nicht nur die nominellen Werte „8 vCPU und 32 GB RAM“, sondern auch:

• tatsächliche CPU-Verfügbarkeit
• Storage
• IOPS und Latenzen
• Host-Auslastung
• Memory Pressure
• Netzwerk
• Backupmechanismus

Wechsel des Hostinganbieters

Bei einem Wechsel des Rechenzentrums oder Hostingpartners werden zusätzlich relevant:

• neue IP-Netze
• VPN
• Firewallregeln
• DNS
• öffentliche Endpunkte
• Whitelists
• Zertifikate
• Site-to-Site-Verbindungen
• Latenzen
• lokale Drucker
• externe Schnittstellen

Die ERP-Migration wird damit gleichzeitig zu einem Netzwerk-, Security- und Integrationsprojekt.

Der Go-Live: kontrollierter Cutover statt Überraschung

Nachdem das Testsystem fachlich und technisch geprüft wurde, planen wir den eigentlichen Produktivumzug.

Ein möglicher Cutover sieht beispielsweise so aus:

Typische Schritte am Cutover-Tag

1. Definierter Bearbeitungsstopp im Altsystem
2. Prüfung laufender Importe und Schnittstellen
3. Finale Datenbanksicherung
4. Kontrolle der Sicherung
5. Übertragung beziehungsweise Restore der Datenbanken
6. Notwendiger Sage-Versionswechsel
7. Aktivierung der Zielkonfiguration
8. Start der relevanten Dienste
9. Prüfung des Sage Applikationsservers
10. Kontrolle der Schnittstellen
11. technische Smoke Tests
12. fachliche Kernprozesse testen
13. Belegdruck kontrollieren
14. E-Mail-/Archivierungsprozesse prüfen
15. Freigabe
16. Benutzerstart
17. verstärkte Nachkontrolle

Rollback und Fallback: vorbereitet, nicht dramatisiert

Ein professioneller Migrationsplan beantwortet auch eine einfache Frage:

Was tun wir, wenn am Go-Live ein wirklich kritisches Problem auftritt?

Das bedeutet nicht, dass wir mit einem Scheitern rechnen.

Es bedeutet, dass wir einen definierten Entscheidungsweg haben.

Dazu gehören je nach Projekt:

• finale und überprüfte Sicherung
• dokumentierter Zustand des Altsystems
• definierter Cutover-Zeitpunkt
• klare Freigabekriterien
• definierter Entscheidungszeitpunkt
• Ansprechpartner
• Vorgehen für Rückkehr auf das Altsystem
• Umgang mit Schnittstellen und Nachrichtenwarteschlangen
• Vermeidung paralleler Datenerfassung in Alt- und Neusystem

Gerade der letzte Punkt ist wichtig.

Ein Rollback ist nicht einfach „alte VM wieder einschalten“, wenn inzwischen Aufträge, Buchungen oder Schnittstellendaten in der neuen Umgebung verarbeitet wurden.

Deshalb planen wir Fallback und Cutover zusammen.

Nach dem Go-Live beginnt die Nachkontrolle

Einige Fehler zeigen sich nicht innerhalb der ersten zehn Minuten.

Manche Prozesse laufen nur:

• einmal pro Stunde
• nachts
• zum Tagesabschluss
• am Monatsende
• bei bestimmten Belegarten
• bei bestimmten Kunden
• bei bestimmten Schnittstellenereignissen

Deshalb gehört zur Migration eine geplante Nachkontrolle.

Technische Prüfung

Wir kontrollieren beispielsweise:

• Windows Event Logs
• Sage-Dienste
• Applikationsserver
• STS
• BlobStorage
• SQL Server
• SQL-Agent-Jobs
• Schnittstellenlogs
• geplante Aufgaben
• Backups
• Datenbankwachstum
• Performance
• Fehlermeldungen

Fachliche Prüfung

Gemeinsam mit den Key-Usern können unter anderem kontrolliert werden:

• Auftragsbearbeitung
• Einkauf
• Wareneingang
• Lager
• Fakturierung
• Finanzbuchhaltung
• Zahlungsprozesse
• xRM
• Belegdruck
• E-Mail-Versand
• DMS-Archivierung
• Reporting
• externe Systeme

Dokumentation: Damit der neue Zustand nachvollziehbar bleibt

Eine Migration ist gleichzeitig eine gute Gelegenheit, eine über Jahre gewachsene Sage-Landschaft wieder sauber zu dokumentieren.

Je nach Projekt dokumentieren wir beispielsweise:

Systemlandschaft

• Server
• Rollen
• Sage-Komponenten
• Datenbanken
• Netzwerkbeziehungen
• RDS
• Applikationsserver

Datenbank

• SQL-Instanz
• Datenbanken
• Sicherung
• Wartung
• individuelle SQL-Objekte
• SQL-Agent-Jobs

Anwendungen

• Sage-Version
• Module
• Zusatzlösungen
• AppDesigner
• individuelle Entwicklung

Schnittstellen

• Quell- und Zielsystem
• Richtung
• technische Endpunkte
• Zeitpläne
• Dienst
• Verantwortlichkeit

Betrieb

• Servicekonten
• Dienste
• Aufgaben
• Backup
• relevante Zertifikate
• Besonderheiten

Restpunkte

Nicht jede Verbesserung muss zwingend vor dem Go-Live umgesetzt werden.

Wichtig ist aber:

Was offen bleibt, bleibt dokumentiert – nicht vergessen.

Eine bereits begonnene Sage-Migration übernehmen oder retten

Nicht jedes Projekt beginnt bei null.

Vielleicht wurde bereits:

• ein neuer Server aufgebaut
• eine Sage-Version installiert
• eine Datenbank migriert
• ein Update begonnen
• ein Testsystem erstellt
• ein früherer Dienstleister gewechselt

und trotzdem bleibt die Frage:

Ist die Umgebung vollständig und bereit für den Produktivbetrieb?

Auch in dieser Situation können wir einsteigen.

Wir beginnen dann nicht wieder blind von vorne, sondern ermitteln den tatsächlichen Zustand:

1. Was wurde bereits umgesetzt?
2. Welche Ausgangsdokumentation existiert?
3. Welche Komponenten wurden übertragen?
4. Welche fehlen?
5. Welche Tests wurden durchgeführt?
6. Welche Fehler bestehen?
7. Gibt es Abweichungen zwischen Produktiv-, Test- und Zielsystem?
8. Welche Restpunkte blockieren den Go-Live?

Anschließend entsteht ein klarer technischer Maßnahmenplan.

Auch ein Wechsel des bisherigen Sage-Partners lässt sich mit einer Migration verbinden. Mehr dazu unter Sage 100 Betreuungswechsel.

Warum Appontes für eine Sage-100-Migration?

Weil wir nicht an der Installationsroutine aufhören

Eine Sage-100-Migration berührt gleichzeitig ERP, Datenbank, Infrastruktur, Entwicklung und Geschäftsprozesse.

Genau an dieser Schnittstelle arbeiten wir.

Sage 100

Wir beschäftigen uns intensiv mit:

• Sage 100 Warenwirtschaft
• Sage 100 Rechnungswesen
• Sage 100 xRM
• Updates und Releases

Entwicklung

Wir analysieren und entwickeln:

• AppDesigner-Lösungen
• Sage-SDK-Erweiterungen
• individuelle Anwendungen
• DLLs
• APIs
• SQL-Erweiterungen
• Automatisierungen

Appontes positioniert die eigene Sage-100-Arbeit ausdrücklich auch über AppDesigner, Schnittstellen und Sage SDK; individuelle Erweiterungen werden im eigenen Haus entwickelt.

SQL Server und Performance

Wir können beurteilen, ob ein Problem im:

• Sage-Client
• Applikationsserver
• SQL Server
• Storage
• Netzwerk
• individuellen Code

entsteht.

Mehr unter Sage 100 Performance & SQL Server.

Applikationsserver

Wir betrachten ServiceDomains, Ressourcen, Last und Konfiguration des Sage 100 Applikationsservers.

Schnittstellen

Wir arbeiten nicht nur mit Sage 100, sondern auch mit den Systemen darum herum.

Dazu gehören beispielsweise:

• Salesforce
• DocuWare
• ITscope
• Praxedo
• Power BI

xRM

Gerade bei umfangreich angepassten xRM-Landschaften ist tiefes technisches Verständnis hilfreich. Appontes beschreibt auf der eigenen xRM-Seite auch den langjährigen persönlichen Entwicklungshintergrund im Sage-100-xRM-Umfeld.

Das Ergebnis ist eine andere Perspektive auf Migration:

Nicht: „Welche Sage-Komponenten müssen wir installieren?“
Sondern: „Welche Komponenten benötigt Ihr Unternehmen, damit der gesamte Prozess danach wieder funktioniert?“

Unser Vorgehen bei einer Sage-100-Migration

1. Technisches Erstgespräch

Wir klären:

• Ausgangsversion
• Ziel
• Infrastruktur
• Anzahl Mandanten
• Benutzer
• Zusatzlösungen
• Individualisierung
• Schnittstellen
• zeitliche Rahmenbedingungen

2. Bestandsaufnahme

Wir dokumentieren die tatsächliche Systemlandschaft.

Nicht nur das, was laut ursprünglichem Projektplan existieren sollte.

3. Zielarchitektur

Wir legen fest:

• Sage-Zielversion
• Windows-Server-Architektur
• SQL Server
• Applikationsserver
• Terminalserver
• Schnittstellen
• Betriebsmodell

4. Testmigration

Wir führen den technischen Migrationsweg reproduzierbar in einer isolierten Umgebung durch.

5. Technische und fachliche Tests

Wir prüfen relevante Geschäftsprozesse, Zusatzlösungen, Schnittstellen, Druck und Reporting.

6. Performancevergleich

Wo sinnvoll, vergleichen wir Alt- und Zielumgebung anhand definierter Messpunkte.

7. Produktivmigration

Der Cutover erfolgt nach einem dokumentierten Ablauf.

8. Nachkontrolle

Wir überprüfen auch zeitversetzte Prozesse, Jobs, Schnittstellen, Backups und Performance.

Was Sie von uns nicht bekommen

Keine Migration nach dem Prinzip:

„Backup einspielen, Setup starten, Benutzer anmelden lassen – fertig.“

Keine Aussage:

„Der neue Server hat mehr CPU, also muss er schneller sein.“

Keine pauschale Zusage:

„Das Update dauert vier Stunden.“

ohne vorher zu wissen, was in Ihrem System tatsächlich vorhanden ist.

Und keine technische Migration, bei der Fachprozesse als Problem der Anwender betrachtet werden.

Eine stark standardisierte Sage-100-Umgebung kann unkompliziert zu migrieren sein.

Eine über zehn oder fünfzehn Jahre individualisierte Installation kann deutlich mehr Vorbereitung erfordern.

Beides ist in Ordnung – wenn man vorher weiß, womit man es zu tun hat.

Häufige Fragen zur Sage-100-Migration

1. Was kostet eine Sage-100-Migration?

Das hängt wesentlich vom Ausgangssystem ab. Eine weitgehend standardisierte Sage-100-Installation mit wenigen Mandanten ist anders zu bewerten als eine langjährig individualisierte Office Line mit Zusatzlösungen, eigenen SQL-Objekten, Schnittstellen und mehreren Servern.

Deshalb sollte vor einer belastbaren Aufwandsschätzung zumindest eine technische Bestandsaufnahme erfolgen.

2. Wie lange dauert ein Sage-100-Versionswechsel?

Die technische Installation selbst ist nur ein Teil der Projektzeit. Entscheidend sind Ausgangsversion, Updatepfad, Datenmenge, Individualisierungen, Zusatzlösungen, Schnittstellen und Testumfang.

Wir unterscheiden deshalb zwischen Projektlaufzeit und tatsächlicher Downtime beim Cutover.

3. Kann eine alte Sage Office Line direkt auf die aktuelle Sage 100 aktualisiert werden?

Das lässt sich ohne Kenntnis der konkreten Ausgangsversion nicht seriös beantworten. Abhängig vom vorhandenen Stand können mehrere technische Migrations- beziehungsweise Updateschritte erforderlich sein.

Wir prüfen deshalb Ausgangs- und Zielversion sowie die dafür relevanten Sage-Vorgaben vor Projektbeginn.

4. Bleiben meine historischen Daten bei der Migration erhalten?

Bei einem Versionswechsel innerhalb der Office-Line-/Sage-100-Produktfamilie ist die Übernahme des vorhandenen Datenbestands grundsätzlich ein wesentliches Ziel der Migration. Vorher prüfen wir jedoch Datenbanken, Ausgangsstand und notwendige Updatepfade.

Eine vollständige und überprüfte Sicherung ist dabei obligatorisch.

5. Wie viel Ausfallzeit entsteht beim Serverumzug?

Das hängt unter anderem von Datenmenge, Infrastruktur, Updateumfang und Schnittstellen ab.

Durch Testmigrationen lässt sich der spätere Cutover deutlich besser planen und die notwendige Downtime abschätzen.

6. Können SQL Server und Sage 100 gleichzeitig aktualisiert werden?

Technisch können mehrere Komponenten Bestandteil desselben Projekts sein.

Ob das sinnvoll ist, hängt von Ausgangs- und Zielumgebung ab.

Bei größeren Änderungen kann es sinnvoll sein, die einzelnen Variablen bewusst zu strukturieren, damit Fehler eindeutig zugeordnet und Tests reproduzierbar durchgeführt werden können.

7. Welche SQL-Server-Version benötigt eine aktuelle Sage 100?

Das ist abhängig von der verwendeten Sage-Version.

Für die recherchierte Sage 100 V9.0.11 vom April 2026 werden Microsoft SQL Server 2019, SQL Server 2022 und SQL Server 2025 in den dort aufgeführten Editionen unterstützt. Vor jeder Migration prüfen wir die Anforderungen der konkret vorgesehenen Sage-Zielversion erneut.

8. Unterstützt Sage 100 Windows Server 2025?

Die Systemvoraussetzungen der Sage 100 V9.0.11 führen Windows Server 2025 Standard für relevante Serverrollen. Auch hier gilt: Maßgeblich ist immer der konkrete Zielstand der Sage 100 zum Zeitpunkt der Migration.

9. Kann Sage 100 von einem physischen auf einen virtuellen Server umziehen?

Ja, eine virtualisierte Infrastruktur ist grundsätzlich möglich. Entscheidend ist, dass CPU, RAM, Storage, Netzwerk und Latenzen den Anforderungen entsprechen. Die Sage-Systemvoraussetzungen weisen explizit darauf hin, dass auch virtualisierte Systeme die notwendigen Ressourcen bereitstellen müssen.

10. Muss für eine Migration ein Testsystem aufgebaut werden?

Für geschäftskritische oder individualisierte Umgebungen empfehlen wir das ausdrücklich.

Unsere Grundhaltung lautet:

Eine produktive Sage-100-Umgebung ist kein Testsystem.

Je mehr Anpassungen und Schnittstellen vorhanden sind, desto wertvoller ist eine reproduzierbare Testmigration.

11. Was passiert mit AppDesigner-Anpassungen?

Sie werden Bestandteil der Inventur und anschließend auf der Zielversion geprüft.

Relevant sind nicht nur sichtbare Maskenanpassungen, sondern auch Datenquellen, Geschäftslogik, Abhängigkeiten und gegebenenfalls verteilte Dateien oder externe Komponenten.

12. Was passiert mit individuellen DLLs und Zusatzlösungen?

Wir dokumentieren Version, Hersteller beziehungsweise Quellcode, Installationsort und Abhängigkeiten.

Anschließend wird geklärt, ob:

• die vorhandene Version weiter verwendet werden kann
• ein Update benötigt wird
• eine neue Version installiert werden muss
• Anpassungsbedarf besteht

Die tatsächliche Funktion wird im Zielsystem getestet.

13. Können Salesforce-, DocuWare- oder Webshop-Schnittstellen weiter verwendet werden?

In vielen Fällen ja – aber auch eine unveränderte Schnittstelle kann durch einen Serverwechsel betroffen sein.

Beispiele sind geänderte Servernamen, Datenbankverbindungen, IP-Adressen, Zertifikate, Dateipfade oder Firewallregeln.

Deshalb sind Schnittstellen Bestandteil des Migrationstests.

14. Was passiert mit SQL-Agent-Jobs?

Sie werden explizit inventarisiert.

SQL-Agent-Jobs sind ein gutes Beispiel dafür, warum das reine Migrieren der Mandantendatenbank nicht ausreicht: Sie sind serverseitige Komponenten und müssen beim Wechsel des SQL Servers gesondert berücksichtigt werden.

15. Was passiert mit individuellen Reports und dem Belegdruck?

Relevante Reports und Belege werden im Testsystem geprüft.

Bei geschäftskritischen Dokumenten vergleichen wir nach Möglichkeit einen definierten Beleg auf Alt- und Zielsystem.

16. Was muss bei Power BI berücksichtigt werden?

Unter anderem Datenquelle, Servername, Datenbank, Credentials, Gateway und Refresh.

Besonders wichtig: Nach dem Go-Live muss sichergestellt sein, dass Berichte nicht unbemerkt weiterhin auf die alte Produktivumgebung zugreifen.

Mehr dazu unter Power BI und Sage 100.

17. Können Sie auch Terminalserver und RDS mit migrieren?

Ja. Bei solchen Projekten betrachten wir Sage-Client, Zusatzlösungen, Benutzerprofile, Druck, Berechtigungen, Office-Komponenten und benötigte Netzwerkpfade gemeinsam.

18. Können Sie nur den SQL Server beziehungsweise Applikationsserver übernehmen?

Ja.

Nicht jede Migration muss die vollständige Infrastruktur betreffen.

Wir unterstützen auch gezielt bei einer SQL-/Performance-Thematik oder beim Sage Applikationsserver.

19. Können Sie eine bereits problematische Migration übernehmen?

Ja.

Wir analysieren zunächst den erreichten Stand und unterscheiden zwischen:

• bereits korrekt umgesetzten Komponenten
• fehlenden Bestandteilen
• Fehlkonfigurationen
• ungeprüften Bereichen
• tatsächlichen technischen Fehlern

Anschließend entsteht eine priorisierte Restpunkteliste.

20. Kann der Sage-Betreuungspartner gleichzeitig mit der Migration gewechselt werden?

Grundsätzlich lässt sich ein Betreuungswechsel mit einem technischen Modernisierungsprojekt verbinden.

Wichtig ist eine saubere Übergabe von Systemwissen, Lizenzen, Anpassungen, Zugängen und Dokumentation.

Mehr dazu: Sage 100 Betreuungswechsel.

21. Welche Informationen benötigen Sie für eine erste Einschätzung?

Hilfreich sind insbesondere:

• aktuelle Sage-Version
• Anzahl Mandanten
• Anzahl Benutzer
• eingesetzte Module
• SQL-Server-Version
• Windows-Server-Version
• Zusatzlösungen
• bekannte Individualentwicklungen
• AppDesigner-Anpassungen
• Schnittstellen
• Ziel der Migration

Wenn nicht alles bekannt ist, ist das kein Problem.

Genau dafür gibt es die Bestandsaufnahme.

Sage 100 migrieren – mit Blick auf das Gesamtsystem

Eine Sage-100-Migration ist kein isoliertes Setup-Projekt. Sie verbindet ERP, Infrastruktur, individuelle Erweiterungen und die Abläufe, auf die Ihr Tagesgeschäft angewiesen ist.

Erfolgreich ist die Migration erst, wenn Ihre Geschäftsprozesse im neuen System mindestens genauso zuverlässig funktionieren wie vorher.