Datenmigration(plus Umzug) von NAV2009 nach NAV2013

Hi zusammen,

Bei meinem Arbeitgeber wurde Navision über einen externe Dienstleister eingeführt (weil wir recht viele Indivisualprogrammierungen/Anpassungen brauchten und dazu über einen Dienstleister gegangen sind). Wir nutzen momentan die Version NAV2009. Es steht demnächst aber ein Upgrade auf NAV2013 an, dies soll auch der Dienstleister begleiten bzw. als Projekt bei uns durchführen. Er hat hierzu vorgeschlagen, dass eine noch ausstehende Anpassung (noch zu programmierendes Modul) in NAV2013 programmiert wird. Dieses Modul (in NAV2013) soll mit dem Altsystem (in NAV2009) eine zeitlang parallel laufen und miteinander synchronisiert werden. Die Synchronisation selber macht mir keine Kopfschmerzen, aber das was er danach vorhat:
Es soll dann in den darauffolgenden Jahren der Datenbestand (also einzelne Module/Datensätze) aus dem Altsystem (aus NAV2009) stückweise nach NAV2013 migriert/umgezogen werden - und da fängt bei mir das Unverständnis an. Ich komme zwar nicht aus dem Bereich der SQL-Programmierung/Datenbanken, aber mein Verständnis von der Thematik geht trotzdem noch soweit, dass ich weiß, dass es Primärschlüssel gibt in Tabellen und es zu Schlüsselverletzungen kommen könnte, wenn man Datensätze von einem Standardsystem in ein anderes System versucht einzufügen/ergänzen, oder seh ich das falsch?
Von einem Komplettupgrade auf NAV2013 des Altsystems wurde uns abgeraten, da wir zuviele Individualanpassungen hätten (und uns vom Standard schon sehr weit entfernt haben) - ist sowas ein Argument???

Wie klingt das für euch? Versucht uns der Dienstleister einen Bären aufzubinden oder stimmt der Rat - wobei ich kann mir das beim besten Willen nicht vorstellen, dass eine Synchronisation zwischen zwei NAV-System, plus anschließendem Datenumzug weniger Risiken hat als ein Komplettupgrade auf NAV2013?!

Danke für den Rat!
VG, Marion

Hallo Marion,

eine Frage vorab: Benutzt ihr NAV2009 mit dem Classic Client? Wenn ja, dann kann ich das zögern des Partners etwas verstehen. Dieser stückweise Umzug der Datenbank ist ungewöhnlich und (je nach komplexität eurer Lösung) mindestens gefährlich (für die Datenintegrität und Funktion des Gesamtkonstrukts) bis nahezu unmöglich. Die Argumentation des Partners bezüglich der Individualanpassungen lässt darauf schliesen das ihr wahrscheinlich noch den Classic Client benutzt. Dann ist der Umstieg auf NAV2013 mit der Einführung eines neuen ERP vergleichbar, da sich die Oberfläche und die Bedienwege sehr stark voneinander unterscheiden. Hinzu kommt, das die darunterliegende Technologie "anders" ist, mit anderen Möglichkeiten der Programmierung - und vieles von dem was man im Classic Client machen konnte geht im NAV2013 nicht mehr, und muss völlig anders gelöst werden.
Für die meisten praktischen Szenarien würde ich sagen, ein stückweiser Umstieg auf NAV2013 geht nicht. Ein Komplettupgrade ist sehr aufwendig, besser ist es man nutzt die Gelegenheit für einen Neuentwurf der auf die Bedienlogik von NAV2013 zugeschnitten wird. Die dann im Raum stehenden Kosten lassen aber für gewöhnlich jeden nüchtern rechnenden Unternehmer den Kopf schütteln und sich nach strategischen Alternativen umsehen.

LG Jens

Hallo,

ich kann Jens da (leider) nur zustimmen. Es gibt aber nicht wirklich eine Alternative dazu.

