Advice and VAR to discuss Upgrade from NAV 4.03 to ?

emulsified

Forgive me if this is posted in the wrong place. I see that plenty of companies are running NAV 4.03 and 5 still in 2018!

I have a client using NAV 4.03 native database. I would like to have discussions with some VAR's regarding the best way to upgrade in the near future (1 to 2 years).

There are customized objects and an object pack that had been purchased from a developer that mostly contains customized reports in the vendors own object # range. There is also use of objects in the 50000 range.

15 user license currently
Only need about 10 concurrently as of this time
Native DB is 28gb
Server 2003 R2 OS

I need a VAR that knows what they are doing and doesn't need to spend hours of billable time "figuring it out" so to say.

Can anybody recommend any VAR's that are good at doing all the pre-req steps such as checking for custom objects prior to planning upgrade and giving options that are practical for a client who's employee base is mostly technologically challenged and have a "never change" attitude? Ha ha, that's everyone right? The environment is such that the employees comfort level is mostly catered to when it comes to Navision rather than utilizing the business logic in Navision, change is heavily resisted.

Any recommendations would be appreciated.

Slawek_Guzek

The "figuring it out" part is always required unless your installation is a clear and unmodified CRONUS based one. Which personally I have not seen yet, despite working with NAV for a looong time.

Each system modification is pretty much unique, systems were and are tailored to meet a set of specific client's needs. Sometime ISVs add-ons were used, most of the time custom modifications.

The analysis of the system is required to find out what has been modified, whether the modifications are still necessary in the new version, which modifications can be removed/ignored and replaced with new standard functionality, which needs to be carried forward, and if there are any how to upgrade them. A lot of things changed between older and newer versions, lots of system functions migrated from one object to another, changed signatures (parameters with which they are called from the code). Data structure changed between versions, sometimes dramatically, and you need to figure out if and how to transform the old data to the new format.

If you have NAV instalation on native database server then additional analysis should be done to find potential performance problems, or extra budget should be allocated for performance problem fixing after the upgrade.

This all is inevitable if you want the upgrade to be a successful and swift project, not a disaster and nasty pain in the bottom months and months after go live. If you skimp on pre-upgrade analysis you will spend a much much more money on addressing problems arising unexpectedly during upgrade, and even more on after go-live problems fixing. And after go-live you will have no option but to pay. Putting out fires is costly.

This analysis, proper analysis, is time-consuming, you need a senior class developers/analysts involved with a wealth of experience, so they can properly analyze your solution (not only the code differences but also what modification does and what for) and propose a good solution for you.

If you find someone, a partner who promises you "they've seen it all and don't need any analysis" before undertaking the upgrade project I would suggest avoid them.

Unfortunately some partners out there specialising in upgrades do only short-time code analysis to save time and money, and the upgrade they propose is simply a code merge exercise, where the modifications are almost mindlessly carried over, and the only changes they make is to make sure the old code is compatible with new system structure. Whether the modifications are required and if they can be done in a better way, more aligned with new system functionality, is far beyond either their interest or capabilities (or both).

Slawek_Guzek

@BlackTiger might be right, if NAV system to be upgraded is backdated quite a few versions, the re-implementation is often a cheaper option - if you can afford loosing the access to the historical transactions in productions system. In such scenarios often the old system is left in place intact to keep the historical transactions data in case they are needed. On the other hand reimplementation naturally gives a good chance to cleanse the data, don't bring into new system customers who are long gone, items no longer traded, etc

But despite choosing the upgrade path or reimplementation path the "figure it out" part is still required. I'd say in face of such decision the pre-upgrade analysis is needed even more because it gives you the information required to take the decision whether to upgrade or re-implement.

swpolo

@BlackTiger ,
I need to disagree wuth you.
If database is low customized ( as author said) upgrade is still possible and can be done in 1 week even from old NAV versions.
If you do NAV upgrade with transferring all customizations you save all historical data and all functionality - this is main advantage.
If you transfer just master data you lost transactions and need to recover old functionality. You save time on NAV upgrade, but you spend very LOT of time to recover yor customizations.

I have experience when a customer decided to avoid do stadard NAV upgrade and then spend a lot of money on new development. New development is always time and material projects an you never know the budget.

On my opinion you should first estimate efforts on standard NAV upgrade and then make your final decision.

PS: We can do it for you for free.

Slawek_Guzek

@swpolo the thing is that the 'free' service still costs the time and the money.

If you are running a proper business, not a charity organisation, you will need to:

1) make sure you can recover the cost somehow - for example by conducting the "free" analysis under a condition that the customer will select you as upgrade service provider. It this case the customer will pay for the analysis anyway, but the analysis will not be shown on the final invoice as a separate charge (and therefore We can do it for you for free is a false claim)

or

2) if you do not bind the "free" service with further upgrade you would need to limit the potential loss in cases when a customer orders the "free" analysis from you and then selects another partner to perform the upgrade.

In this case limiting costs means limiting time and expansive resources, like the time which a senior analysts/software architects/experienced developers need to take to analyse the customization properly. In consequence such analysis is very often limited to comparing the code base, often using some automated code compare tools, and reporting back to customer what has been modified.

This sort of analysis severely limits, if not excludes completely proper understanding of purposes and business process nuances served by the customization, and in result the upgrade means moving the code from old system to the new one - regardless the modifications are required or not.

Lack of understanding of customer's specific business processes leads to lack of means of proper testing of upgraded database.

For the reasons above a free analysis", at least for me, means increased risk of the upgrade project failure. Some customers may take it, some may not.

swpolo

@Slawek_Guzek
I need to agree with you that if a customer chooses our company for NAV upgrade, we include estimate to all project scopes and it is very low (less than 3 hours). This scope is fully fixed price and not changed for the customer.
The estimate does not require a lot of human time since we use internal tools for estimation of NAV upgrade. That's why this process is not so complicated for us and we can do it almost for free even if we lose particular project.
Since we make estimates with fixed price it is our side to exclude all possible risks.
Agree with you that some customers require a very detailed estimate with removal of unnesessary functionality and so on. This estimate requires much more time to complete and has another price.

We did more than 200 NAV upgrades and have deep experience in this area and we know most of possible risks. These upgrades are not technical only. Most of them are also included implemenataions and further support with final fixing-tuning if needed.
So all estimates are based on quality solution and guarantee NAV to be worked as in source NAV database.

Miklos_Hollender

Are you sure you need that 28GB data? In every Classic to RTC upgrade in our company group I offered people a clean start (like a new implementation, master data and opening balances) and they were happy to get rid of old mistakes. Of course not something to do with every upgrade. But once every ten or so years, and 4.03 is older than ten, when there is such a huge tech jump... treat it as a new implementation if they accept it.