I want to upgrade a NAV 2015 db to NAV 2018 with converting all customizations as an extension. My NAV 2015 db is not customized with event-based structure but there aren’t many customizations. Hence, I am thinking of creating a new 2018 db from scratch, remake customizations as an extension and move data with rapidstart services but I am not convinced by this method and not sure if this is the best practice. Can you kindly let me know what is the way to follow in this type of scenario?
The worst thing you could do is to blindly create all customizations as an single extension! Even if you don’t have that many changes, then you need to carefully analyze your changes and structure them into logical extensions.
How experienced are you with Extension development? How experienced are you with upgrade NAV? If you are not very experienced and have done countless upgrades and extensions, then I would suggest to keep it as simple as possible to avoid too many complications.
My suggestion would be to upgrade your NAV 2015 to NAV 2018 in the “traditional” way. The only thing you should really change in the first step, would be to utilize events and move as much custom code to even subscribers as possible. And clean out anything you don’t need anymore.
Then after you have upgraded to NAV 2018, then you can start by recoding your customizations as Extensions, and one by one removing them from the system.
You don’t need to use RapidStart for moving your data. You don’t remove the actual custom fields, before you have moved the data (with an install codeunit in the extension) into the new Extension fields.
First and foremost, I am not building one giant extension and have a design to follow about how old customizations should be converted to extensions by their functionalities.
I am not very much experienced with extensions but this is a type of a project to gain such and we want to pull this off with only building extensions and not with a side-by-side development mentality.
Since we want to go with only extensions, going the traditional way and keeping the custom fields might not do this for this case.
I was wondering what would be the best way to upgrade to 2018 while moving everything to extensions?
If you want to do everything as “one-big-bang” then the best way is hire a consultant/developer who have done it before!
I cannot recommend doing it like this, if it is “your first”. Unless of course you have already worked with AL Extensions in NAV for 3-6 months, but you state that you have not very much experience with extension.
I will repeat my recommendation:
upgrade your NAV 2015 to NAV 2018 in the “traditional” way. The only thing you should really change in the first step, would be to utilize events and move as much custom code to even subscribers as possible. And clean out anything you don’t need anymore.
Then after you have upgraded to NAV 2018, then you can start by recoding your customizations as Extensions, and one by one removing them from the system.
Eventually you could move isolated functionality, to get some experience working with Extensions. Work wise it’s going to be the same. In order to make your NAV 2015 customizations into NAV 2018 extensions, you would have to first upgrade it 1-to-to change to use subscribers. Then when your code is cleaned and upgraded to NAV 2018, it will be much easier to create the extensions. So you really don’t get around the traditional upgrade first. I’m just suggesting that you go live with NAV 2018, before you start your next step.
Or of course hire someone who have done it. [emoticon:c4563cd7d5574777a71c318021cbbcc8]
Since I should be the one doing this thank God nobody else got hired but the more I got involved with the project the more I understood what you mean and eventually, I managed with the path you provided.
I traditionally upgraded to NAV 2018 and then move customizations to extensions one by one and then move the data with install codeunits.