Den schrittweisen Umstieg hätte man in NAV 2009 noch sinnvoll durchführen können. (Abteilungsweise von CC auf RTC umziehen).
Für den Umstieg auf 2013 sollte man allerdings den von Jens schon skizzierten Weg, entweder alles oder nichts, gehen.
Bei der Umstellung auf NAV 2013 ist im wesentlichen das Reporting ein Problem, da die Reports des CC in NAV 2013 neu geschrieben oder zumindest konvertiert werden müssen. Ein erfahrener Parter hat aber gerade für die aufwendigen Belege Volragen.
Habt Ihr viele eigene Forms gebaut ist auch das Aufwand, aber eigentlich nur eine Fleissarbeit.
Geschäftslogik sollte man im wesentlichen übernehmen können.
Ein letzter u.U. aufwändiger Teil ist die Konvertierung von Addons, die u.U. auf .Net konvertiert müssen und der Umgang mit zu verarbeitenden Dateien, die vom Client auf den Servicetier oder zurück übertragen werden müssen.

Gruß, Fiddi

Hi Jens,

Vielen Dank für deine Antwort! Ich muss sagen, das entmutigt mich jetzt leider etwas (sehr) - ich hatte mir die Upgrade-Prozesse auf der MS-seite angeschaut und das schien mir nicht so schwer zu sein bzw. recht "straight forward" (und hatte die Hoffnung der Dienstleister bindet uns nur einen Bären auf und dass das Ganze so einfacher als er es uns verkauft)

Hallo Marion,
eine Frage vorab: Benutzt ihr NAV2009 mit dem Classic Client? Wenn ja, dann kann ich das zögern des Partners etwas verstehen.

Ja, wir benutzen den Classic Client (mit Forms).

Dieser stückweise Umzug der Datenbank ist ungewöhnlich und (je nach komplexität eurer Lösung) mindestens gefährlich (für die Datenintegrität und Funktion des Gesamtkonstrukts) bis nahezu unmöglich.

ja, das Gefühl hab ich auch, aber der Dienstleister meint es gäbe keine Probleme dabei (versuchte uns das Ganze als "normale" Vorgehensweise zu verkaufen)

Dann ist der Umstieg auf NAV2013 mit der Einführung eines neuen ERP vergleichbar, da sich die Oberfläche und die Bedienwege sehr stark voneinander unterscheiden. Hinzu kommt, das die darunterliegende Technologie "anders" ist, mit anderen Möglichkeiten der Programmierung - und vieles von dem was man im Classic Client machen konnte geht im NAV2013 nicht mehr, und muss völlig anders gelöst werden.
Für die meisten praktischen Szenarien würde ich sagen, ein stückweiser Umstieg auf NAV2013 geht nicht. Ein Komplettupgrade ist sehr aufwendig, besser ist es man nutzt die Gelegenheit für einen Neuentwurf der auf die Bedienlogik von NAV2013 zugeschnitten wird.

Jetzt bin ich echt ratlos! Es wurde schon sehr viel Geld in die momentane NAV-Lösung investiert. Pfffhhh, keine gute Aussichten ...

Ich dank dir für die vielen Infos!!! Ich wunder/ärger mich echt, wie Microsoft eine NAV-Version anbietet, die solche Probleme/Hürden bei einem Upgrade darstellt. Eine letzte Frage vielleicht: Wie würdest du hier weiter vorgehen?

LG, Marion

Hallo,

in einer Sache muss ich Jens allerdings widersprechen: Die Einführung von NAV 2013 ist nicht unbedingt mit der Einführung eines neuen ERP-Systems zu vergleichen.

Wer in NAV 2009 weiß was er tut, wird das auch in NAV 2013 bewerkstelligen. Es dauert ein bis zwei Tage sich mit den Möglichkeiten der neuen Oberfläche vertraut zu machen, die viele auch für sehr viel einfacher zu verstehen halten als den CC. Die Geschäftslogik und die Funktionen unterscheiden sich kaum vom NAV 2009 CC. Wer also einen Auftrag im CC erfassen und buchen kann, der wird das nach einer halben Stunde in NAV 2013 können, ohne dabei gravierende Fehler zu machen.

Was man lernen muss, sind die neuen Tastenkombinationen (die passen aber eher zu Windows, als die des CC), und die neue Oberfläche mit den Übersichten, Menübändern und der neuen Eingabeform(en) für Filter.

Gruß, Fiddi

