[Gelöst]Migration von 4.0 SP3 zu NAV2009 oder NAV 2013

Sehr geehrte Forenteilnehmer,

wir setzen zur Zeit noch NAV 4.0 SP3 auf Windows XP-Clients ein (Datenbank: SQL Server 2005) und möchten auf NAV 2009 (oder idealerweise NAV 2013) (Client-OS: Windows 7) migrieren.

Zahlreiche Objekte sind an die Unternehmensanforderungen angepasst mit umfangreichen Coding.

Im ersten Schritt möchte ich In Erfahrung bringen, wieviele Migrationsschritte denn erfahrungsgemäß erforderlich/empfehlenswert sind, um von NAV 4.0 SP3 zu NAV 2009 (oder idealerweise NAV 2013) zu gelangen.

Hat jemand hier Erfahrungen damit?

Schönen Gruß
Igel

Zuletzt geändert von Igel am 9. August 2013 12:28, insgesamt 1-mal geändert.

[Freestyler]

Sehr geehrte Forenteilnehmer,

wir setzen zur Zeit noch NAV 4.0 SP3 auf Windows XP-Clients ein (Datenbank: SQL Server 2005) und möchten auf NAV 2009 (oder idealerweise NAV 2013) (Client-OS: Windows 7) migrieren.

Zahlreiche Objekte sind an die Unternehmensanforderungen angepasst mit umfangreichen Coding.

Im ersten Schritt möchte ich In Erfahrung bringen, wieviele Migrationsschritte denn erfahrungsgemäß erforderlich/empfehlenswert sind, um von NAV 4.0 SP3 zu NAV 2009 (oder idealerweise NAV 2013) zu gelangen.

Hat jemand hier Erfahrungen damit?

Schönen Gruß
Igel

Hallo,

IIRC Microsoft supportet es nicht offiziell, von NAV 4.03 auf 2009 / 2013 zu upgraden, sondern empfiehlt einen kompletten Neustart

Zuletzt geändert von Freestyler am 7. August 2013 09:55, insgesamt 1-mal geändert.

Hallo,

Microsoft supportet es nicht, von NAV 4.03 auf 2009 / 2013 zu upgraden, sondern empfiehlt einen kompletten Neustart

Da frage ich mich woher du diese Information hast.
Auf meiner Installations-CD für NAV 2009 ist ein Upgrade- Toolkit sogar für NAV 3.70 enthalten. daher gehe ich davon aus, das MS ein Update zumindest von der Version 3,7 auf NAV 2009 unterstützt.
Richtig ist allerdings, das man nur von NAV2009 auf NAV 2013 updaten kann.

Ein Update von Version 4 halte ich persönlich für ein durchaus durchführbares Projekt. Hier stellt sich die Frage auf welche Version man upgraden will.
Geht man nur auf Version 2009 Classic, halte ich das für ein sehr überschaubares Projekt.
Möchte man auf den RTC wechseln, macht es eigentlich nur Sinn auf NAV 2013 zu wechseln. Dies ist es allerdings ein etwas aufwändigeres Unterfangen, insbesondere dann, wenn man sehr viele Berichte angepasst hat.
Desweiteren darf man die Laufzeiten des Updates nicht außer acht lassen, die allerdings beim Update auf NAV 2013 im wesentlichen von der Größe der Datenbank und der Anzahl Dimensionsposten abhängt.

Wenn du auf den RTC wechseln möchtest, darfst du auch den Schulungsaufwand für die Mitarbeiter nicht vergessen. Die neue Oberfläche sieht komplett anders aus, und die Tastenkombinationen sind auch anders. Wer aber in NAV- CC nicht nur Tastenkombinationen auswendig gelernt hat, sondern weiß was er tut, findet sich in NAV2013 u.U. besser zurecht, als in der alten Version.

Zu deiner Frage nach der Anzahl Migrationsschritte kann man sagen das man immer mindestens zwei Schritte für ein Versions- Update benötigt den sog. Step 1 und Step 2. Wenn du also von NAV 4 nach 2009 updaten möchtest, musst du aus dem passenden Upgradetoolkit jeweils Step 1 und 2 ausführen. Möchtest du auf NAV 2013 aktualisieren musst du auch das Upgrade- Toolkit für das Update von NAV 2009 nach 2013 ausführen (dies ist eine sehr verkürzte Darstellung eine Updates, detailiertere Infos findest du mit einer Suche im Forum)

