Upgrading from Nav 4.0 to Nav 2018

Mathan

Hi everyone,

Can someone suggest the best path or approach to upgrade from Nav 4.0 to Nav 2018? Any advice would be gladly appreciated. Thanks in advance.

Mathan.

Slawek_Guzek

Code wise you can take two approaches - upgrade or reimplementation

Upgrade will require you to convert forms into pages, and do usual merge of customisations. Since you are quite far behind and there are significant changes in standard and lots of new functionality you may not be able, and likely you will not be able just to move customisation code. Yo would need to change calls to standard funtions as the things moved around, and reshaped. Classic example is dimension management.

Forthat reason you may be better off to reimplement the customisations using Cronus 2018 as a base, and geting rid of anythin which is now available in standard


Data wise there is no "one step" toolkit available so you would probably need to upgrade in steps 4 -> 6R2 (or 5) -> 2013 (or 2015) -> 2018. The trouble is that you would have to prepare intermediary 'half merged' tables as they were in those versions, to make standard upgrade toolkit work (+add of course upgrade code handling your custom fields)

Another possibility is to build your own upgrade tookit using all 4 standard toolkits as a base, and merging steps (where possible)

Yet another option is re-implementation - don't do full data upgrade but start over as if you were implementing brand new system. Bring in from the old one only master data (G/L Accounts / Customers, etc) and opening balances, prepare and repost unpaid invoces etc.

That's what available.

My personal preference on code upgrade path is re-implementation of customisations in Cronus 2018, and getting rid of everything which can be done in standard. If your business processes can be changed try to push them to fit in standard as much as possible. After all if you bring all ther modifications your new system will work exactly as the old one - what's the point of upgrading then?

Data wise I cannot recommend anything. It depends how much do you rely on historical detailed postings being on-hand available (rather than being kept in separate database), if your business can start fresh from opening balances, how much data do you have, etc.

Slawek_Guzek

Code wise you can take two approaches - upgrade or reimplementation

Upgrade will require you to convert forms into pages, and do usual merge of customisations. Since you are quite far behind and there are significant changes in standard and lots of new functionality you may not be able, and likely you will not be able just to move customisation code. Yo would need to change calls to standard funtions as the things moved around, and reshaped. Classic example is dimension management.

Forthat reason you may be better off to reimplement the customisations using Cronus 2018 as a base, and geting rid of anythin which is now available in standard


Data wise there is no "one step" toolkit available so you would probably need to upgrade in steps 4 -> 6R2 (or 5) -> 2013 (or 2015) -> 2018. The trouble is that you would have to prepare intermediary 'half merged' tables as they were in those versions, to make standard upgrade toolkit work (+add of course upgrade code handling your custom fields)

Another possibility is to build your own upgrade tookit using all 4 standard toolkits as a base, and merging steps (where possible)

Yet another option is re-implementation - don't do full data upgrade but start over as if you were implementing brand new system. Bring in from the old one only master data (G/L Accounts / Customers, etc) and opening balances, prepare and repost unpaid invoces etc.

That's what available.

My personal preference on code upgrade path is re-implementation of customisations in Cronus 2018, and getting rid of everything which can be done in standard. If your business processes can be changed try to push them to fit in standard as much as possible. After all if you bring all ther modifications your new system will work exactly as the old one - what's the point of upgrading then?

Data wise I cannot recommend anything. It depends how much do you rely on historical detailed postings being on-hand available (rather than being kept in separate database), if your business can start fresh from opening balances, how much data do you have, etc.

Mathan

Thank you soo much for the detailed response, Based on your suggestion, I really do believe that re-implementation is the best option rather than upgrading the code. Regarding the Data upgrade its just as you stated, Need to check up on all the things. I do have a couple of things to ask.

1.) Is there an Online version of nav available? If so can we upgrade from Nav 4.0 to a Nav online version just the way you suggested.

2.) Is it possible to upgrade from Nav 4.0 to Microsoft office 365? If so, will the 'code' or 'data' upgrading steps be similar? Or do we have do a re-implementation on this case?

Slawek_Guzek

I am not a cloud fan I'm afraid, and don't know for sure.

There is nothing dedicated for lower versions, but I guess you couls spin up vitrual machines on Azure, virtual SQL Server, and install old NAV on those. Then you would need to move and restore backups somehow.

Never tried this myself in the cloud, but we do have all the stuff virtualized (in VMWare though).

For NAV2018 I am not sure if it is avalable yet. It is supposed to be as far as I know.

For the Office 365 Business Edition you would have to reimplement your customisations as extensions, as far as I understand latest MS trends. Which is quite a limiting factor in my view. Aslo interfacing with other on-premises systems, if you have any, migt be challenging.

As for bringing in the data from on-prem NAV to - not sure how to approach this too. Export data on prem into files (CSV? XML?) and import them into D365 perhaps?

I am quite sure that there are cloud fans / specialists here on Mibuso, so perhaps someone will chime in.

bhaydon

We just did this move with a partner from Nav 4 to Nav 2017 cloud based.

Nav feels like a product in transition at the moment, so I'm not enamoured with either the web or win client vs Nav 4, but the integration with Excel is useful, and rapidstart is superb for mass editing data outside of Nav. We used rapidstart to get all the data in. There are some practical limits with the amount of data to load in with rapidstart - I found about 10,000 lines of Item table data batched was best, some tables with less attributes might be double that - though the constraint might be on the hosting side since I have no idea resources they give.