Hallo Marion,

Eine letzte Frage vielleicht: Wie würdest du hier weiter vorgehen?

Gute Frage. Ich würde mich intensiv mit NAV2013 (R2) beschäftigen, eine Testinstallation aufsetzen (lassen) und die Anwendung auf die fürs Unternehmen wichtigen Bereiche austesten, ggf. auch mit den Keyusern der Fachabteilungen zusammen (*). Wenn ihr NAV-Entwickler im Haus habt würde ich mir auch die Designmöglichkeiten anschauen, und die Schulungen machen. Danach kann man dann abschätzen ob NAV2013 denn eine Option ist, und was der Aufwand (intern) ist, dieses Update zu machen. Die externen Kosten dafür dürften bei ungefähr 20k€ liegen. Natürlich hat diese Testinstallation nicht eure Anpassungen (und evtl. auch nicht eure Daten), aber für einen Eindruck sollte es reichen. Wichtig ist gängige Prozesse wirklich mehrfach auszuprobieren, um den Bedienlauf zu ermitteln.

(*) Keyuser einzubinden ist natürlich eine gewisse Gefahr. Es gibt (nicht wenige) Kollegen die diese nicht angepasste Lösung sehen und sagen "Wasn Schrott!" und das wars dann auch, Meinung gebildet, Projekt tot. Das sollte man bedenken

Und jetzt zu dem was wir in unserer Firma machen: Nix. Wir sind technisch auf 2009R2, Geschäftslogik ist 5.0 mit einigen Anpassungen. Wir haben bereits Schwierigkeiten einen sinnvollen Grund für ein Update auf die Geschäftslogik von 2009R2 zu finden - die Geschäftslogik ist nahezu gleich, nur eben nicht ganz. Der Aufwand ist auch dafür verboten hoch, obwohl wir fast alles intern machen können. RTC und alles ab NAV2013 ist für uns zur Zeit keine Option. Wenn wir mit dem Update kommen würden hätten wir (neben den exorbitanten Kosten) das Problem hinterher zu erklären wieso denn die Arbeit mit NAV nicht effektiver, sondern *langsamer* geworden ist. Bestimmte Sachen lassen sich mit dem RTC überhaupt nicht vernünftig machen - sind bei uns aber Kernkomponente der NAV-Anwendung. Also ganz klar keine Option. Irgendwann (2018 oderso, wenn die Wartung von NAV2009R2 auszulaufen beginnt) werden wir uns wahrscheinlich für ein neues ERP-System entscheiden.

LG Jens

Hallo,

ein Umstieg auf NAV 2013 macht definitiv dann Sinn, wenn man mit vielen Dimensionen arbeitet. Das ist eine von den beim Update zeitaufwändigen Prozeduren. Es wird aber durch die eingesparten Dimensionsposten mehr als wett gemacht, die nicht mehr für eine immer größer werdende Anzahl Posten und langsame Buchungen sorgen. Desweiteren hat mit NAV2013 derjenige Vorteile, der sich mit Externen unterhalten muss, sei es über WEB- Browser, Webservices oder auch .Net. Das alles funktioniert wesentlich besser oder überhaupt erst mit NAV2013 (R2).

Gruß, Fiddi

Jetzt sag bitte nicht, dass das schon alle Argumente pro 2013 waren

Jetzt sag bitte nicht, dass das schon alle Argumente pro 2013 waren

Sicherlich nicht. Aber wer in NAV nur seine Aufträge erfasst, womöglich die Buchhaltung von der DATEV machen lässt, und von Verkaufsstücklisten noch nie was gehört hat, oder wo alle Bernutzer alles machen (können), für den gibt es auf den ersten Blick keine Vorteile in NAV2013, die den Aufwand rechtfertigen.

Was der Kunde konkret davon hat auf NAV 2013 umzustellen, kann man leider nur sagen, wenn man den Kunden und dessen Anwendung kennt.

Gruß, Fiddi

Hi zusammen,

