I Appreaciate that Upgrade gnereally is a standard process however the 2018 version is different than the others prior.
What are the key points to cover a 2015 upgrade to 2018. Should I focus on try to move code to Extensions or more to event / Subscriber model ? Has someone a brief guide and experience ?
Follow the guide from Microsoft:https://docs.microsoft.com/en-us/dynamics-nav/upgrading-to-microsoft-dynamics-navBut you have to decide: There a two ways you can go1) Keep modifying the standard code as you probably have done in NAV 2015 (Using the Classic Development Environment) or
2) Recode everything as extensions using Visual Studio Code.DON'T try to do a mix of both, it is going to be a nightmare.
The process as such has not changed so much. I agree with Palle, that having a HYBRID with both customized standard code (and new C/SIDE objects) and customized Extensions is going to be much harder to manager, than a "clean" system with either C/Side or VSCode extensions. Each time you change C/Side code, then you need to rebuild your symbols, before you can continue extending it from VSCode. But that doesn't mean you should stay sharp away from it.
Some things are yet not possible in Extensions, like extending reports and option fields (it's on its way). And likewise some things are not possible in C/Side, like if you need to extend functionality from other extensions.
Which model is best for you and what should you do when upgrading to NAV 2018?
I would say that it depends on how customized your database is? Start (as always) by analyzing the changes. Is moving to extensions even possible, or are you doing things which are not yet supported?
Also look at how you can organize your extensions. The worst thing you could do, even if possible, is to put all customization's into one big Extension. Your extensions should be small and as specific as possible. If you have areas of similar functional changes, without any direct links to other customized functionality, then maybe you can group this together as one extension.
If you have a lot of (maybe undocumented) changes, then my recommendation would be that you should split up your upgrade in two (or three). Stay in C/Side when you upgrade to NAV 2018, but change everything possible to use event subscribers, use the standard events when possible, or add your own (but request MS to add them to the next version). Think extensions, but program it in C/Side.
If you only have minor changes and your are able to logical/functional group them, then you could go the full way to extensions.
Personally I didn't have a lot of changes in my own company NAV system. We had only changed about 10 tables, some codeunits, pages and a few reports, besides adding a few tables, pages etc. Actually very little changes and I'd already recoded everything possible to use event subscribers in NAV 2016/2017 (the missing events I requested were added in NAV 2018). If I had wanted to do it, then I could have changed everything to extensions, right when upgrading to NAV 2018 RTM. But instead I upgraded everything as-is (was already using subscribers) to NAV 2018 C/Side. I did that to minimize the risk of something going wrong. I briefly considered the HYBRID model, but after trying (crying) I reversed again.
When I upgraded to NAV 2018 cumulative update 4 in the spring, I moved had moved most of the changes into an extension. In this version I kept my old fields in C/Side, but had made functionality in the extension to copy the data from the old custom fields, into the new extension fields, while at the same time marking the old fields as obsolete.
Yesterday I finally upgraded to NAV 2018 CU8. Here my remaining changes where moved to another extensions and the obsolete fields deleted from the database. So as of NAV 2018 CU8 I'm personally on a "clean database", with only extension changes.
From my experience, and having a few heavily customized solutions out there, I would still do it the "smooth" way.
If you have modified standard table triggers, try to move your code to the beginning or the end of that trigger.This allows you to move the code to event subscribers.Keep your code with your fields and controls (I removed almost all code from there when Extensions v1 came out, it turns out to become a nightmare to move all code to codenits, especially when you have to buy them). This way you will have the chance to "transform" your customizations into an extension v2.
Try to get rid of all code modifications in all procedures in all standard objects (as far as possible) and move that code to subscribers in your own codeunits.The less modified code you have at the end, the better.
After this, try to identify customizations which are "granular", meaning that you identify all fields controls and business logic which solves a specific problem or enables a specific functionality.
When you identify such a granular customization, make a small extension from it and remove the code from the C/Side environment.You also need some code which moves the fields and tables from the customization to the extension.Remove the code from standard, install that extension and the accompanied data conversion routines and go on to the next granule.
This way you will clean up your solutions one by one, and it gives you the chance to reuse these "granules" easily with other customers.
You can try to test some automated upgrade tools: https://bit.ly/2Mn5nta