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 ?
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.