Vielen Dank für die vielen Inputs! Es wurde bei uns leider garnichts (GUI-Anpassungen, Reports ... oder anderes machbare) von unserer Seite aus gemacht, sondern alles an den Dienstleister ausgelagert mit der Begründung der "Haftbarkeit". Daher ist über die Zeit zuwenig Wissen auf unserer Seite aufgebaut und stattdessen zuviel dem Dienstleister überlassen worden (auch solche Strategischen Dinge wie "wann" wird "in welcher Form" upgegraded). Es wurde uns gesagt, dass Addons zu NAV2009 (EasyArchiv) bereits 2015 abgekündtigt würde und daher ein Upgrade auf NAV2013 ratsam wäre. Ich bin neu in unserem Unternehmen (als Anforderungsanalyst) und leider auch was zu neu in Navision - aus meiner Warte würde NAV2009 für die meisten Anwender im Haus eigentlich erstmal ausreichen. NAV2009 wurde zudem erst im Frühjahr2013 von NAV2005 upgegradet (was ja eine Vorraussetzung für den Upgrade für NAV2013 ist). Daher würde ich auch am liebsten warten bis der Support für NAV2009 ausläuft und dann erst über ein Redesign in NAV2013 nachdenken, auch um die aktuelle NAV-Lösung (die in den letzten 7 Jahren etwas sehr gewuchert ist) zu überarbeiten. Wie ich das von allen hier jetzt verstanden habe, wäre eher zu einem Komplettupgrade zu raten (entweder über ein Redesign oder die Upgrade-Tools von MS), statt der vorgeschlagenen Synchronisationslösung des Dienstleisters.

@Fiddi:
Ja, für das neue Modul (das noch nicht in Navision, sondern lediglich in der Planung ist) bräuchten wir die weiterführenden Funktionen für ein Webportal, daher käme hier eigentlich nur NAV2013 als Entwicklungsbasis in Frage.

Hinzu kommt, das die darunterliegende Technologie "anders" ist, mit anderen Möglichkeiten der Programmierung - und vieles von dem was man im Classic Client machen konnte geht im NAV2013 nicht mehr, und muss völlig anders gelöst werden.

Könnt ihr mir sagen, was genau? Der Dienstleister brachte das auch als Argument für seine Synchronisations+Datenmigrationsidee - ich kenn das aus der Softwareenticklung eigentlich so, dass Versionserhöhungen zwar immer einen Mehrwert/Entwicklung darstellen, aber trotzdem immer abwärtskompatibel sein sollten. Sonst können Altdaten vom Kunden (wie Reports bei uns) ja nicht mehr weitergeführt werden. Das wäre ja fatal (von Microsoft)!

Danke und Gruß,
Marion

Hallo,

um die Alt- Daten brauchst du dir eigentlich keine großen Sorgen machen beim Update von 2009 auf 2013. Die ändern sich im Standard kaum (von den Dimensionen mal abgesehen, die allein schon ein Updategrund sein können).

Sorgen musst du dich im wesentlichen um das Reporting, das komplett neu ist in NAV2013. Hier müssen alle Berichte umgestellt werden, was einigen Aufwand bedeutet. D.h. habt Ihr viele angepasste Berichte/Belege, dann kann das etwas länger dauern wenn der Partner das noch nicht so oft gemacht hat.

Auch kann der Datenaustausch ein Thema sein, da hier durch die Multitier- Architektur andere Gegebenheiten entstehen (Daten werden auf dem Servicetier verarbeitet, nicht mehr auf dem Client).

Wenn du allerdings für die NAV2013- Version bereits fertige Pakete(Branchenlösungen) bekommen kannst bzw. schon eine Branchenlösung verwendest, dann sollte es eigentlich kein Problem sein, ein Update auf NAV2013 zu machen.
Habt ihr eine Branchenlösung allerdings bei einem anderen Partner als eurem aktuellen Partner eingekauft, habt u.U. ein Problem. Wenn eurer neuer Partner nicht an die Objekte des alten Partners benutzen kann, bzw. dessen NAV2013- Version, sondern neu programmieren muss.

Gruß, Fiddi

Hi Fiddi,

