12th July 2012
There are many clients that are still on an old version of Dynamics NAV and have not upgraded to 2009. Many of these clients decided to not invest in upgrading to a newer version because they didn’t see any value. I would agree with many of those customers. 2009 did require more development hours and testing than previous upgrades. Many features were missing from RTC so some users were using classic while others were using RTC. Customizing reports was cumbersome. Modifying forms and Pages would go out of sync. There were certain scenarios where doing just executable upgrade to 2009 were sufficient enough to use web services features.
I would like to share the experience of upgrading an existing Dynamics NAV 4.0 to Dynamics NAV 2013 beta. The client was on 4.0 and support for 4.0 had expired a while back and the client was interested in moving to a supported version. Moving to 2009 didn’t make sense since the 2013 release was right around the corner. The client wanted to see the application with their data and go through their workflows in 2013, so that when the final build is released they will be ready to upgrade to it. The client is also using the C/Side database. The work was assigned to a junior developer with a couple of months of experience with my supervision. This client had about 350 objects modified: 82 tables, 109 forms, 96 reports, and 30 Code units. This is a medium sized number of objects.
I suggested merging the tables first, and then merging code units, then merging forms and last merging reports. Based on his experience with this merge, he thought merging tables was easy and went quickly using text compare tools. Merging the Codeunits was a little more difficult, some of them have changed dramatically so it was harder to compare in text. This is mainly because he was comparing modified 4.0 to 2013 txt files. He had missed a couple of functions, but I helped him resolve those. To upgrade the Forms, I suggested that he redo the changes manually in pages instead of using the form transformation tool. This allowed him to get more experience with designing and working with pages and get more familiar with the application. His comment was that it was his favorite objects to merge. He had a text compare tool compare 4.0 modified to 4.0 standards and make the changes manually in Pages.
When he started upgrading the reports, we came to the conclusion that in order to test them and make sure they work correctly we needed actual data. So we decided to upgrade the data first and then upgrade the reports and run them to confirm that you get the same results as classic. There is not a direct upgrade path from 4.0 to 2013, so we went the route of upgrading to 2009 as an intermediate step. You need a 2009 database with all the custom fields, and you can create that by copying and pasting all the fields in 50K range from the virtual table into a Cronus database. You cannot paste option fields, so those you have to paste directly into each table.
We imported the Step 1 2009 CU and ran it and then loaded the 2009 Cronus database with custom fields and started getting into issues related to NA Payroll. Payroll was part of the North American localization in 4.0 and MS removed it in 5.0 there were a couple of fields on employee table that the customer was using. We had to create custom fields and move the data from those HR fields and blank them out since they were going to be deleted in 2009. Step 2 of 2009 ran without any issues and Step 1 of 2009 was loaded into the database and ran without issues. Then we opened the DB with 2013 classic client and this upgraded the DB moving all the text fields to Unicode. Next we loaded Step 2 of 2013 and this part you have to run from RTC. The process is supposed to create the new Dimension Set ID. Here we ran into another issue. The customer had deleted a dimension value record instead of blocking it and we were getting a dimension Set ID value cannot be blank. I recreated the value and we ran into a second issue. There were Ledger entry dimension records with blank dimension value. I don’t know how they got created, perhaps during the upgrade in 2006 to 4.0 that created those entries. I deleted them as well and then the Step 2 finished with the upgrade.
When we started the upgrade the database was 40 GB, when we finished the size of the DB was 270 GB. 85 GB was the data and 190 was the log file. So make sure you have plenty of space to finish the upgrade process.
We decided to manually make the changes in the modified reports. This will give the developer more experience with 2013 report designer just like the pages. Upgrading custom 50000 range reports was one of the biggest surprises. It was a bit too easy. You import the object and compile them and then you go to tools->upgrade reports. If your report does not compile because of some reference or code, go back to the 4.0 DB and comment out the code. Then reimport and compile it, then select upgrade report. Most of the reports so far have been upgraded without any additional changes. They look identical to classic reports. There were a couple of reports such as Checks that needed manual tweaking, but those reports required tweaking during each upgrade in the past.
The client is in the process of looking at 2013 with their data. They are planning to train their users, who are not that computer savvy and there is a lot of things they have to learn. This way they will be ready when 2013 is released.
Posted in Dynamics NAV | Comments Off