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 und der Rechnungsversand nutzt einen bestimmten SMTP-Relay. Ein Power-BI-Dataset verwendet einen hart hinterlegten Servernamen, eine Zusatzlösung schreibt Dateien auf eine Freigabe und 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 die installierte Sage-100- beziehungsweise Office-Line-Version mit Patch- und LiveUpdate-Stand, die globale Sage-Datenbank und die Mandantendatenbanken, die vorhandenen Mandanten und die eingesetzten Module in Warenwirtschaft, Rechnungswesen und xRM. Dazu kommen Benutzer, Rollen und Berechtigungen, Besonderheiten bei Anmeldung und Authentifizierung, zentrale Konfigurationen sowie relevante Dateipfade und Freigaben.

Anpassungen und Entwicklung. Wir prüfen AppDesigner-Lösungen, kundenspezifische Metadaten, individuelle Masken und Dialoge, Individualentwicklungen, Sage-SDK-Erweiterungen und Zusatzlösungen anderer Hersteller. Auf Dateiebene gehören Assemblies, DLLs, zusätzliche EXE-Dateien und Konfigurationsdateien dazu, auf Datenbankebene eigene Tabellen, Views, Stored Procedures, Funktionen, Trigger und 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 und Zeitpläne, Wartungsjobs, Windows-Dienste, geplante Windows-Aufgaben, Import- und Exportprozesse, Dateiüberwachungen, Batch- oder PowerShell-Skripte, externe Programme und Hintergrundverarbeitung.

Schnittstellen. Wir dokumentieren, welche Systeme Daten mit Sage 100 austauschen und in welcher Richtung. Zum Beispiel Salesforce, DocuWare, ITscope und Praxedo, außerdem Webshops, EDI und E-Procurement mit cXML, EDIFACT oder openTRANS, individuelle REST- und Web-APIs, Dateiimporte und -exporte, Fremddatenbanken sowie weitere ERP-, CRM-, DMS- und Logistiksysteme. Mehr zu unserer Arbeit mit Sage-100-Schnittstellen und Systemintegration.

Belegdruck und Reporting. Wir betrachten individuelle Beleglayouts für Rechnungen, Auftragsbestätigungen, Lieferscheine, Bestellungen und Mahnungen, außerdem Druckerzuordnungen, PDF-Erzeugung und Versandwege. Beim Reporting geht es um Datenquellen, Excel-Auswertungen, individuelle Reportinglösungen und Power BI auf Basis von Sage-100-Daten.

Infrastruktur. Zur Inventur gehören Windows-Server-Versionen, SQL-Server-Version, Edition und Instanzen, der Sage Applikationsserver, Terminalserver und Remote Desktop Services sowie virtuelle Maschinen mit CPU, RAM, Storage und Disk-I/O. Auf Netzwerkseite prüfen wir Latenzen, DNS, Firewall und Freigaben, dazu Servicekonten, NTFS-Berechtigungen und Zertifikate. Abgerundet wird das Bild durch Backupkonzept und Wiederherstellbarkeit der Sicherungen, Virenscanner beziehungsweise EDR und die Microsoft-365- oder 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. Ein erfolgreicher Login ist noch kein erfolgreicher Systemumzug. Wir testen deshalb nicht nur, ob Sage startet, sondern ob die relevanten Geschäftsprozesse Ende-zu-Ende funktionieren.

Sage Office Line → Sage 100

Viele Unternehmen arbeiten noch mit der Sage Office Line, um ihre Belege zu erstellen, Geschäftsdaten auszuwerten und Buchungen durchzuführen.

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 finden Sie in unserem Fachbeitrag Von der Sage Office Line zur Sage 100.

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

AppDesigner-Lösungen gehen weit über eine reine Maskenanpassung hinaus und betreffen unter anderem Datenquellen, Geschäftsprozesse, Oberflächenelemente und die Einbindung beziehungsweise Verteilung zusätzlicher Komponenten.

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

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

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 sollte eine Konfiguration zur tatsächlichen Last, zur Sage-Umgebung und zur verwendeten SQL-Server-Version passen.

Mehr dazu: Sage 100 Performance & SQL Server.

Sage Applikationsserver

Der Sage Applikationsserver ist ein zentraler Bestandteil der Architektur und trotzdem wird sein Einfluss auf die Gesamtperformance häufig unterschätzt. Deshalb ist ein Serverwechsel 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

Unsere Erfahrung deckt sich mit den offiziellen Systemvoraussetzungen: Damit der Applikationsserver seine Serverrolle ausfüllen kann, müssen dessen Ressourcenanforderungen erfüllt werden. 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
• 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 und wird 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?

Eine Sage-100-Migration berührt gleichzeitig ERP, Datenbank, Infrastruktur, Entwicklung und Geschäftsprozesse. Wir kennen Sage 100 und dessen Einbindung in der Praxis.

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. Auf unserer xRM-Seite können Sie unseren langjährigen persönlichen Entwicklungsbeitrag zur Entstehung des Sage 100 xRM nachlesen.

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.

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.