Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2020 release wave 1Discover the latest updates and new features to Dynamics 365 planned through September 2020
Release overview guides and videos Release Plan | Preview 2020 Release Wave 1 TimelineWatch the 2020 Release Wave 1 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
Has anyone seen a whitepaper (yet) for Upgrading a Microsoft Dynamics NAV 2009 R2 or Microsoft Dynamics NAV 2009 SP1 Database to Microsoft Dynamics NAV 2016?
I have found" Upgrading a Microsoft Dynamics NAV 2009 R2 or Microsoft Dynamics NAV 2009 SP1 Database to Microsoft Dynamics NAV 2015", but I'm wondering if the process is the same.
Related to this, in the 2015 upgrade document, one of the steps says "For SQL Server 2012, set the compatibility level of the database to 110." What if we are running SQL Server 2012? Do we still set the compatibility level to 110, or can we set it to 120 (SQL Server 2014)?
for upgrading nav 2009 to nav 2016 follow
it needs to upgrade first to nav 2013, then to nav 2016.
you can also follow
then run the automated upgrade process from nav 2015 to nav 2016.
If you are using sql server 2012 then just check the Compatibility level is set to 110 or not. If it is not then please set it to 110.
If you are using sql server 2014 then please set it to 120.
regarding SQL Server 2014: I would recommend to set the compatibility level to 120. As for the upgrade, you can go* directly** from 2009*** to 2016, and do the upgrade routine from 2015 to 2016, if it is required.
Now to the asterisks:
*: I did for a customer. The basic script was this blog. I compiled my own checklist and a few interesting scripts for the real-world tasks like removing unwanted objects for which you have no license. You should have an SQL Server where you can set snapshots of the database.
**: Depends on your merge tooling and experience. With a state-of-the-art source control system like mercurial or git you can create a usable merge for most object files. You need the right base versions and the change tree to the new versions (no you don't need every change between, but it helps for analysis and it helps the source control with the merge). For example like this:
There are some pitfalls, though - no tool is perfect, and the limitations of a NAV license make matters worse. If you have, for example:
- a table where old standard fields are removed and new standard fields are created, and
- this table contains fields of an addon (maybe also with the remove/create scenario),
you have a problem. You can create a "clean" text version of the object with all fields as they should be. But you can't import it, except when you have a Microsoft W1 Developer License with no restrictions whatsoever. So, the way to go is to create an interim object (as .fob) with all the new fields you need to have, and hopefully the old fields deleted (and no code inside) that you need as primer for the database. Afterwards you can import your text file object. If some of the old fields can't be deleted (you have no means to create the .fob you need), you need to disable them in the text import.
***: Started from 2009, you could even start below. What you need to do is to have a look at what the conversion routines do for upgrades to 2009R2 (and past 2015) and if your database is affected by this.
with best regards
Thank you for the reply. Thanks also to the other people who commented. The bottom line is that I now have confirmed that we have to upgrade to 2015 first, then to 2016. The steps to upgrade to 2015 in your blog and other references also say that you have to go to 2013 also. So its 2009->2013->2015->2016....whew! Note this is data only.
As far as the other application objects, I know our merge will be "interesting". We are removing one shipping addon in favor of another as part of this upgrade, for example. We are also getting ready to use a source control, probably Team Foundation Server with Git/GitHub, since our web development team uses something similar.
Thank you again for the reply and the advice.
no, I have also no official whitepaper for that scenario. But I'm allready in that situation :D
Like my prev. speaker here, I used the way over 2015.
But now I have my NAV2015 Version and one fob file (Upgrade800900.DE.fob). Did anybody knows if this is step 1? is 2 missing? how do I use this upgrade toolkit?
Just to answer you last reply -
For Data Migration you don't need to follow 2009->2013->2015->2016.
The Process Is -
NAV 2009 -> NAV 2013 / NAV 2013 R2 / NAV 2015 -> NAV 2016.
The Data Migration Process is of Two Steps Only.
First you Upgrade Your Data To NAV 2013 / R2 / 2015 (One Merge Tables Only, One Data Migration).
Then you Upgrade Your Data To NAV 2016 (Second Merge All Object Merge , Second Data Migration).
For Data Migration Steps To NAV 2013 / R2 / 2015 From 2009 you will find in Product DVD or Partner Source.
For Data Migration Steps To NAV 2016 - MSDN Link is available but I compiled One Based on My Migration To NAV 2016. You can refer here for those steps .
Let us know if any issues.
Refer Here for Steps -
Hi Saurav Dhyani,
thanks! But im confused. Step 8 is to import the application objects into NAV2016 and with 9 we import the upgrade tool kit. When I synchronize the table-schema (Step 10 with force I think) all standard fields that are not in use anymore are deleted and the data is gone.
In the old data upgrade processes there was Step 1: fill temp tables
Step 2: fill standard fields out of the temp tables.
where I'm wrong? :D
EDIT: AHHHHH they use the upgrade codeunits so solve that. before sync. they copy it etc. or?
Hi MatthiasKoenig ,
The Temp Table Filling thing that was step 1 in earlier upgrade Process, was required because there were some Process Changes which require data to be there on temp.
During Step 2 the Temp data was Re-engineered and Move to Actual Tables. If these types of changes are not there between version then we don't need to do that.
Hope you understand.
mmhh I understand but I think im blind. I don't find the "Step 1".
I checked the codeunit (and your blog post) but dont see there step 1 :/ sorry
+ in the MSDN Article is this part:
Task 10: Run the data upgrade process
A data upgrade runs the upgrade toolkit objects, such as upgrade codeunits and upgrade tables, to migrate business data from the old table structure to the new table structure. You can start the data upgrade from the Microsoft Dynamics NAV Development Environment or Microsoft Dynamics NAV 2016 Administration Shell.
But I dont find where the temp tables will be filled.
What Microsoft Upgrade Toolkit Still Have to Re-design is the Approval Related Part. There are some tables which does not require Data like approval Setup and Some which require data Movement or Table structure change like Approval Entry and all.
If you filter your objects using UPGTK9.00.00, you will find some new tables added which are temp and one codeunit added.
The Codeunit 104050 UPG8081.W1, is a Type of Upgrade Codeunit which do the magic which you are looking for.
depends a little. Usually, in the upgrade codeunit itself. For an upgrade 2009->2015, this step is run on 2009, the temp tables will be filled there. These upgrade codeunits are quite powerful and a PITA at the same time. ;)
For example: Try to select them. If you don't know which ones are upgrade codeunits, you need to export all as text and do a grep to find them. Old upgrade codeunits are a real danger, they should be deleted immediately after use, IMO.
Another example: When you do the schema synchronisation after you've imported your new (target) objects, the upgrade codeunit must already be there (and compiled). Otherwise you will get errors and hints on how to complete the upgrade codeunit in the powershell output (that's powerful.).
with best regrads
thanks for your fast post :)
I want to upgrade to 2016. The way is here 2009->2013->2015 and then 2016.
I use the Upgrade Toolkit of 2015 to Upgrade all the data in that "new" table structure of NAV2015. Now I want to Upgrade this into 2016. A full new Upgrade and the old filled temp tables are gone :)
The Codeunit 104050 UPG8081.W1 is as you both described an update codeunit. But this fills NOT the temp tables. This Codeunit prepare the table sync setup and fills the new standard tables/fields with the temp tables. But I think, they are empty and get never filled.
Did you know were the temp tables get the data in the upgrade from nav 2015 to 2016?
sorry but I'm interested in those details and hate it when I don't get it by my self:D
when the upgrade is run in one step (between versions that know the upgrade codeunits), the data is only saved in the temporary tables during the run time of the upgrade. They should be empty afterwards.
now that's an interesting find, thank you :) The combination goes a little further. You said that it will be an "interesting" merge (as usual), with removing old addons/cruft (we did) and integrating new addons (we didn't, only new versions, and workflow is now part of standard NAV). For the data migration of the addon data, you actually can use the same mechanism. This way (and it's a big plus, IMO) you can do your merge / development of the new solution without paying too much attention on how to transform from the old structure to the new one, as long as you know what goes where. No interim fields in tables of the target application, easily possible "cleanup" of bad numbering decisions from the past, to name two. You can put your "custom" part of the upgrade in your own upgrade codeunit. It will be executed with the rest. In the overall context of this upgrade, this will be the "better" approach, IMO. For the standard upgrade codeunits, you need to look what the structural changes between 2015 and 2016 are, and eliminate the steps that created the structures in 2015 from 2009. You reduce them to one transformation from 2009 to 2016. Since the upgrade from 2015 to 2016 can only be these, you integrate these transformations into the 2009 to 2015 upgrade codeunit.
Business Applications communities