Update Rollups and Project Considerations for Upgrade, Maintenance and New Implementations

More and more partners are beginning to work with the update rollups. They find a lot of value in applying the latest application and platform fixes up front, instead of waiting for a customer to report those. Update rollups also simplify the way fixes are discovered and surfaced.

So with this blog post, we want to provide a more detailed picture of the update rollups, their purpose, and their usage scenarios so that you are aware of the rollup release process and components, and so that more of you start using them. We would also like to provide our look at how to adopt and use the update rollups within various stages of the implementation project lifecycle.

What is an update rollup?

Update rollups are released monthly for Microsoft Dynamics NAV 2013 and Microsoft Dynamics NAV 2013 R2: 

Released update rollups for Microsoft Dynamics NAV 2013 R2

Released update rollups for Microsoft Dynamics NAV 2013

An update rollup is a set of files that includes all hotfixes (application and platform) and regulatory features that have been released for the versions of Microsoft Dynamics NAV that are listed above. 

They are cumulative, meaning that they include hotfixes and regulatory features that were released in the earlier update rollups for the specific product version.

Each rollup contains the following:

  • Accumulated application change log (TXT format) compared to the originally release of the specific product version (the RTM release).
  • Application change log (TXT format) compared to the previous rollup - the “delta”.
  • Only the application objects that changed since the RTM version are included in the FOB and TXT files provided with the rollup.
  • Each application object is marked with rollup version number (version number + build number) to make it possible to see which objects have been changed in which rollup.
  • The latest version of all (not only the changed ones) platform components (executables and .dll assemblies). These components are also stamped with a version number and a build number.

Application changes:

Platform components:

Hotfixes that are included in the update rollups do not always include translation. In that case, the translation for such changes are provided with the next RTM version of  Microsoft Dynamics NAV (major releases or minor release). Regulatory features included in the rollup are almost always translated; however, in rare cases the translation is provided with the following monthly update rollup.   

Update rollups are currently released for 10 countries: Australia, Germany, Denmark, France, Italy, North America (Canada, US, Mexico), Netherlands, New Zealand, Sweden, United Kingdom.

Local hotfixes for the following countries are currently not included in update rollups: Austria, Belgium, Switzerland, Spain, Finland, India, Iceland, Norway.


Maintenance. Applying rollups for the countries/regions where they are available.

If you have a version of the running application for which you would like to apply the update rollup, you can follow this high level flow:

  • Find the latest rollup available for your application version here:
  • See the KB article for the UR to find the full list of application and platform changes as well as regulatory updates included in it. The list is divided by country/region. For instance, here are the KB articles for the latest available rollups:
  • Based on the urgency and relevance of the application and platform changes, current project stage, customer situation and other surrounding factors decide whether you want to apply the UR now, or wait for the next one. We strongly recommend that you always apply the latest UR to gradually reduce the amount of regressions, merging, issues and to be compliant with the latest regulatory requirements. 
  • If you are on the RTM version merge your application objects with all objects included with the latest rollup.
  • If you are on the URn version – filter out the objects which were changed since URn till the latest available UR and merge your application objects with those objects. You can use the Version List field to see in which rollup (build) they were changed. 

Maintenance. Applying hotfixes for the countries where update rollups are not available.

For these cases the process of applying the hotfixes and regulatory updates is the same as it was before the UR concept was introduced, namely the changes relevant to all countries/regions (W1 changes) should be applied one by one.

However, URs can aid this process as well as you can obtain all W1 changes by downloading the latest W1 UR and merge them into your country version. You can find W1 URs by clicking at “Show additional information” and looking at their Fix Name which you can see when you download the UR:

Platform components are country independent, therefore the platform updates can also be obtained from W1 UR and deployed for any country/region-specific version of Microsoft Dynamics NAV.

Major releases, minor releases, and update rollups

URs are different from the major and minor releases. Every major and minor release contains new application and platform features and functionality as well as hotfixes, while the URs only contain hotfixes and regulatory updates. So when a major release or minor release has been released, we create a new branch for the next release and continue to maintain both branches.

Let’s dissect the process based on the Microsoft Dynamics NAV 2013 version as an example (see the illustration below).

