Migration von Version 2.0 auf 2009R2

Hallo Zusammen,

hat jemand Erfahrung damit die uralt-Version Navision 2.0 auf NAV2009R2 zu migrieren ?
- Welcher Migrationspfad ist zu empfehlen ?
- Wie kommt man an die uralten Upgrade Toolkits ? (In der MS Partnersource gibt es zwar ein "Database and Upgrade Toolkit Archive", aber die Cronus-Datenbanken fangen erst bei Version 2.60 an und die Upgrade Toolkits erst ab Version 4.0 SP3)
- Mit welchem Aufwand ist hierbei zu rechnen (z.B. im Vergleich zu einer Migration von Version 4.0 auf Version 2009R2)
- Wie problematisch/aufwändig ist hierbei die Umstellung auf Multi-Language

Vielen Dank für Eure Hinweise/Erfahrungen !

Grüße, Blue

Hallo,

wie groß ist die Datenbank? und wieviel Historie MUSS ZWINGEND übernommen werden.

Eigentlich kann man nur den Rat geben auf NAV 2013 umzusteigen, und die Daten mit den RIM- Tookit zu importieren.

Alles andere macht nur Sinn, wenn der Kunde mit einem Erschießungskommando droht .

Gruß, Fiddi

Hallo fiddi,

es geht um einen sehr kleinen Kunden mit 4 Usern und einer ca. 1GB-Datenbank, bei dem der Migrationsaufwand die absolut dominierende Rolle spielt (daher zunächst die Migration auf NAV2009R2 Native).
Habe gerade gesehen, dass im Upgrade Toolkit von Version 4.0 auch bereits die Migration von Navision Financials 2.00 behandelt wird, also würde sich ja vermutlich folgender Migrationspfad empfehlen:
2.00 --> 4.0SP3 --> 2009R2

Der Schritt von 2.00 --> 4.0SP3 ist für mich dabei der unbekanntere und deutlich schwieriger einzuschätzender. Hmm, muss mir vermutlich das 150seitige Toolkit-Handbuch von Version 4.0 hierzu genauer ansehen.
Bin für Einschätzungen/Hinweise hierzu von Leuten, die das schon mal gemacht haben auf jeden Fall dankbar!

Grüße, Blue

Ist in der 2.0er Db die Impuls- Lagerrgulierung enthalten oder macht der nur Buchhaltung ohne Kostenstellen u.ä.?

Grußß, Fiddi

@fiddi: Das kläre ich zur sicherheit nochmal genauer ab.

Gruß, Blue

Hallo,

wie groß ist die Datenbank? und wieviel Historie MUSS ZWINGEND übernommen werden.

Eigentlich kann man nur den Rat geben auf NAV 2013 umzusteigen, und die Daten mit den RIM- Tookit zu importieren.

Alles andere macht nur Sinn, wenn der Kunde mit einem Erschießungskommando droht .

Gruß, Fiddi

Bei einem so großen Sprung würde ich das persönlich auch empfehlen.

Ist in der 2.0er Db die Impuls- Lagerrgulierung enthalten oder macht der nur Buchhaltung ohne Kostenstellen u.ä.?

Grußß, Fiddi

--> Der Kunde hat die Lagerregulierung NICHT im Einsatz und auch keine Kostenrechnung. Im Wesentlichen setzt er FiBu, Auftragsabwicklung, Lager (ohne Übergabe an FiBu) ein.

Der Kunde hat die Lagerregulierung NICHT im Einsatz

Ob er sie eingesetzt hat oder nicht, ist hier nicht die Frage. Ist die Impulsregulierung eingebaut, kannst du die Artikelposten nicht mehr mit dem UGT migrieren, weil das Format sich geändert wurde und die Feldinhalte anders genutzt werden.
Soviel ich weiß gibt es dafür auch keine Update-Möglichkeit.

Gruß, Fiddi

@fiddi: Also ich habe keine solchen Objekte in der Kunden-DB gefunden. Wo würden sie denn liegen bzw. wie würden sie heissen?

Der Kunde ist übrigens nicht sehr stark angepasst. Er hat nur ca. 100 geänderte Standardobjekte und ca. 30 Individualobjekte.

Grüße, Blue

ich stehe vor demselben Problem ...
Aufgrund massiver Eingriffe in den Standard und einem nicht unerheblichen Anteil an Eigenentwicklung machen wir nur ein technisches Update...
d.h.:
du nutzt den SQL und 2009R2 als Software, behälst aber deinen kompletten Ablauf und Look@Feel aus der 2.00er Version ....

Also ich habe keine solchen Objekte in der Kunden-DB gefunden

wenn ich das richtig weiß, haben die betroffenen Objekte die Versionskennung "iLW"

Gruß, Fiddi

Also ich habe keine solchen Objekte in der Kunden-DB gefunden

wenn ich das richtig weiß, haben die betroffenen Objekte die Versionskennung "iLW"

Gruß, Fiddi

