Upgrade-Strategie

Hallo allerseits,

bei einem befreundeten Unternehmen habe ich folgendes Vorgefunden: Navision Datenbankserver Version 3.6, ca. 100 GB native Datenbank, Windows Server 2003. Die ca. 60 Clients laufen auf Windows 7 Maschinen in einer VM mit Windows XP. Es gibt sehr viele individuelle Anpassungen/Erweiterungen. Ein Wartungsvertrag ist vorhanden.

Die Lösung mit XP soll weg, also ist ein Upgrade auf jeden Fall erforderlich.
Dafür gibt es jetzt die verschiedensten Möglichkeiten:

1. technisches Upgrade auf 2009 R2, weiterhin native Datenbank
das wäre wahrscheinlich der schellste und kostengünstigste Weg

2. technisches Upgrade auf NAV 2017 (nur SQL-Datenbank möglich)
geht das Überhaupt bei Beibehaltung der alten Applikations-Objekte?

3. komplettes (technisch und Applikation) Update auf NAV 2017
das wäre wohl der Königsweg, allerdings müssten dann viele viele Anpassungen neu gemacht werden

Was würdet Ihr vorschlagen bzw. wo liegen die Stolpersteine und Probleme bei den Lösungen 1-3? Oder gibt es noch eine vierte, fünfte, Ente Möglichkeit?

Hallo,

Antwort 2 scheidet schon mal aus. Ein rein technisches Update auf 2017 ist von 3.6 nicht möglich, da hier auch der Umstieg von Classic zu Roletaylored-Client erfolgen müsste.

Ich würde mich im ersten Moment für Weg 1,5 entscheiden. NAV 2009R2 mit SQL-Server wenn es etwas kurzfristiges sein soll/muss. Das ist sowieso der Weg zu Antwort 3. Um den du über kurz oder lang sowieso nicht herum kommst. Und je früher du das machst, desto geringer ist das Delta zwischen den Funktionalitäten der alten und der neuen Version. Wobei das in diesem Fall schon fast egal ist.

Die wichtigste Frage, die du dir vor einem eventuellen Update stellen musst, ob es sinnvoller ist neu anzufangen, oder ob man ein Update durchführen muss wegen der Historie.
Musst du ein Update fahren, ist dein größtes Problem wohl der Zeitrahmen des Updates. Nach MS- Lesart wären dann folgende Updates notwendig NAV3.6->NAV5->NAV2009->NAV2013->NAV2017. Wenn die Datenbank dann auch ausgiebig mit Dimensionen gespickt ist, kannst du das Update mal mit einer Woche Laufzeit einplanen, wenn du es mit NAV- Bordmitteln versuchst.

Mann kann es bei eurer DB- Größe u.U. aber auch an einem Wochenende oder weniger hinbekommen, wenn man die Updates zusammenfasst, und einfache Aufgaben, in SQL-Skripte auslagert.

Gruß Fiddi

Danke,

ok, 2009R2 ist auch mein erster Gedanke.

Fragt sich halt nur, ob SQL-Server oder native Datenbank.

Wenn die native Datenbank weiter benutzt wird, dann müssten keine Objekte angefasst werden, oder? Man könnte doch die bestehende Datenbank einfach konvertieren (oder besser ein Backup einspielen ?), die Clients updaten und das war's.

Beim Umstieg auf SQL-Datenbank müssten die Datumsfelder gecheckt werden und die andere Code-Felder-Sortierung muss ggf. berücksichtigt werden - das scheint mir ein relativ geringer Aufwand zu sein. Oder gibt es da noch mehr zu berücksichtigen?

Welche Vorteile (außer Table-Locking) bringt denn die SQL-Datenbank? Braucht man einen Datenbank-Admin, der gut mit SQL-Server umgehen kann?

Wenn die native Datenbank weiter benutzt wird, dann müssten keine Objekte angefasst werden, oder?

Das kommt darauf an. Wenn Ihr z.B. die Officeintegration benutzt, könnte das schon sein, dass das mit der neuen Version nicht funktioniert. Generell müsst ihr euch alle Objekte anschauen die schnittstellen mit externen Programmen haben (ADCS,...)

Beim Umstieg auf SQL-Datenbank müssten die Datumsfelder gecheckt werden und die andere Code-Felder-Sortierung muss ggf. berücksichtigt werden - das scheint mir ein relativ geringer Aufwand zu sein. Oder gibt es da noch mehr zu berücksichtigen?

Dafür gibt es Tools von MS oder Mibuso (letzteres ist erheblich schneller) die das prüfen und korrigieren (aber erst mit einer nach 2009 konvertierten Native-DB machen)

Welche Vorteile (außer Table-Locking) bringt denn die SQL-Datenbank? Braucht man einen Datenbank-Admin, der gut mit SQL-Server umgehen kann?

- Frage wie lange dauert es eine Datensicherung in der native zurückzusichern? Funktioniert das überhaupt noch bei euch? Der SQL-Server sichert eure DB auf einem aktuellen Server in weniger als 1 Stunde, und ein Restore nimmt erheblich weniger Zeit in Anspruch. Man kann auch kontinuierlich alle 10 Minuten Änderungen sichern, und verliert bei einem Ausfall nur die Daten seit der letzten Änderungssicherung.
- Einen Datenbank- Admin braucht man nicht unbedingt, wenn das System einmal richtig eingerichtet wurde.
- Der SQL-Server ist erheblich besser skalierbar. d.h. er nutzt nicht nur max. 1GB Arbeitsspeicher und einen Core sondern alles was Lizenz, Hardware und Konfiguration hergeben.

Gruß Fiddi

ja, die Datensicherung ist durchaus ein Thema! Das dauert täglich ziemlich lange. Rücksichern funktioniert auch. Ab und zu wird eine Rücksicherung gemacht, um zu checken, ob das geht - dauert aber ewig - ist zum Glück bisher noch nie im Echtbetrieb erforderlich gewesen.

Antwort 2 scheidet schon mal aus. Ein rein technisches Update auf 2017 ist von 3.6 nicht möglich, da hier auch der Umstieg von Classic zu Roletaylored-Client erfolegen müsste.

Ist das so? Das heißt, es könnte eine höhere technische Version als 2009R2 ohnehin nicht eingesetzt werden? Wenn ich das richtig verstehe, dann müsste beim Einsatz von Nav 2017 also auf den 2017er Applikations-Objekten aufgesetzt werden und alle Anpassungen/Erweiterungen müssten neu gemacht werden - sofern sie nicht inzwischen ohnehin im Standard vorhanden sind.

Ja. sofern es sich um visuelle Objekte wie Reports und Forms bzw. Dataports handelt. Tabellen und Codeunits könnten u.U. übernommen werden. Ebenso sind Schnittstellen in Datei- oder auch anderer Form an die neue Struktur anzupassen.

Gruß Fiddi

Braucht man einen Datenbank-Admin, der gut mit SQL-Server umgehen kann?

Ganz klares: Ja. Bei SQL kann man vieles einstellen, bei der nativen Datenbank nicht. Nur: Man muss bei SQL auch vieles einstellen, und dann muss man auch wissen was man tut. Das kann aber natürlich auch der Microsoft-Partner sein, als Endkunde braucht man den SQL-Spezialisten nicht im Haus.