When Microsoft Dynamics NAV 2013 version was released, we created a new branch for Microsoft Dynamics NAV 2013 R2 development. As we’ve been building Microsoft Dynamics NAV 2013 R2 functionality, we kept fixing Microsoft Dynamics NAV 2013 and kept releasing URs for it.

Relevant fixes from the Microsoft Dynamics NAV 2013 version were merged into the Microsoft Dynamics NAV 2013 R2 version in the course of its development. In many cases they had to be redesigned to fit the new code and new functionality of Microsoft Dynamics NAV 2013 R2.

Therefore, when Microsoft Dynamics NAV 2013 R2 was released, not all fixes included in the latest available Microsoft Dynamics NAV 2013 UR were included in it. The process of finding and merging relevant fixes into the latest branch is a continuous process, and there will be a certain lead time until the fixes from the releases are synchronized between branches. So, for instance, the majority of the fixes which were available in Microsoft Dynamics NAV 2013 UR7 were included into Microsoft Dynamics NAV 2013 R2 UR1, and the process of merging of relevant fixes will go on.

When considering upgrade or a new implementation of the new major release or minor release, we recommend that you always upgrade to (or start from) the latest available UR for it. If there is a particular hotfix which is available in the previous version of Microsoft Dynamics NAV, but it not yet available in the latest release, you can always request it to be merged there using the normal support process “How to create a new support case”.  It is also always possible to only update the platform components with the updated ones coming from a corresponding UR (technical upgrade), although the best practice would be to keep the application objects updated to the latest UR as well.

Microsoft Dynamics NAV 2013 R2 hotfixes are also periodically merged into Microsoft Dynamics NAV 2013 and will be eventually available in the upcoming URs. Similarly, if there is a particular hotfix which is available in the current version of Microsoft Dynamics NAV, but it not yet available in the previous release, you can also request it to be merged there using the same support process “How to create a new support case”. 

We will continue to release URs for the Microsoft Dynamics NAV 2013 release and future releases periodically, synchronizing relevant fixes between them over time.

Microsoft Dynamics NAV 2009 SP1 and Microsoft Dynamics NAV 2009 R2 are maintained following the old process - you can request hotfixes on case by case basis, no update rollups available for those product versions. 

The following timeline illustrates the process.



It is highly recommended to implement the update rollups. We look forward to hearing your feedback and suggestions to how this process could be made more convenient for you to assess and absorb the changes.


Kind regards,

Microsoft Dynamics NAV Team


Updated on January 16, 2014: We removed two sentences that were misleading around the upgrade rollups and the Upgrade Toolkit. We apologize for the confusion.