Gruß, Fiddi

Vielen Dank fiddi für die prompte Antwort, die mir fürs erste schon gut weiterhilft!

Kleine Ergänzung:
Prinzipiell ist auch ein direktes Update von NAV 4 nach 2013 möglich. Hier müsste euer NAV- Partner allerdings die Upgrade- Toolkits für NAV 4 nach 2009 und 2009 nach 2013 mischen. Das dürfte mit einigem Programmier- und Testaufwand verbunden sein, der sich nur dann lohnt, wenn es Laufzeitprobleme beim Update gibt, oder der Aufwand für eine 2009er- Version der Tabellen zu viel Arbeit bedeuten würde.

Gruß, Fiddi

Prinzipiell ist auch ein direktes Update von NAV 4 nach 2013 möglich.

Da sollte man aber vorher klären, ob speziell designte Forms, wie z.B. hier, vorhanden sind. Das ist mit Pages ohne Add-ins nicht machbar, und dafür gibt es keine Updateroutine.

Da sollte man aber vorher klären, ob speziell designte Forms, wie z.B. hier, vorhanden sind. Das ist mit Pages ohne Add-ins nicht machbar, und dafür gibt es keine Updateroutine.

Da hast du schon Recht, aber das hat mit dem speziellen Fall des direkten Updates von NAV 4 nach 2013 nichts zu tun. Das muss man bei einem Update auf RTC immer klären.

Habe ich eine passende Page in 2013 kann ich updaten (egal ob von NAV 4 -> 2009 -> 2013, oder direkt NAV 4->2013) . (ich will ja nicht in NAV 2009 arbeiten, ich benötige ja nur die Daten zum konvertieren)

Gruß, Fiddi

Da hast du schon Recht, aber das hat mit dem speziellen Fall des direkten Updates von NAV 4 nach 2013 nichts zu tun. Das muss man bei einem Update auf RTC immer klären.

In NAV 2009 kann man zur Not ja noch zweigleisig fahren und zumindest die Benutzer, die sehr spezielle Forms benötigen, mit dem CC arbeiten lassen, auch wenn das vom Aufwand nicht gerade empfehlenswert ist und man dem RTC an allen Ecken und Enden anmerkt, dass das eine Übergangsversion mit vielen Einschränkungen ist. Die Möglichkeit hat man ab NAV 2013 ja nicht mehr, auch bei den Reports. Da muss alles neu programmiert werden, in NAV 2009 kann man den CC weiterhin zum Rendern der alten Reports nutzen, auch wenn man sonst nichts damit macht.

Also verstehe ich das richtig?
Wenn man auf NAV 2009 upgradet, kann man weiterhin den CC betreiben oder auch den RTC? Im Falle des RTC kann man mit Visual Studio programmieren und debuggen?
Wenn man dann noch auf NAV 2013 migriert muss sämtlicher "benutzerdefinierte" Code komplett neu manuell programmiert werden?

Viele Grüße
Igel

Also verstehe ich das richtig?

Nicht ganz.

In NAV 2009 kann man den Classic- Client (CC) weiterhin benutzen, so wie du Ihn aus NAV 4 kennst. Nur die Farben sind etwas anders.
NAV 2009 bietet aber auch die Möglichkeit bereits den Role Tailored Client (RTC) zu benutzen. Dafür müssen aber alle Anpassungen aus den Forms in die entsprechenden Pages (Ersatz für die Forms), soweit möglich und nötig, übertragen werden. Möchtest du auch die RTC- Reports benutzen, so sind auch die umzustellen, bzw. die Änderungen an den Standardreports in die entsprechenden RTC- Reports zu übernehmen.
In NAV 2013 gibt es nur noch den RTC, es ist auch kein parallel- Betrieb von CC und RTC wie 2009 mehr möglich. Alle Anpassungen müssen, soweit nötig, in die entsprechenden RTC- Komponenten (Forms- >Pages,CC- Reports-> RTC- Reports) konvertiert werden.
In meinen Augen hast du allerdings nur zwei wirklich interessante Optionen: NAV 2009 als CC (wobei das ein Auslaufmodell ist) oder NAV 2013. Die Option NAV 2009 RTC ist, wie Kowa schon sagte, nicht wirklich eine gute Wahl. Aber bei gravierenden Einschränkungen (z.B. eigene Anpassungen können nicht so ohne weiteres nach NAV 2013 konvertiert werden, oder mangelnde für die Umstellung notwendige Ressourcen) kann doch der Weg über NAV 2009 RTC geboten sein.

