[Gelöst] NAV "Migration" 2009 CC -> 2016 RTC

Hallo liebe Forengemeinde,
In meiner Firma steht ein großes Projekt an. Es soll der 2009 CC auf den 2016 RTC aktualisiert werden.
Ich recherchiere aktuell wie man die Daten migrieren kann und bin dabei auf diese beiden MSDN Einträge gestoßen:

https://msdn.microsoft.com/en-us/library/hh169484(v=nav.70).aspx
https://msdn.microsoft.com/en-us/library/dn271649(v=nav.90).aspx

Nach meinem ersten Lesen muss man wohl zuerst auf NAV 2013 upgraden bevor man auf weitere Versionen upgraden kann.
Sind diese beiden Artikel grundsätzlich die richtige Richtung oder gibt es noch andere "Tools" die man nutzen könnte?
Im Hinterkopf habe ich noch irgendwas von "RapidStart" in Bezug auf die Datenmigration.

Vielen Dank und beste Grüße,
Thomas

Zuletzt geändert von ThomasM am 22. Februar 2016 15:08, insgesamt 2-mal geändert.

Hallo,

ob man das so machen kann, hängt ein wenig von der DB- Größe ab, ob und wieviele Dimensionen Ihr benutzt, und wie Lange euer System stehen darf.

Gruß Fiddi

Links im Startbeitrag bitte in URL-Tags einschließen, da diese sonst nicht anklickbar sind.

Hallo,

ob man das so machen kann, hängt ein wenig von der DB- Größe ab, ob und wieviele Dimensionen Ihr benutzt, und wie Lange euer System stehen darf.

Gruß Fiddi

Besten Dank für diese Info, allerdings bin ich nur ein wenig schlauer dadurch.
Gibt es irgendwo belastbare Zahlen/Aussagen dazu?

Vermutlich scheitert es bei uns bereits an der SQL Server Lizenz: Wir haben "nur" eine SQL 2014 Runtime, und da darf die DB max. 80GB groß werden, soweit ich weiß.
Die aktuelle DB ist wohl schon ca. 160GB groß - womit sich das dann wohl erledigt hat.

Aber man möchte doch die alten Posten / Stammdaten mitnehmen - wie stellt man das bei so einem Upgrade an? Muss man sich dann eine eigene Routine auf SQL Basis überlegen oder kann man das noch mit Microsoft Upgrade Mitteln handhaben?

Vermutlich scheitert es bei uns bereits an der SQL Server Lizenz: Wir haben "nur" eine SQL 2014 Runtime, und da darf die DB max. 80GB groß werden, soweit ich weiß.

Wenn das eine SQL-Runtime über sie NAV- Lizenz ist, dann hat die keine Größenbeschränkung.

Wenn du jetzt noch gesagt hättest, ob ihr Dimensionen benutzt, und wie lange Ihr ohne NAV könnt, hätte ich evtl. schon was sagen können

Aber bei der DB- Größe (wie groß ist der Datenteil und das LOG, und wie voll ist das LOG ?) wird für eine vertretbare Downtime wohl ein stark angepasstes Update zum Einsatz kommen müssen.

Gruß Fiddi

Wenn du jetzt noch gesagt hättest, ob ihr Dimensionen benutzt, und wie lange Ihr ohne NAV könnt, hätte ich evtl. schon was sagen können
Aber bei der DB- Größe (wie groß ist der Datenteil und das LOG, und wie voll ist das LOG ?) wird für eine vertretbare Downtime wohl ein stark angepasstes Update zum Einsatz kommen müssen.

Gruß Fiddi

Also Dimensionen werden sogar sehr exzessiv genutzt. Das Log darf wohl max. 45GB groß sein, die aktuelle Größe kann ich z.Z. nicht einsehen.
Verzichten können wir im Prinzip gar nicht aufs NAV, wobei das "Migrationskonzept" noch nicht wirklich existiert und ich im Moment nur etwas recherchiere und herum probiere.

Das Log darf wohl max. 45GB groß sein

Das wird für das Update wohl nicht reichen, da muss mehr Platz her. Und das Update wird wohl länger dauern (>1Tag).

Gruß Fiddi

So ein Upgrade macht man nur am Wochenende, am besten an einem Feiertagswochenende... Aufgrund der geänderten Dimensionsspeicherlogik wird die Datenbank hinterher kleiner sein, eine geile Sache. Wir haben eine DB mit ca. 40 GB von NAV 5.0 nach NAV 2013 R2 migriert. Die Laufzeiten sind natürlich auch abhängig von der verwendeten Hardware usw.