Comments (29)

  1. Dennis says:

    You are NOT making it easy for us to create addons for Microsoft Dynamics Nav…

  2. Jens Glathe says:

    I agree with Dennis. This is insane, plain and simple.

  3. Vincent Vancalbergh says:

    As requested with previous rollups, please release localized versions for all countries.

    Merging a W1-version with a BE-version (for instance) is hell because diff-tools like WinDiff and Beyond Compare see every multilanguage caption as a difference. I wouldn't mind if the localized versions were delivered two months later than the W1. It'd still be better than delivering a project on the RTM version and then having to implement everything one by one. As it stands, merging these takes too long to justify the cost.

  4. Natalie K. says:

    First of all, thanks for this good summarizon. One could complain about the update rollup processes, but not about the article itself!

    Just one thing:

    Support process “How to create a new support case”? Is there a link missing, several times in your article?

  5. Kai Kowalewski says:

    @Vincent Vancalbergh

    If you export all the language modules except ENU with option "Delete Language" first , you can afterwards export objects without all the multilanguage differences. When you have finished your merge and reimported the objects, you can then reimport the language layer files. That works perfectly and saves hours of time spent with merging.

  6. Dmitry Chadayev (Microsoft Dynamics NAV) says:

    Great discussion! Thank you for your comments and for sharing your view.

    @Dennis – would you please elaborate? What is causing troubles? Anything we could do to ease this process for Add-on providers?

    @Jens – I found your points on another Blog post:

    1. Fixes: Real fixes of bugs, no new features or changing of the code base structure on the fly. All this in rollups, that'll be fine. What's not ok is when captions are reset to english because you've changed the W1 caption… this is a major pain for every user of localized versions, that'll be most of us NAV partners. Or you make major changes in (for example) CU 12. This is a real pain for partners with Add-Ons.

    2. Feature Updates: If it has to be… but then based on a easily to find source base, or it's a merge nightmare.

    //DMC: We are searching for the feedback like this, things which would ease the process of rollups (and new versions) adoption. Could you please give me more info on the situation with captions being reset if you get a chance? In which version/objects/localization it happened?

    CU12 was indeed refactored significantly in NAV 2013 R2 RTM release, it was a real pain maintaining it in the past. It will take time to learn the updated structure, however it should be more easily mergeable and extendable in the future. There is a White Paper available in the NAV 2013 R2 Readiness Library on the Partner Source which explains the details of this refactoring (PS is under reconstruction currently – I'll try to find the link as soon as it is available again).

    // Finding a source base – how would you like it to be exposed? What would you expect to see in the source base(s)?

    @Natalie – thank you! The link will be added as soon as PS is back in its full glory!

    @Vincent and Kai – yes, exporting language modules with "Delete Language" flag would indeed remove MLCaptions for that language from the code, so this should help. We are also aware that dealing with MLCaptions in this way is tricky (to say the least), so we are looking at the ways to improve this experience.

    Kind regards,


  7. In the article it is said that "Hotfixes that are included in the update rollups do not always include translation."

    Why is that?

    Where is the problem with translating the missing MLCaptions? I mean I can do it! My only problem is supposably with next Update Rollup 3 they will be overwritten if I’m not really carefully. That is why I recently submitted about 23 DEU-Caption with English Content to the Microsoft Support regarding Dynamics NAV 2013 R2 release to Update Rollup 2.

  8. gert@lynge.org says:

    It is a pain to update multiple client installs with rollups. I know you could build a ClickOnce installer or install via policies… But for small customers with 5-10 clients it could be solved easier:

    It would be nice if a small update utility was included. One which was initiated by the NAV Windows client when it was started and found that the server had a newer build than the client…

    Simply exit NAV, call the updater which would then download (the rollup package from a pre-defined path/URL) and update the client to the same platform build as the server and then restart the NAV client…

  9. Vincent Vancalbergh says:


    Thanks for the tip. I'll be trying that as soon as possible !

  10. Jens Glathe says:


    regarding the code base for merges… I would assume that you're using a revision control system inhouse. I assume quite a lot of partners do likewise now. To set one up you need the real base versions (the RTMs?) to have a base to apply changes against. When a rollup update gets released, you need to add the changes to your "msft" tree, to have starting points for the releases you do with your AddOn. Also, for the release to customers, you merge the changeset of the rollup update into the customer's tree.

    So far so workable, if it weren't for a few problems:

    1. What's the "branch" revision for a new version of NAV? We can't know, we could perhaps find out afterwards. So, we have a problem setting up a correct version tree to branch out from (example: NAV20123 -> NAV2013R2 has a code base somewhere between RU5 and RU6).

    2. For the localizations you also need the true "branch" revision. Same problem, essentially, but even more annoying due to the captions problem.

    If you're maintaining AddOns, you have to ensure that it runs as advertised on all the versions and localizations you support (and from 2013 on, all the rollups). That is quite a task in itself (now). If you offer a "merge" service to ease the integration of your AddOn into the customer's database, you would also need the correct base tree to have a chance of doing the merge in reasonable time. Keeping the whole thing working requires a lot of work and discipline. The maintenance amount is so high that the fact that you actually want to develop new features gets somehow thrown under the bus.

    So, anything that eases the maintenance of the rollups/localizations/AddOns would help getting me back to actually do some development.

    with best regards


  11. Sebastiaan Lubbers says:

    I created a repository in which I checked in below versions of which I can branch and compare any version of our implementation. The way I did it was to create a full text export, split the individual objects, but also strip Date/Time/Modified and Version List. That way you get clean compare of code changes and not "version" changes which might conflict when trying to make a merge with another countries implementation.

    master > 3.0.10008

    master > 3.1.10750

    master > 3.6.11353

    master > 3.7.13643

    master > 3.7.16172 > 3.7.19516

    master > 4.0.19365

    master > 4.1.21666

    master > 4.2.22100 > 4.3.25143

    master > 5.0.24199

    master > 5.0.26084

    master > 6.0.27808

    master > 6.0.29626

    master > 6.0.32012

    master > 7.0.33781

    master > 7.0.34688

    master > 7.0.34902

    master > 7.0.35026

    master > 7.0.35201

    master > 7.0.35345 > 7.0.35488 > 7.0.35670 > 7.0.35782

    master > 7.1.35473 > 7.1.35701 > 7.1.35764 > 7.1.35800

    Using the "for personal use" free SourceTree client you can easily do a blame or a log to see what version changes what and who changed it.

    Setting up a remote on visualstudio.com and you are easily set to work from home or office on the same codebase.

  12. Capone says:

    I agree with Gert Lynge. The major reason to why we don't update regulary with UR:s is that we need to "reinstall" all the clients which is a time consuming process.

    Another reason is that it will be harder to maintain from a developer perspective. Correct me if I'm wrong but each UR is a new build? This means if we have several customers on different builds we have to maintain in our own developing environment (some times you can't cross objects from different builds).

    I would appreciate a blog post on how to easy install a UR on customer site which has a lot of clients and some tips and tricks about how to easy maintain several builds at our own site.

  13. Dennis says:

    @ Dmitry Chadayev

    We have 4+ addons we offer in DK and W1 versions.

    Lets look at one of them:

    We have modified the following standard objects:

    Table 8,18,21,36,80,81,91,112,114,289,295,297,302,304

    Page 9,21,22,25,42,43,44,101,119,132,134,253,255,427,434,438,446,450,6630

    Codeunit 1,11,12,13,80

    To make installation as easy as possible for our Partners we always want to be able to provide the latest version of each object.

    Every month when you release a new RollUp we have to move our addon-code into every object you have changed.

    (Please note – a modified Version List is also a change)

    We are wasting time moving code!!

    And that is not all.

    We also have to support the new RollUp versions for X months.

    Lets say I have a new feature for my addon that require a modification to table 112.

    I now have to modify every unique table 112 I have in my system (W1 and DK versions)

    How many extra versions of table 112 do you think I will have to modify in 6 months?

    You could say – you dont need to support all those RollUps – just delete them after x months.

    But if we make a great new feature or a bug-fix for our addon and a customer with RollUp 1 only would like to get it – then he should be able to get RollUp 1 objects from us for a quick install…

    We are wasting time supporting too many versions!!!

    Are you really sure we need a RollUp every Month??

    Have fun Mr. Elvis 😉

    Kind Regards


  14. Dmitry Chadayev (Microsoft Dynamics NAV) says:

    Daniel, Gert, Jens, Sebastian, Capone and Dennis – Thank you for all this great input! This is really helpful and I can certainly see, that keeping up with the rollups can be a big infrastructural challenge.

    Although it is interesting to note that this has become more prominent when we introduced *the notion* of an update rollup.

    In the past, we were releasing application hotfixes and regulatory updates separately on the Partner Source. They would pile up there until someone would bump into an issue and then they would have to search for a specific hotfix among dozens of titles in the library. There would even be hotfixes which intersect with each other! If a regulatory feature would be touching the objects which are already patched by a hotfix, you (and we) would have to search for those hotfixes and integrate them into the regulatory feature. So the base application objects would also change back then, and the add-ons would be tricky to apply in those times too. The base version would be somewhat unpredictable (well… unless you don't apply any fixes at all).

    With the rollups we removed the complexity of cherry-picking hotfixes and RegFs – we are shipping a complete version every month. New implementations can start on the version which is compliant with local laws and has less issues in it. Also when a new release comes out – there is less merging required, as the code of the hotfixes and regulatory features is already merged.

    But with the rising update rollups awareness – customers' and partners' expectations are also rising, as you correctly pointing out. It requires better tooling, structure, source data, source control and actual merging. You are absolutely right – it is a lot of versions to maintain *today*. As we improve and optimize the way we absorb the rollups – eventually there will be less fragmentation in the versions the customers will be running. Until that time – I can assure you that we are looking at all possible options to make this process easier for you, you'll be seeing more done in this area. Therefore please keep up the constructive feedback like this. It is ending up in the right hands! 🙂

    Thank you!

    Dmitry (aka Mr. Elvis ;))

    Microsoft Dynamics NAV Team  

  15. I don't think that there will be less fragmentation in the versions the customers are running. We are already getting requests from our customers (other MBSPs) for all Update Rollup versions that exist, and if this continues the way it is now the day will come when I will have several requests for our addons on my desk all at the same time, one for Rollup 3, the next Rollup 11 , Rollup 23…etc, depending on when the NAV rollout actually took place and if the partner who is taking care of the customer updated the site installation in the meantime.

    Since NAV 2013, NAV 2013 R2 and NAV 8 "Crete" and NAV 8 R2 all will have their own rollup product line to handle, the amount of work will triple or even quadruple every month until the support for NAV 2013 ends.

    Supporting all the different technical builds will also be a big issue. In our case, Rollup 8 was the first version which could not be compiled with the RTM build due to a new DotNet-Method in the Excel Buffer, but even before this there was a change in the compiler which had an impact on the way the coding in a page object was checked. This led to the effect that the RTM build compiled the page without problems but the compiler of the rollup version did not. So to really make sure that the objects will be usable straight away there is no alternative but to compile them with the corresponding build.

  16. Tommy says:

    Lots of nice discussion here. Just wanted to re-iterate what has already been said (albeit using difference words). The fact is that in the "old days" hotfixes were just that. Hotfixes. IF you ran into a specific issue you would incorporate that hotfix into your code base. NOW it is quite different. Yes hotfixes are now collected and released in one big chunk. But the fact that awareness has been heightened with regards to this makes it so we have to be able to provide our products to any given RollUp. Previously we could safely provide just one version of our addons for every major release and for a few (maximum 3 major patches for a given version of NAV, if I remember correctly). With rollups we have 9 versions (x number of addons) for NAV 2013 alone and it will only get worse.

    To put it bluntly. It bloody suxx to have to do this and we WILL have to decide at some point to only release for every 4th RollUp or something like that or we will have no time to actually create new value for our addons.

  17. Dmitry Chadayev says:

    @Natalie, Jens – Partner Source link as promised:

    1. New Technical Support Request: mbs2.microsoft.com/…/newstart.aspx

    2. Changes in the Gen. Jnl.- Post Line Codeunit: mbs.microsoft.com/…/app2 ("General Ledger Posting Framework" section)

    Kind regards,


    Microsoft Dynamics NAV Team  

  18. Natalie K. says:

    Thanks Dmitry!

  19. Dennis says:

    Ehmmm Dmitry…

    Why do you change the version list when it is not needed??

    I am looking at Table 81

    Roll Up 1 version list is : NAVW17.10.00.35770

    Roll Up 2 version list is : NAVW17.10.00.35800

    And that is the only difference between the two versions???

    You should only change the version list if you make any changes to the object please 🙂

  20. dmitry_chadaev@hotmail.com says:

    Thank you Dennis, I'll look into it.

    Kind regards,


  21. Dennis says:

    I found some more objects where Version list is the only difference between Roll Up 1 and 2 :


    Roll Up 1 version list is : NAVW17.10.00.35770

    Roll Up 2 version list is : NAVW17.10.00.35800


    Roll Up 1 version list is : NAVW17.10.00.35770

    Roll Up 2 version list is : NAVW17.10.00.35701   And Version is lower in Roll Up 2 ??


    Roll Up 1 version list is : NAVW17.10.00.35770

    Roll Up 2 version list is : NAVW17.10.00.35701   And Version is lower in Roll Up 2 ??


    Roll Up 1 version list is : NAVW17.10.00.35770

    Roll Up 2 version list is : NAVW17.10.00.35701   And Version is lower in Roll Up 2 ??


    Roll Up 1 version list is : NAVW17.10.00.35770

    Roll Up 2 version list is : NAVW17.10.00.35800


    Roll Up 1 version list is : NAVW17.10.00.35770

    Roll Up 2 version list is : NAVW17.10.00.35800

    This is not good….

  22. Sascha says:

    Thanks for this articles which opened my eyes a bit more how NAV is working.

    NAV 2013 UR6 and NAV 2013 R2 UR1 is breaking our AddIn because the parameterlist of a function has changed.

    I can't find any document which is mentioning any changes regarding this codeunit nor any feature which could be involved.

    Means to me I can't rely on any document but have to test every release against our code.

    As we provide an AddIn to partners which expect an installer for it we end up in a quite challenging (probably impossible) situation how to deliver our bits in a simple way without giving our customers a choice of a dozen options they have to select from.

    The now likely upcoming multiple choices of installers end up in multiple calls to our support team.

    It ends up in multiple partners beeing bothered or annoyed why some simple things end up getting complicated.

    It ends up in a developmentteam which is testing every 30 days against new versions of NAV to keep the AddIn running.

    It ends up in putting more and more time in maintaining and support than in development and invention.

    Alltogether this costs time and money.

    This is definitely no basis for an developer of an AddIn control.

    Best regards

  23. Dennis says:

    Hi Dmitry,

    Sorry for bothering you with this – again – but its kind of important for us…

    I found this on dynamics.com:


    Version List; update the version list after each object change; this gives you at least an indication something has been changed.

    This property, however, does not say anything about what has been changed and who applied the change and, even more important why it was changed.

    Can we still count on you to only update the version list when something in the object has been changed?

    I have now looked at the DK version and your Version list errors have cost me a lot of time…

    The following objects have a changed version list as the ONLY difference from Roll Up 1 to Roll Up 2:

    TAB21, TAB81, TAB112, TAB289, TAB295, TAB302, COD12, PAG21, PAG22, PAG25, PAG132

    That is 11 objects I now have in my system because you are changing the version list when you are not supposed to!

    Adding your “errors” to my object-system just feels stupid.

    You REALLY need to ONLY change the version list when it is needed – PLEASE!!!!

  24. Tommy says:

    Come on people. This is not directly related to this blog.. and then again. It kind of is.

    Clicking on this link from this article regarding released rollups for Nav2013 shows you roll up 10 is now available:


    Going the official route by checking in with PartnerSource (deployment Download. Dynamics NAV 2013 hotfixes) gives you this link:


    Here you can only find Roll Up 9. NOT roll up 10 that you just release. *sigh*

    It might be a small thing but it is something we have seen time and again with Microsoft releases and it is just another source of frustration with this fancy new system you have in place.

    Please get things coordinated so we can actually find what we need without going through obscure blog articles to find links to where you have actually posted the updates.

  25. Dennis says:

    Howdy Dmitry – Any news about the version list issue? 😉

  26. piedmont says:

    Great discussion 🙂

    As Kai says, clearly you need to use platform build XYZ to test your own source code merged with NAV 'vanilla' source code version XYZ.

    What is the best practise for maintaining a platform per update rollup?

    One VM / Azure machine per update rollup; or multiple service tiers & dev environments on a single server..?

    (My 2c: update rollups beat fragmented hotfixes hands down.  The challenges mentioned in the thread are to reach an end result which was in practical terms totally impossible with the old system.)

  27. Dmitry Chadayev, Microsoft Dynamics NAV says:

    Hi Dennis, fully agree with you – Version List must not be changing if there are no changes in the object. We have a support engineer looking at this case – sorry it is taking so long.

    We've been using the following builds for NAV 2013R2 roll-up releases:

    UR1     35701

    UR2     35800

    UR3     36035

    UR4     36078

    We've compared the builds released as roll ups – DK UR1 and UR2 and

    and there are differences in Tab 81. E.g. Creditor No. OnValidate trigger was changed. However your comment is about build 35770. So want to investigate it a little more. I'll get back to you when we have more info.

    Kind regards,


  28. Dmitry Chadayev, Dynamics NAV Team says:

    Ok, we have found build 35770 which is causing versioning issues. This is a W1 of the Cumulative Upgrade 1 (CU1) – where we introduced some additional Cash Management functionality.

    CU1 was a very special case – it is not one of the update rollups, but an out of band release of critical features, and it was not in-line with the usual UR flow, shipping from a separate branch. It was released shortly after UR1, and then the team merged all those changes into UR2. Therefore you see many objects from CU1 matching UR2 objects.

    If you compare UR1/UR2/UR3/UR4 – there we don’t expect any objects to have the versioning flows you describe.

    Kind regards,


  29. Andy says:


    I am a SCM Admin and I have to update the NAV Client by SCCM. It seems that the Setup.exe is only for installing a fresh Installation of the Client. Can somewhere tell me how I have to update the Client?


Skip to main content