Gruß, Fiddi

Ich denke ein Entscheidungsfaktor wird wohl auch sein:
Hat das Unternehmen aktuell einen auslastenden Auftragsbestand, wird man maximal ein NAV 2009CC -Upgrade durchführen.
Wenn es gerade eine leichte Flaute gibt, die nicht unternehmensgefährdend ist, hat man als Kunde erst genug Zeit von CC auf RTC umzusteigen.

"Aber bei gravierenden Einschränkungen (z.B. eigene Anpassungen können nicht so ohne weiteres nach NAV 2013 konvertiert werden, oder mangelnde für die Umstellung notwendige Ressourcen) kann doch der Weg über NAV 2009 RTC geboten sein"
Ich finde, das hört sich vernünftig an. Dann könnten wir -nachdem wir alles auf 2009 "gehoben" haben- in NAV 2009 Schritt für Schritt in einem Testsystem (Abbild der Prod.) sämtliche Forms und Reports für RTC neu bauen (ich denke, es gibt sicher keinen Konverter, der einem das abnehmen kann). Und wenn alles fertig ist und gründlich getestet, können wir auf NAV 2013 migrieren. Vor der Migration zu 2013 natürlich immer im Auge behaltend, dass Änderungen in Produktion in den neuen Forms und Reports berücksichtigt werden, aber das halte ich für vertretbar.

Ist das ein aus Eurer Sicht gangbarer Weg?
Und was passiert eigentlich mit den DataPorts und CodeUnits? Müssen die neu programmiert werden?

Viele Grüße
Igel

Ich finde, das hört sich vernünftig an. Dann könnten wir -nachdem wir alles auf 2009 "gehoben" haben- in NAV 2009 Schritt für Schritt in einem Testsystem (Abbild der Prod.) sämtliche Forms und Reports für RTC neu bauen (ich denke, es gibt sicher keinen Konverter, der einem das abnehmen kann). Und wenn alles fertig ist und gründlich getestet, können wir auf NAV 2013 migrieren. Vor der Migration zu 2013 natürlich immer im Auge behaltend, dass Änderungen in Produktion in den neuen Forms und Reports berücksichtigt werden, aber das halte ich für vertretbar.

Theoretisch schon, praktisch gibt es zwischen 2009 und 2013 aber ein paar kleine nicht unwichtige Unterschiede, die u.U. für doppelte Arbeit sorgen, bzw. für Frust bei den NAV 2009 RTC- Anwendern (Organisation der Pages, Aufbau der Reports). Prinzipiell ist der Weg aber so durchführbar, wenn auch doppelter Testaufwand bei der Migration nach 2013.

Und was passiert eigentlich mit den DataPorts und CodeUnits? Müssen die neu programmiert werden?

Codeunits müssen nicht geändert werden, sofern sie nicht, auf Forms oder Dateports zugreifen, oder auf Dateien direkt zugreifen. (gilt im wesentlichen für 2009, in 2013 werden Form durch Pages ersetzt (mit Tool), und Dataports durch XML- Ports).
Dataports werden in der RTC- Umgebung durch XML-Ports ersetzt.

Bei der RTC- Umstellung ist außerdem auf die 3-Tier- Umgebung zu achten (welches Objekt läuft wo und unter welchem Benutzer)

Gruß, Fiddi

...sämtliche Forms und Reports für RTC neu bauen (ich denke, es gibt sicher keinen Konverter, der einem das abnehmen kann). ...
...

Für Forms gibt es ein Transformation Tool, was normal nach Guideline erstellte Forms migriert. Für Reports hat glaube ich Yaveon ein Tool im Angebot.

...
Ist das ein aus Eurer Sicht gangbarer Weg?

Definitv.

...
Und was passiert eigentlich mit den DataPorts und CodeUnits? Müssen die neu programmiert werden?
...

Dataports müssen tatsächlich neu programmiert werden, weil die nicht mehr unterstützt werden. Codeunits müssen ggf. auf die 3-tier Architektur angepasst werden (z.B. Dateihandling)

Wie sind denn Eure Erfahrungen mit den Konvertern, sind die Konverter für Forms und Reports denn auch in der Lage C/AL-Code zu konvertieren? Wenn ja, wie sind hier Eure Erfahrungen? Sollte man vielleicht besser alles manuell neu programmieren?

