Ist ein technisches Update von 3.70 auf 2009 R2 CC möglich?

Hallo,

Ich wurde gefragt, ob ein rein technisches Update (nur Objektstand) von NAV 3.70B auf NAV 2009 R2 CC möglich ist?
Die 3.70B ist schon ein technisches Update von 2.60F.

Ich erinnere mich dunkel, dass es früher hiess, dass ein technisches Update nur vom Client und den Objekten nur möglich ist bis NAV 2009 ohne SP.
NAV 2009 R2 erforderte doch mindestens NAV 2009 SP1?

Andererseits lese ich von einem erfolgreichen techn. Update von 4.03 auf 2009 R2:
viewtopic.php?f=40&t=15298&p=75268&hilit=Technisches+Update#p75268

Ich kann mir das nicht vorstellen, dass ein rein technisches Update von 3.70 (Hintergrund 2.60F) auf 2009 R2 klappt, da man früher z.B. keine Wertposten kannte?

Für mich ist das ein komplettes Migrationsprojekt, wo die Stamm- und Bewegungsdaten per Dataports aus dem alten 3.70 exportiert und in das neue 2009 R2 importiert werden müssen?

Für eine Antwort danke ich im Voraus!

Hallo,

Ich wurde gefragt, ob ein rein technisches Update (nur Objektstand) von NAV 3.70B auf NAV 2009 R2 CC möglich ist?
Die 3.70B ist schon ein technisches Update von 2.60F.

Ich erinnere mich dunkel, dass es früher hiess, dass ein technisches Update nur vom Client und den Objekten nur möglich ist bis NAV 2009 ohne SP.
NAV 2009 R2 erforderte doch mindestens NAV 2009 SP1?

Andererseits lese ich von einem erfolgreichen techn. Update von 4.03 auf 2009 R2:
viewtopic.php?f=40&t=15298&p=75268&hilit=Technisches+Update#p75268

Ich kann mir das nicht vorstellen, dass ein rein technisches Update von 3.70 (Hintergrund 2.60F) auf 2009 R2 klappt, da man früher z.B. keine Wertposten kannte?

Für mich ist das ein komplettes Migrationsprojekt, wo die Stamm- und Bewegungsdaten per Dataports aus dem alten 3.70 exportiert und in das neue 2009 R2 importiert werden müssen?

Für eine Antwort danke ich im Voraus!

Offiziell ist es nicht unterstützt, richtig. Ich habe auch schon von Problemen gehört. Das liegt unter anderem daran, dass der Client Funktionen z.B. aus der CU 1 aufruft.

Ich würde an deiner Stelle ein Upgrade ohne Bewegungsdaten, sondern nur mit Stammdaten durchführen.

Hallo,

zunächst sollten wir mal klären was ein technisches Update ist.

Hier im Forum sprechen wir von einem technischen Update, wenn wir die technische Umgebung ändern wollen, d.h. wir wollen jetzt den NAV2009-Client /Server statt der alten 3.70- Clients/Server verwenden, ändern aber nichts an Daten und Objekten (zumindest fasst nichts )
Ein vollständiges Update ist der Austausch sowohl von technischer Umgebung (also 3.70->2009) und der Update der Objekte und damit auch die Konvertierung der Daten.

Es gibt nur diese beiden Möglichkeiten.
Ein Update von 3.70 nach 2009 nur mit technischer Umgebung und Objekten ist nicht möglich, das geht auch von 2.60 nach 3.70 nicht (zumindest dann nicht, wenn man die NAV- Standard- Datenbanken als Basis nimmt. Sollte das tatsächlich mal so durchgeführt worden sein, war das nicht wirklich ein Update auf die neue Version, bzw. keine NAV- Standard- DB, oder beides )

Welche Probleme auf dich bei einem rein technischen Update zukommen, findest z.B. hier.

Gruß, Fiddi

Ich verstehe das jetzt so, daß es sich damit eigentlich um ein technisches Update von 2.60F auf 2009 R2 handelt. Der Kunde hatte nur zwischenzeitlich schon ein technisches Update auf 3.70B gemacht. Wurde in dem Zusammenhang dann auch schon auf SQL migriert oder soll das jetzt im Zuge von 2009 R2 geschehen? Für den Fall solltet ihr auch die Objekte updaten, denn hier hat sich einiges getan, gerade auch im Bezug auf Performance.

Aber ehrlich gesagt, bei einer derart alten Objektbasis würde ich gar nicht mehr unbedingt über ein Update nachdenken. Ich gehe jetzt mal davon aus, daß es sicher hier um eine Datenbank mit sehr vielen individuellen Änderungen handelt und daher bisher das echte Update "gescheut" wurde. Diese Anpassungen auf Basis der Technologie von 2.60F mit hochzuziehen auf 2009 R2 ist aus meiner Sicht kompletter Unfug. Dabei ist es schon fast egal, was das für Änderungen sind.

