The application upgrade is where you are upgrading the objects in your customers version to able to use them in the new version you are upgrading to.
If you are upgrading a customers database without any modifications, then you can jump directly to Upgrade Step 3.
What is the reason for upgrading?
Before you get started you need to think about one thing. What is the reason for upgrading?
If you are the NAV developer and you were given this project by the customer or sales person, then you hopefully got this information along with the project. If not, then now is really the time to ask this question, especially if you are working on a fixed price project! And what the your salesperson promise the customer?
Some of the most common replies to this question from customers are:
- We upgrade to be able to use new functionality
- We upgrade because we are using an old version, that Microsoft no longer supports.
- We upgrade to clean up in unused customized functionality
Often the answer is a little of each. The reason might be that they want to be able use new functionality, but also clean up unused customized functionality.
If just one the reason to upgrade is to clean up unused customized functionality, then it means that you need to know, not only what code/objects changes the customers database contains, but also why these changes was done. And futhermore to figure out which changes are not used anymore, that requires that you first get a clear picture of the changes done, before you must go into dialog with the customer, to figure out what can be removed and what needs to be upgraded.
Compare the changes to the standard objects
- Export the customers objects
The first step to compare the changes done to your customers database is that you need to export all the objects into a text file.
- Export the base versions objects
Then you need to get the a clean unmodified version of the objects the customer's changes are based upon. So in example if the customer want's to upgrade from a US version of NAV 4.0 SP1, then you need to get this exact version. If you don't have it your self (most NAV developers always safe his own copy of the old databases he has been working with in his personal file, or in his companys shared directory), then you can often download it either from Microsoft partnersource, Dynamics User Group download section or maybe Mibuso. If you cannot find it any of the places, then try to ask in the "NAV Developer Forum".
When you have the right version, then you must also export this version into a text file.
- Export the new versions objects
Now you must export the objects from the new version you are upgrading to into a text file.
Common for all text file exports is that you should always use the same client on the same PC when you export. Otherwise you will sometimes experience that the file formats are not 100% the same in the different clients and that will give you problems when you are going to compare the files. Also make sure that you have a full developer/partner license that have access to all the different versions, including any add-ons. Otherwise you will get errors when you're trying to export the objects.
That also leads us to another important thing: NEVER WORK DIRECTLY ON YOUR CUSTOMERS DATABASE, always work on a local copy. Either a full copy, of just a copy of his objects. But you need access to the full database, especially if the customers reason for upgrading is to get rid of unused customized functionality, as a data analyzis here is also required.
When you have the three files, then you can start your compare. For this purpose Microsoft provides you with the Dynamics NAV Developer Toolkit, but most experienced Navision developers seams to prefer Mergetool (available from Dynamicsuser.net's download section and from http://www.mergetool.com). And other and often much more experienced developers again prefer other more manual tools like Araxis Merge etc.
When you have compared the different version, you should get a clear picture of the size of the upgrade.
If your project was a fixed price project or you in any other way have given the customer an expectation to what the price of the upgrade would be, then this step should actually have been done before you actually starts the project.
Decide the upgrade strategy
Knowing everything what has been changed in the customers version, then you need to decide for the strategy you want to use to upgrade the the customers database.
Limited number of customizations
If the customer only has a very limited number of modifications to tables, forms and reports or if you are doing a minor upgrade (ex. from Dynamics NAV 4.0 SP2 to Dynamics NAV 4.0 SP3 with only a few cases of customized objects also changed in then new version), then you it can be an advantages to do a manual upgrade, where manually transfer the changes into new version. That means that you just manually cut and paste the modifications, eventually just imports the reports.
Just notice that upgrading customized copies of standard reports can actually be a challange in itselfs, becuase what on first sight looks like no changes, actually are big changes, as you cannot directly compare the objects. Instaed you need to compare the customized version with a new object number, with the original object with another object number. The reason for doing a manually or semi-manual (ex. using tools like Araxis) compared to the "full-blown" mergetool, is that it takes quite some time to setup these tools before you can use them. And with a simple and very small upgrade, that might not even be worth it.
A lot of customizations
If the customer has a lot of customizations, but he wants to do a cleanup as a part of the upgrade, then of cause the first thing you need know is what is not used anymore. This easy question is actually not so easy to answer, but it requires that you not only talks to the customer, but also that he actually knows the code and changes done in the system, and also that you do a data analyzis to see that the functionality is actually not used anymore. And that is really not the full answer. Becuase if you are analyzing tables, then it might just be automated functionality which is creating the content of the tables. Instead look at what reports/forms are using the tables, and who are using these forms and reports.
Customizations you do decide not to include in your upgrade, should be deleted from you customized database. Then you should re-export the text file and do a compare again.
It might also get more complicated if the customers modifications are in an area which has been heavily changed in the new version. An example on this is the job module, which from version 5.0 was change a lot, with a lot of new tables and removed old tables. In that situation you need not only to analyze code, but also the actual functionality from the users point of view.
Merging the changes
When you have removed unneeded code from you customized version and decided what other structural changes you want to do to upgrade, then you can start with the next step. That's the step where you're actually doing the merging of the changes. It is basically the same process as when you compared the objects.
If you are using the Mergetool it works like this: The tool compares the base version with the customized version with the new version and based on your setup it will put a priority on either the new version of the customized version.
Merging tables, codeunits, dataports and xmlports
The easiest part is merging the tables and codeunits as these objects are basically "just code". That means that the mergetool can easily do almost the full process of these objects automatically. Only where you might have changed code in the old version, which is also changed in the new version, then you'll have a conflict, which you need to verify. Then you can use the tool to transfer the changes YOU DECIDE, or you can skip the object and take the object later.
Dataports and xmlports are almost as easy, but if they have a request form, then they might take a bit longer.
The most difficult, or should we say time-consuming, is to merge forms and reports. Reports are difficult, for the reason described above, as they are often given a new object number, so when you're comparing the objects, then they do actually not existing in either the new or the old standard version. So they are just transferred and marked as good. The problem is that they are really not, as you need to do a manual compare of them to the object the report was originally based upon.
Comparing forms are difficult for the situation that your customized and the new standard object have added new fields to the same location of the form. Just doing a automated merge, will often just cause that both the added and the new fields are merged together.
That means that a good practice is the always manually check and verify ALL FORMS AND REPORTS.
When you have merged all the customizations, then you must export these from the tool again. If you are using Mergetool, then this tool has a number of functions and reports, which you can use before exporting, to check for various typical errors, such as giving two menu points the same shortcut in forms.
Before exporting the objects, then you should use the function to delete all objects which are exactly the same as the objects in the new standard version. This will make your import faster and easier.
Import the object text file of the new customized version into an empty database, only containing all the standard objects of the new version. If your customer had a standard Add-on then you should read this page also: Upgrading an Add-on, as you might experience problems with your license is not allowed to create new fields in the add-ons protected object/field area.
The merge is completed when you succesfully have imported and compiled all objects.
Depending on what version you are upgrading to and from, then there are different upgrade tools available from Microsoft. The upgrade tools are often available on the Partner Tools CD or from Partner Source. You need to find the tool exactly for your versions.
If you are upgrading from a very old version, into a new version, example from Navision Financials 2.50 into Dynamics NAV 5.0, then there is no direct upgrade tool available. Instead you need to take the upgrade over the different steps, ex. from version 2.50 into 4.00 and then into NAV 5.0.
The upgrade tools are usually tools designed to upgrade the data in the database. Like if you go from MBS-Navision 4.0 into Dynamics NAV 5.0, then the whole job module has been redesigned. Then it's not enough to upgrade the objects, but you need to make sure that the data are moved into the right new tables.
You must read the documentation for each version of the upgrade tool carefully, as there might be important steps, which was not part of the last version.
Also you need to go back to your new customized version, compare the changes and the verify if you need to customize the upgrade tool also. If you are doing the job module upgrade from version 4.0 to 5.0, and your customer had new fields to the Job Budget Entry table, then you need to go back an see what you decided to do about these changes in your merge process. If you created the modification in another table, the you need to make sure that the upgrade tool is also transferring the data of this field into the right table.
When you have customized the upgrade tool, then you need to test it. Now you need the full copy of the customers database. Follow the documentation for the upgrade toolkit.
And remember NEVER WORK ON THE PRODUCTION VERSION. At least not until you have tested and tested again and the customer has verified that your upgrade is correct.