Und wie sieht denn eine Migration von 4.0 auf den 2009er-Classic-Client konkret aus? Die Tabellen werden bei uns schon in einer SQL Server-Datenbank betrieben.
Gibt es in 2009-CC noch die SIFT-Tables? Welche Änderungen führt denn ein Upgrade-Toolkit durch? Wenn Änderungen in den "Tabellenarchitekturen" erfolgen, dauert es bei unserer 67GB großen DB sicher sehr lange
Können die Forms, Reports und Dataports nach 2009-CC eins zu eins übernommen werden? Macht das Upgrade-Toolkit alles nötige? Wie sind da Eure Erfahrungen?

Viele Grüße
Igel

bitte auch beachten, dass 2013 eigentlich nicht auf XP supported wird.
habe allerdings selbst vor kurzem mehrere client-installationen auf xp erfolgreich durchgeführt.

weiterhin haben wir eine 90gb db von 370 auf 2009r2 gehoben - die 90gb db war noch nativ - also gleichzeitig eine sql migration durchgeführt.
die komplette migration von 370 auf 2009 inkl. sql-umstellung lief an einem wochenende - soviel zum zeitlichen aufwand.
bring erstmal alles auf 2009, wandel die reports um und schau dir die cu's zwecks dateihandling an. wenn dort alles passt, kannst du weiter auf 2013 gehen.

der yaveon-konverter für die reports ist ganz nützlich, setzt allerdings auch einiges an handarbeit voraus, da man ihm ja sagen muss, welche section was im rdlc sein soll ...etc.

Wie sind denn Eure Erfahrungen mit den Konvertern, sind die Konverter für Forms und Reports denn auch in der Lage C/AL-Code zu konvertieren? Wenn ja, wie sind hier Eure Erfahrungen? Sollte man vielleicht besser alles manuell neu programmieren?

Prinzipiell kann man sagen, Sie funktionieren. Aber: Das ganze ist nicht ohne Aufwand, und auch dann nicht Problemfrei (Reports funktionieren nur als Vorschau oder PDF oder Word vernünftig aber nicht in allen gleichzeitig, sind wg. hoher erzeugter Datenmengen langsam oder stürzen wg Speicherüberlauf ab). Je nach Anpassung der Objekte kann es auch einige Programmumstellungen erfordern (Code in im RTC nicht mehr vorhandenen Triggern), die man auch gleich im RTC direkt programmieren könnte.
Ich bevorzuge die Methode, die Forms/Reports der Kundenversion mit einer Basis-NAV- Version zu vergleichen, und die Abweichungen in die neuen Pages und Reports zu übernehmen. Das hat den Vorteil, das man sie bei der nächsten NAV- Version wieder gegen den NAV- Standard mergen kann, was bei den konvertierten nicht unbedingt funktioniert. Für Eigenkreationen kann man das natürlich nicht machen, aber diese Pages hat man u.U. schneller im RTC neu erstellt, als das Tiff- Tool angepasst. Ein weiterer Vorteil meiner Methode ist das Kennenlernen der neuen (Programmier-) Umgebung.

Und wie sieht denn eine Migration von 4.0 auf den 2009er-Classic-Client konkret aus? Die Tabellen werden bei uns schon in einer SQL Server-Datenbank betrieben.

Das ist eher von Vorteil. Die Migration erfolgt nach den Vorgaben des UGT (Siehe Forum). Das muss u.U. angepasst werden, damit eure Daten korrekt in NAV 2009/2013 übernommen werden.

Gibt es in 2009-CC noch die SIFT-Tables? Welche Änderungen führt denn ein Upgrade-Toolkit durch? Wenn Änderungen in den "Tabellenarchitekturen" erfolgen, dauert es bei unserer 67GB großen DB sicher sehr lange

JEIN, es gibt entsprechende Views, die Funktionalität in NAV hat sich aber nicht geändert. DB- Größe: Kommt ein bisschen auf die Hardware an, aber im wesentlichen auf die Art der nötigen Änderungen und das Können des Programmierers, der das UGT anpasst.

Können die Forms, Reports und Dataports nach 2009-CC eins zu eins übernommen werden? Macht das Upgrade-Toolkit alles nötige? Wie sind da Eure Erfahrungen?

Sofern die keine Änderungen in NAV 2009 tangieren: JA!
EDIT:Das Upgradetoolkit ändert nur Daten keine Objekte!