Wir sind dabei nach der "Anleitung" von Microsoft vorgegangen.
(http://msdn.microsoft.com/en-us/library ... 8(v=nav.71).aspx)

Die Schritte mit längerer Laufzeit waren:
in NAV 2013
Step 1 Task 4 - NAV 2013 Entwicklungsumgebung, Datenbank öffnen & konvertieren
ca. 3-3,5 Std.
in NAV 2013 R2
Step 2 Task 11 - Page 104002 -> Run -> Test Database Connection -> Transfer Data - also der Datenkonvertierungslauf in NAV 2013 R2
ca. 1 Std.

Es dauert einige Zeit bis nach den Jobs der Mandant bzw. die Datenbank zur Verfügung steht, was aber nicht dokumentiert ist. Im Hintergrund läuft wohl eine SQL-Datenbank-Reorganisation oder ähnliches. Das Starten der Page und damit des Windows Clients wird also ggf. nicht funktionieren. Auf keinen Fall sollte man an dieser Stelle irgendwas abbrechen.
Wartezeit ca. 1 bis 1,5 Std.

M. E. sollten dann die weiteren Schritte nach NAV 2015 und NAV 2016 keine längeren Laufzeiten verursachen.

Im Hinterkopf habe ich noch irgendwas von "RapidStart" in Bezug auf die Datenmigration.

RapidStart hat damit nix zu tun, damit würde man Daten aus anderen Vorsystemen importieren, z. B. aus Excel Dateien.

Hallo,

Zeiten für ein Update von 2009CC nach 2013+ kann man nicht wirklich vorhersagen.
Bei intensiv genutzten Dimensionen, habe ich bei einer ähnlich großen DB (ca. 30GB) das Update allein der Dimensionen nach 20 Stunden abgebrochen. Nach ein paar Anpassungen war das ganze Update inklusive Dimensionen nach 4 Stunden durch.

Gruß Fiddi

Wir sind dabei nach der "Anleitung" von Microsoft vorgegangen.
(http://msdn.microsoft.com/en-us/library ... 8(v=nav.71).aspx)

Sind das die gleichen Anleitungen wie von mir oben genannt? Der Link ließ sich leider nicht öffnen.

Die Schritte mit längerer Laufzeit waren:
in NAV 2013
Step 1 Task 4 - NAV 2013 Entwicklungsumgebung, Datenbank öffnen & konvertieren
ca. 3-3,5 Std.
in NAV 2013 R2
Step 2 Task 11 - Page 104002 -> Run -> Test Database Connection -> Transfer Data - also der Datenkonvertierungslauf in NAV 2013 R2
ca. 1 Std.

Damit habe ich doch schon einmal eine ziemlich genaue Vorstellung. Vielen Dank dafür.

Im Hinterkopf habe ich noch irgendwas von "RapidStart" in Bezug auf die Datenmigration.

RapidStart hat damit nix zu tun, damit würde man Daten aus anderen Vorsystemen importieren, z. B. aus Excel Dateien.

Von RapidStart habe ich bisher nur kurz gelesen, mich aber noch nicht wirklich eingearbeitet. Es empfiehlt sich also eher nicht eine NAV Datenmigration anhand dieser Methode durch zu führen?

Nach ein paar Anpassungen war das ganze Update inklusive Dimensionen nach 4 Stunden durch.

Was für Anpassungen waren das denn beispielsweise?

Beste Grüße,
Thomas

Wir sind dabei nach der "Anleitung" von Microsoft vorgegangen.
(http://msdn.microsoft.com/en-us/library ... 8(v=nav.71).aspx)

Sind das die gleichen Anleitungen wie von mir oben genannt? Der Link ließ sich leider nicht öffnen.

Mit url-Tags schon, diese bitte auch benutzen. Darauf habe ich mehrfach schon hingewiesen.
http://msdn.microsoft.com/en-us/library/dn271668(v=nav.71).aspx

Was für Anpassungen waren das denn beispielsweise?

einiges

zum einen habe ich eine Großen Teil des Updates per SQL-Skript gemacht, weil das nun mal um Größenordnungen schneller ist als C/AL
Zum andren habe ich den Dimensionsupdate ein wenig optimiert, was man sich aber von Fall zu Fall anschauen muss.

Gruß Fiddi

Mit url-Tags schon, diese bitte auch benutzen. Darauf habe ich mehrfach schon hingewiesen.
http://msdn.microsoft.com/en-us/library/dn271668(v=nav.71).aspx

Ich schreibe reinen Text. Die Forumssoftware zerhäckselt das dann. Da kann ich nix für, bzw. ich weiß nicht wie ich das verhindern soll.

Na eben indem du den Link in solche Tags einschließt: [url][/url]

Die Forumssoftware zerhäckselt das dann.

Das sind in diesem Fall die Klammern in den URLs. Das sind reservierte Zeichen, die früher durch %-Darstellungen ersetzt wurden, mittlerweile aber nicht mehr. Deswegen geht es hier nicht ohne die url-Tags.
https://de.wikipedia.org/wiki/URL-Encoding
Nur bei einfachen Links ohne reservierte Zeichen kann man auf die url-Tags verzichten (der Wikilink hat auch keine), das sieht man den Link dann aber sofort an, weil der komplett in blauer Schrift und, falls etwas länger, mit Auslassungspunktem erscheint wie z.B. dieser hier:
http://wetterstationen.meteomedia.de/?s ... vorhersage

Nach Rücksprache mit einem Entwickler unseres Solution Centers wird wohl der Migrationspfad für uns nicht in Frage kommen.
Dies liegt darin, dass wir auch die Standardobjekte angepasst haben und bei der Migration u.U. Probleme mit den Feldinhalten bekommen würden und jede neue Version erst mit unseren Objekten mergen müssten.
Daher werden wir den Weg des Rapid Starts nutzen.

Dies liegt darin, dass wir auch die Standardobjekte angepasst haben und bei der Migration u.U. Probleme mit den Feldinhalten bekommen würden und jede neue Version erst mit unseren Objekten mergen müssten.

Das ist doch eigentlich normal, dass man zusätzliche Felder in die Stammdaten oder Posten eingebaut hat. Wenn man eine saubere Versionshistorie pflegt, ist das auch kein riesiger Aufwand, es sei denn ihr wollt die ganzen Anpassungen nicht mehr einsetzen!!???

Daher werden wir den Weg des Rapid Starts nutzen.

D.h. dann aber auch, Ihr wollt keine Historie übernehmen. Denn bei 160 GB Datenbankgröße, dürften die Postentabellen Rapidstart zur Verzweiflung bringen.

Gruß Fiddi

Das ist doch eigentlich normal, dass man zusätzliche Felder in die Stammdaten oder Posten eingebaut hat. Wenn man eine saubere Versionshistorie pflegt, ist das auch kein riesiger Aufwand, es sei denn ihr wollt die ganzen Anpassungen nicht mehr einsetzen!!???

Soweit mir bekannt sollen u.a. Sachposten mitgenommen werden. Aber mir wurde von unserem Partner gesagt, dass das wohl bei uns kaum möglich sei, die DB vernünftig zu migrieren.
Wir haben eine aktuelle DB (NAV 2009R2 - nicht RTC). Das Projekt ist so geplant, dass unser Partner auf Basis seiner Branchenlösung unsere Strukturen und Prozesse nachbaut/einbindet.
Es wird zukünftig also Felder geben, welche es vorher nicht gab. Manche Info's sind wiederum in ganz anderen Tabellen und auch in anderen Strukturen (wegen der Branchenlösung) abgebildet

Manche Info's sind wiederum in ganz anderen Tabellen und auch in anderen Strukturen (wegen der Branchenlösung) abgebildet

OK, dann macht das wahrscheinlich Sinn, zumindest zum Teil, mit Rapidstart zu arbeiten. Aber nahezu alle Bewegungsdaten zu verlieren, ist dann schon ein schwerer Schlag.

Gruß Fiddi

Was für Anpassungen waren das denn beispielsweise?

einiges

zum einen habe ich eine Großen Teil des Updates per SQL-Skript gemacht, weil das nun mal um Größenordnungen schneller ist als C/AL
Zum andren habe ich den Dimensionsupdate ein wenig optimiert, was man sich aber von Fall zu Fall anschauen muss.

Gruß Fiddi

Hi Fiddi,
ich würde mich schon für deine 'Arbeit' interessieren.
Habe ich eine Möglichkeit die zu erwerben?
Wir benutzen die Dimensionen auch sehr intensiv, DB 120GB ...
Möchten 2009R2 auf 2013 upgraden.