Folgende Gedankenspiele einfach mal wirken lassen und mitmachen:
1. Die in 2.60F abgebildeten Prozesse der Firma sind mittlerweile über zehn Jahre alt. Die Firma wird sich doch auch weiterentwickelt haben. Stimmen die Prozesse noch? Gibt es weitere oder neue Optimierungsmöglichkeiten?
2. Inwieweit gibt es heute auf Basis der Objekte in 2009 R2 Lösungen/Lösungsansätze für die Individualprogrammierung aus 2.60F? Gap/Fit-Analyse? Gegenüberstellung von Kosten/Aufwand/Nutzen?
3. Was ist eigentlich der Anlaß für das Update? Wo ist der Bedarf und welche technischen Möglichkeiten gibt es die Probleme zu lösen mit 2.60F-Technologie und mit 2009R2-Technologie? Wie steht das Unternehmen generell zu neuer Technologie? Sind für die Zukunft weitere Maßnahmen geplant/notwendig? Was sagen die MA, nicht nur der Vorstand?
4. Wie sieht es um die Datenqualität aus? Inwieweit benötigen die Stammdaten eine Überarbeitung? Inwieweit benötigen die Prozesse, die zur Erstellung von Bewegungsdaten führen, eine verbesserte Kontrolle?
...
Eine komplette Neuimplementierung inkl. aller erforderlichen Analysen und Prozeßmodellierungen wäre hier u.U. die bessere Wahl.

Meiner Meinung nach ist ein technisches Update von 2.60F auf 2009 R2 technisch sicherlich möglich (mit kleineren Schwierigkeiten wie oben genannt), aber inhaltlich macht es einfach keinen Sinn. Wenn man unbedingt 2009R2-Technologie braucht oder möchte, dann auch mit dem entsprechenden Unterbau.

Hi,

aus der praktischen Erfahrung heraus: 2.60-Objekte funktionieren auch mit einer 2009R2-DB (Native). Die Geschäftslogik ist halt die alte, im Menü findet man noch was, usw. Wenn es um eine Migration auf einen SQL Server geht, muss man sich die Objekte recht genau anschauen und evtl. Perfomancebremsen entfernen. Aber auch das geht.

LG Jens

Hallo,

mir ist das hier zum Teil zu einfach gedacht. Es gibt einige gute Gründe, warum ein Kunde sich entscheiden könnte, nur technisch auf dem Laufenden zu bleiben und die Applikation außen vor zu lassen. Natürlich ist ein komplettes Update sinnvoll, wenn man Budget, Anpassungsgrad, Migrationsaufwand etc. außer Acht lassen kann, aber das geht nicht immer. Vor allem das Budget schiebt hier oft einen Riegel vor. Wenn man dann z.B. aufgrund von Kompatiblität mit Betriebssystem oder SQL-Server gezwungen ist, nach Lösungen zu suchen, dann zieht man ein rein technisches Upgrade schnell in Betracht.

Zum eigentlichen Problem: oben wurde bereits erwähnt, dass sich das Verhalten in einigen Bereichen ändern wird. Hier noch ein weiterer Link dazu: MSDN
Wir selbst sind bzgl. unserer Applikation auf 3.01B, technisch aber bereits auf 2009R2 und nutzen auch die neuen Möglichkeiten bereits (z.B. Webservices). Ich muss aber zugeben, dass wir von 3.01B zunächst auf 4.03 und dann auf 2009R2 gegangen sind. Insofern weiß ich nicht, ob ein direkter Sprung möglich wäre, gehe aber davon aus.

Bei uns war seither übrigens der Anpassungsgrad und der Migratiosnaufwand die Hemmschwelle über ein "echtes" Update nachzudenken (bei 300GB kann man sich über eine Migration nur bedingt Gedanken machen). Mit NAV2013 wird aber alles anders.....

Gruß
Meik

Keiner hat gesagt, daß das eine einfache Entscheidung ist. Und keiner hat gesagt, daß es überhaupt keine Schwierigkeiten bei einem echten Update geben wird. Und schon gar keiner hat gesagt, daß ein eches Update nicht mit Aufwand (finanziell und zeitlich) verbunden sein wird, erst recht nicht bei einer derart alten Codebasis.

Aus meiner Sicht gibt es nur wenige Gründe, warum man das echte Update so lange hinausgezögert hat. Die zwei größten sind vielleicht Angst und die Kosten, was man ja immer wieder hört. Angst, daß etwas nicht mehr funktioniert, resultiert meistens aus einem hohen Individualisierungsgrad. Hohe Kosten resultieren meistens aus einem hohen Individualisierungsgrad. Aber warum zahlt man dann Wartungs- und Supportgebühren? Oder wenn man sie nicht zahlt, warum hat man dann nicht für eine Aktualisierung der ERP-Landschaft eine Reserve zurückgelegt? Ich meine, was hat man denn geglaubt, wie lang der Lebenszyklus einer solchen Software sein soll? Ich meine, das hört sich jetzt vielleicht extrem an, aber wenn man es auf Essenz herunterbricht, dann spricht ein hoher Individualisierungsgrad und zu hohe Kosten für ein ERP-Update meistens für eine schlechte Beratung und/oder schlechtes Management.