Gruß, Fiddi

Wie verhält es sich denn mit der Programmiersprache?
In 2009-CC gibt es ja nach wie vor die Sprache C/AL.
In 2009-RTC: nur .NET oder auch C/AL oder? Und Programmierung/Debuggen nur in Visual Studio?
In 2013: nur .NET?

Bitte klärt mich noch in diesem Punkt kurz auf.

Vielen Dank!
Igel

Alles wie bisher C/AL, nur für das Reportdesign für den RTC wird Visualstudio benötigt, und da wäre es schön, wenn man ein bisschen Visual Basic verstehen könnte (ist fürs Kästchenschieben aber nicht unbedingt notwendig).
Wer bisher viel mit Automations in NAV gearbeitet hat, sollte sich auch mit .Net beschäftigen, wenn er auf NAV 2013 umstellen möchte.

Gruß, Fiddi

Wie verhält es sich denn mit der Programmiersprache?

Zusätzlich zum von Fiddi schon gesagten, wenn man Add-ins einsetzen will, dann kommt noch C# dazu.

Ok, ich fasse mal stichpunktartig zusammen:

NAV 2009: Classic(CC) und RoleTailored(RTC)-Architektur lassen sich parallel betreiben.
NAV 2013: Ausschließlich RTC
________
********** RTC ************
Forms:
Gibt es im RTC nicht mehr. Es gibt ein Form Transformation Tool, um Forms zu Pages zu transformieren. Jedoch meist nicht ohne manuelle Anpassungen.
Reports:
Müssen konvertiert bzw. neu gebaut werden als RTC-Reports. Konverter: von Fa. Yaveon
Die Anpassung von Reports ist besonders aufwändig.
Dataports:
gibt es im RTC nicht mehr. Müssen neu programmiert werden als XMLports
Codeunits:
Müssen z.B. bzgl. Dateihandling manuell angepasst werden oder falls sie auf Dataports oder Forms zugreifen.

Bei Automations empfiehlt sich .NET.
________
******* Programmiersprachen *********
CC: C/AL
RTC: wie bisher C/AL, nur für das Reportdesign für den RTC wird Visualstudio benötigt (z.B. VB.NET oder C#)

________
******* SIFT *********
Ab NAV 5.0 gibt es keine SIFT-Tables mehr, sondern Indexed Views!
Bei Verwendung sehr großer SIFT-Tables wird die Datenmigration entsprechend aufwändig.

________
******* Upgrade Toolkit ******
Das Upgradetoolkit ändert nur Daten keine Objekte!
Unter Umständen muss das Upgrade-Toolkit angepasst werden, damit die Daten korrekt übernommen werden.

Bleibt noch eine letzte Frage, die ich stelle:
Muss man außer dem SQL-Datenbankserver unter 2009 CC auch schon einen dedizierten Applikationsserver installieren, also eine separate Maschine einrichten, oder gilt das nur für RTC?

Viele Grüße
Igel

Hallo,

sehr gute Zusammenfassung!

Ergänzung:
- Die Umstellung der SIFT- Tables erfolgt schon, wenn du deinen Client auf technisch NAV5.0 SP1 mit aktuellem Patch- Level bringst. Das wurde schon während Version 5 umgestellt.
- in NAV muss man den Application- Server und den Service- Tier- Server unterscheiden. Der Application- Server (NAS) ist schon in früheren Versionen verfügbar. Er sorgt für die Hintergrundbearbeitung von NAV- Aufgaben. Den kannst/musst du auch in einer reinen CC- Umgebung installieren und benutzen. Der Service- Tier-Server ist für den RTC und die Webservices zuständig. Den kannst/musst du installieren, wenn du diese Dienste nutzen möchtest, sonst nicht.
In NAV 2013 übernimmt ein Service- Tier- Server (Dienst) auch die Aufgaben des NAS.

Ob du für den Servie-Tier zusätzliche Maschine(n) benötigst, hängt von der Anzahl deiner Arbeitsplätze und deren (intensive!?) Benutzung ab.

Gruß, Fiddi

Abschließend möchte ich allen, die sich meiner Fragen angenommen haben,
ein ausdrückliches Dankeschön! aussprechen.

Eure Antworten waren sehr hilfreich, so dass ich mir ein erstes Gesamtbild der Migrationsmöglichkeiten aufbauen konnte.

Viele Grüße
Igel