@fiddi: Dann habe ich wohl Glück gehabt. In der 2.0er-DB sind keine Objekte der impuls-Lagerregulierung.
@h-d.neuenfeld: Dann lässt sich allerdings auch keine Funktionalität aus neueren Versionen nutzen. Über kurz oder lang kommt man also nicht drum herum.

Hallo,

ich habe das vor ein paar Jahren mal für einen Kunden machen dürfen/müssen - damals war das allerdings eine Migration von Financials 2.01 auf NAV2009 (R2 gab's damals noch nicht).

Unser Kunde verwendete in der Financials-Datenbank keine Addons - hatte aber etliche angepasste Objekte .
Wir haben dann für die Migration von Financials 2.01 auf NAV 4.0 zunächst eine 4.0-Standarddatenbank verwendet und dort in alle angepassten und zusätzlichen Tabellen / Felder hinzugefügt, damit (fast) alle Daten aus Financials zu NAV 4.0 migriert werden konnten.
Die angepassten Programmlogiken aus Financials haben wir dann erst in der NAV2009-Datenbank nachprogrammiert, sofern dies erforderlich war.

Gruß
Jörg

du nutzt den SQL und 2009R2 als Software, behälst aber deinen kompletten Ablauf und Look@Feel aus der 2.00er Version ....

Warum sollte man das machen? Wozu macht man dann überhaupt ein Update? Beschwert sich der Kunde nicht, daß die ganzen Update- und Supportgebühren quasi für die Katz sind?

Generell würde ich über eine Neueinführung nachdenken und die Daten migrieren. So könnte man auch gleichzeitig über eine Restandardisierung und eine Prozeßoptimierung nachdenken. Der normale, dreistufige Updatepfad macht aus meiner Sicht im Verhältnis zum Aufwand keinen Sinn.

Generell würde ich über eine Neueinführung nachdenken und die Daten migrieren. So könnte man auch gleichzeitig über eine Restandardisierung und eine Prozeßoptimierung nachdenken. Der normale, dreistufige Updatepfad macht aus meiner Sicht im Verhältnis zum Aufwand keinen Sinn.

Und man könnte auch direkt einfach auf NAV 2013 neu einführen.

Das meinte ich ja. Deshalb dreistufig: 2.00 -> 4.00 -> 2009 -> 2013

Warum sollte man das machen? Wozu macht man dann überhaupt ein Update? Beschwert sich der Kunde nicht, dass die ganzen Update- und Supportgebühren quasi für die Katz sind?

Nennt sich technisches Update ..
Beschleunigt die Datenverarbeitung ..
Wir sind in diesem Fall unser eigener Kunde
Grundstein unseres Systems ist Navision 1.20 bzw 1.30 gewesen und was man als Betrieb damals noch so brauchte ist Eigenprogrammierung

Ich weiß, was ein technisches Update ist. Nur macht es keinen Sinn bei so einem großen Unterschied zwischen Applikationsversion und Programmversion.

Es gibt genug Beiträge im Internet zum Thema Performance, wenn man rein ein technisches Update ausführt. In einigen Fällen ist es schneller geworden, in anderen langsamer. Man kann also nicht generell sagen, daß ein technisches Update die Geschwindigkeit verbessert. Das hängt von der einzelnen Lösung ab. Und da man es vorher nicht weiß, würde ich keinem Kunden raten das einfach zu machen, wenn das einzige Ziel ist, daß die Performance nach oben geht. Was sagt man denn dann dem Kunden, wenn sie nach unten gehen sollte? Das ist auf keinen Fall zu vertreten.

Wenn es bei euch funktioniert, dann ist das gut für euch, aber daraus kann man keine generelle Vorgehensweise ableiten.

Außerdem reden wir hier über ein Update bis auf 2013. Da gibt es keine native Datenbank mehr, ergo braucht man (mindestens) die SQL-Optimierung, die, wenn ich mich richtig erinnere, mit 4.03 eingeführt wurde.

Bei einem Datenbänkchen von 1 GB und wenig Anpassungen ist der Weg über NAV 4 SP3 -> 2009 R2 -> SQL kein all zu großes Problem mit den Upgrade Toolkits. Der letzte Schritt ist wegen der Reports und Pages aufwändiger aber machbar. Ich habe sogar schon mehrfach die blaue Version auf 2013 hochgezogen, wobei alle Daten erhalten geblieben sind.

Der Kunde wollte es so, und er hat es so bekommen. Ob ich es selbst auch so gemacht hätte lassen wir mal dahin gestellt.

Eine kleine Rückmeldung hierzu:

Die Migration über die Upgrade-Toolkits von 2.0 bis 2009R2 hat bei diesem Kunden recht gut funktioniert.
Dies lag im Wesentlichen daran, dass der Kunde wenige Individualanpassungen hatte.
Individualanpassungen können bei diesem grossen Schritt nämlich nicht über ein Textvergleichstool gemergt werden sondern müssen manuell nachvollzogen werden.

Grüße, Blue