Keiner hat gesagt, daß das eine einfache Entscheidung ist. Und keiner hat gesagt, daß es überhaupt keine Schwierigkeiten bei einem echten Update geben wird. Und schon gar keiner hat gesagt, daß ein eches Update nicht mit Aufwand (finanziell und zeitlich) verbunden sein wird, erst recht nicht bei einer derart alten Codebasis.

Aus meiner Sicht gibt es nur wenige Gründe, warum man das echte Update so lange hinausgezögert hat. Die zwei größten sind vielleicht Angst und die Kosten, was man ja immer wieder hört. Angst, daß etwas nicht mehr funktioniert, resultiert meistens aus einem hohen Individualisierungsgrad. Hohe Kosten resultieren meistens aus einem hohen Individualisierungsgrad. Aber warum zahlt man dann Wartungs- und Supportgebühren? Oder wenn man sie nicht zahlt, warum hat man dann nicht für eine Aktualisierung der ERP-Landschaft eine Reserve zurückgelegt? Ich meine, was hat man denn geglaubt, wie lang der Lebenszyklus einer solchen Software sein soll? Ich meine, das hört sich jetzt vielleicht extrem an, aber wenn man es auf Essenz herunterbricht, dann spricht ein hoher Individualisierungsgrad und zu hohe Kosten für ein ERP-Update meistens für eine schlechte Beratung und/oder schlechtes Management.

Ein ERP-System an Geschäftsprozesse anzugleichen (egal wie altbacken/kompilizert diese Geschäftsprozesse sind) bringt mehr Beratungs-/Entwicklungs-/Supportzeit zum Abrechnen.
Ich kenne Personen, die ändern Geschäftsprozesse (leicht) ab, um näher am ERP-Standard zu bleiben. Die sind auf lange Sicht die Gewinner mit der Strategie.
Man sollte schon so mit einem Zyklus von ca. 4-5 Jahren ein Update in Betracht ziehen. Insb. wenn es neue gesetzliche Anforderungen gibt, die nicht so einfach in uralt-Objektstände gemergt werden können. (VAT2010 ist da ein schönes Beispiel)

...
Eine komplette Neuimplementierung inkl. aller erforderlichen Analysen und Prozeßmodellierungen wäre hier u.U. die bessere Wahl.

Vielen Dank!

Das ist genau meine Meinung und ich werde das genauso vorschlagen

Budget ist kein Problem, wird genehmigt.

Individual angepasste Objekte auf 2.60F / 3.70B => im Objektdesigner zähle ich 160 Objekte, verteilt quer beet über Forms, Reports, Tabellen und Codeunits.
Es werden nur Fibu, Einkauf, Verkauf rudimentär genutzt.
Es gibt eine selbstgestrickte Projektkostenrechnung.

Mein Plan ist eine komplette Neuimplementierung vorzuschlagen, da die Anzahl der angepassten Objekte niedrig ist und die Keyuser bisher das System als eine bessere Schreibmaschine nutzen.

Ein ERP-System an Geschäftsprozesse anzugleichen (egal wie altbacken/kompilizert diese Geschäftsprozesse sind) bringt mehr Beratungs-/Entwicklungs-/Supportzeit zum Abrechnen.

Das stimmt. Leider haben immer noch viel zu viele Solution Center nur die Dollarzeichen in den Augen, anstatt das beste für den Kunden herauszuholen.

Ich kenne Personen, die ändern Geschäftsprozesse (leicht) ab, um näher am ERP-Standard zu bleiben. Die sind auf lange Sicht die Gewinner mit der Strategie.
Man sollte schon so mit einem Zyklus von ca. 4-5 Jahren ein Update in Betracht ziehen. Insb. wenn es neue gesetzliche Anforderungen gibt, die nicht so einfach in uralt-Objektstände gemergt werden können. (VAT2010 ist da ein schönes Beispiel)

Genau das meinte ich.

Budget ist kein Problem, wird genehmigt.

Individual angepasste Objekte auf 2.60F / 3.70B => im Objektdesigner zähle ich 160 Objekte, verteilt quer beet über Forms, Reports, Tabellen und Codeunits.
Es werden nur Fibu, Einkauf, Verkauf rudimentär genutzt.
...
Mein Plan ist eine komplette Neuimplementierung vorzuschlagen, da die Anzahl der angepassten Objekte niedrig ist und die Keyuser bisher das System als eine bessere Schreibmaschine nutzen.

In dem Fall verstehe ich überhaupt nicht, wie man auf die Idee kommen kann, so lange kein Update zu fahren. Der Aufwand und die Kosten sind doch sehr überschaubar. Ich meine, da sind doch dann die Wartungs- und Supportgebühren über zehn Jahre im Sand verlaufen.

Es gibt eine selbstgestrickte Projektkostenrechnung.

Ich weiß nicht, ob es in dem Fall möglich ist, kommt darauf an, was genau diese Projektkostenrechnung macht bzw. machen soll, aber ich habe mal ein solches Modul durch den Standard ersetzt (in NAV 2013 "nur noch" als AddOn von CKL), indem die Projektnr. als eigene Dimension eingeführt wurde.