To Upgrade or Not to Upgrade

That's the question.

It's about two years ago since I started working with Liberty Grove Software, a certified upgrade service center. I've helped them establish a european office. Since that time we've done about 12 upgrades together.

Upgrades has always been a problem in the Navision world. The methodology is there and clear. The problem is not the methodology but the nature of Navision.

Navision is a very flexible development environment which easily allows bad development. Since Navision is easy to learn and real developers are hard to find, a lot of bad code has been written by people who shouldn't have tried.

The question of weather or not to upgrade can (IMHO) be answered by answering the question: "How much code is in the database that should not be there".

No matter what version you some from: If the customisations where done, the way they supposed to be done, anyone can upgrade the database, even if that one does not know the modificatios or the customers business.

So the next question is: how do you find out if there are these kind of modifications in the database.

This is a very hard question to answer. Most upgrade service centers have a list of versions and modifications which are dangerous like

  • Use if bincode in older versions (replaced by WMS)
  • CRM in 2.6
  • Jobs to 5.0 from older versions
  • Item tracking in 3.x

But these are the easy ones. I've seen:

  • Abusing standard Navision fields for other functionality instead of adding fields
  • Modifying ledger entries wihtout the posting routines
  • IF INSERT THEN DELETE statement in OnDelete trigger (As workaround for flowfields on Native)
  • COMMIT in middle of posting routine

So if you are considering an upgrade, start with a health check of your system. This will give you valuable information that helps in the decision of uprading or reimplementing. Some systems should not be upgraded.

Another issue is performance.

Most customers think that to go to SQL, a full upgrade is enevitable. This is not true.

A lot of customers started on 2.x 10 years ago and are very happy with the functionality. The system is customised to their needs and legal changes have been built in or downgraded. But what to do when the company or database grows.

Good news. A 2.x database is very suitable to run in a SQL2005 environment. The datastructure is much simpler compared to 3.x and higher. If performance is an issue and the functionality is solid than a SQL upgrade is your thing. This will also provide Vista and Terminal Server 2008 support.

Off-cource, a technical review and benchmark is required for a safe project

Comment List