Hmm, der Dienstleister meinte, die Umstellung des CCs auf RTC wäre eine der größten Hürden. Die Forms in Pages umzuwandeln, mit Programmanteilen, die in den Forms hinterlegt wurden (statt in der Tabelle oder in CodeUnits) und daher auch überprüft werden müssten. Die Reports hatte er garnicht erwähnt gehabt. Müssten die alle dann umgeschrieben werden? Hat sich da die Syntax/Programmierung für NAV2013 geändert?
Das doofe/ärgerliche ist: wir haben eine Branchenlösung des Dienstleisters - warum der Dienstleister seine eigene Branchenlösung nicht upgraded kann, müssten wir jetzt nochmal rausfinden/hinterfragen.

LG, Marion

Hallo Marion,

die Programmierung der Reports unterscheidet sich doch sehr (Vergleich NAV2009 CC <--> NAV2013).
Das komplette Report-Layout wird in NAV2013 in Visual Studio erstellt/gepflegt und ist demnach nicht mit dem Reportdesigner des ClassicClients zu vergleichen.

Frage:
Wenn ihr eine Branchenlösung verwendet - bezahlt ihr dann dafür eine separate Wartung für die Pflege der Branchenlösung?
Wenn JA - ist in der Wartung dann nicht das Recht (oder ggf. die Pflicht) enthalten, auf die aktuellste NAV-Version (inkl. der notwendigen Branchen-Objekte) umzustellen?

Gruß
Jörg

Hallo Marion,
die Konvertierung der Forms halte ich, je nach Programmierung, für ein überschaubares Problem.

Gruß Fiddi

[Freestyler]

Also ganz klar keine Option. Irgendwann (2018 oderso, wenn die Wartung von NAV2009R2 auszulaufen beginnt) werden wir uns wahrscheinlich für ein neues ERP-System entscheiden.

LG Jens

OT: Ok, na dann werden ab 2018 die Airberlin Tickets a bisserl mehr kosten

Ontopic:

sondern alles an den Dienstleister ausgelagert mit der Begründung der "Haftbarkeit". Daher ist über die Zeit zuwenig Wissen auf unserer Seite aufgebaut und stattdessen zuviel dem Dienstleister überlassen worden

Da hat man IMHO suboptimal entschieden.

Man kann heutzutage eine simple deutsche Kostenrechnung und deutsche Buchhaltung meistens nach Polen und Tschechien auslagern, falls man jemanden dort findet, der Deutsch spricht, BWL studiert hat und dem man das repetitiv beibringt, v.a. da sich die Regeln hierfür nicht so oft ändern (abgesehen vom EStG, welches Ausstrahlwirkung auf die Buchhaltung hat).

ABER: wenn man seine IT und v.a. sein ERP outsourced und sich nicht bewusst ist, dass man kein Legobaukastenprinzip mit beliebig austauschbauren Einzelteilen hat, sondern ein komplexes Gebilde mit Interdependenzen, dann tauscht man Haftbarkeit und vermeintliche Risikominimierung gegen Abhängigkeit und höheren Kosten.

Outsourcing ist immer eine schwierige make or buy Entscheidung, daher kann ich euer Management schon irgendwo verstehen, dass man sich IT-Probleme vom Hals schaffen und dafür einen Pauschalpreis zahlen wollte.

Zuletzt geändert von Freestyler am 19. Februar 2014 09:49, insgesamt 3-mal geändert.

Die Forms in Pages umzuwandeln, mit Programmanteilen, die in den Forms hinterlegt wurden (statt in der Tabelle oder in CodeUnits) und daher auch überprüft werden müssten.

Auch in Pages kann man Programmcode hinterlegen, aber es je nach Komplexität manchmal gar nicht möglich, eine Page zu erzeugen, die 1:1 die bisherige Funktion einer Form übernehmen kann. Das ist ein anderes Konzept. Ein Form wird pixelgenau designt (dafür gibt es zwar auch Regeln im Style Guide, bei speziellen Anforderungen hat man da aber auch freie Hand), eine Page dagegen einem definierten Renderingschema unterworfen, welches kein freies Designen mehr zulässt. Dazu kommt noch, dass sich durch die 3-Tier-Technologie vieles in der Client-Server-Interaktion geändert hat. Man muss den gesamten Bedienungsworkflow überprüfen, egal wo der Programmcode steht.