Best strategy to prepare for future upgrades

themave

We currently have Navision 4.0 and are making customizations to the database to better fit our company. But, as I have been thinking about a future to Nav 5.0 and beyond. I have been trying to figure the best thing to do now to prepare for that.

I am thinking the customizations should be done using new fields and new code units, ect, as much as possible, rather then change existing code. This way the standard code should be easier to upgrade, if it is untouched, it should not require anything, and then we just have to review existing customizations to see what we want to carry forward.

What is your opinion of customizations and upgrades ?

As we look at add-on's for credit card processing and e-ship ect. I was wondering do add-ons typically use there own forms, codeunits, ect, or do they modify existing code. How hard does having an add-on affect upgrades between major version of Navision.

nunomaia

In http://dynamicsuser.net/files/12/nav_of ... y1842.aspx you have a good document about that.
The document is also in the Parnersource.

nunomaia

Document well were the standard has changed and why has changed. It’s common to forget why you have changed that peace of code.

themave

nunomaia wrote:

In http://dynamicsuser.net/files/12/nav_of ... y1842.aspx you have a good document about that.
The document is also in the Parnersource.

I read the tech ed document, it was more of a how to approach an upgrade, rather then how to minimize upgrade cost. and I am an end user, so no access to partnersource.

Reading the tech ed doc above is what generated my question. one of the first things they say to do is to compare customized old version objects with base non customized objects.

So, to expand the questions, is it better to use new objects and maybe pay a little more for the current custimizations, then to modify existing objects and pay more later to upgrade.

We just went through a 2.0 upgrade to 4.0, and it was very expensive, now trying to just upgrade to SP1 or SP2 is a whole nother major hasle. I am trying to determine ways to minimize this, so that we can continue to upgrade to the newer versions, What I am starting to think, is it is going to be so costly to upgrade to 5.0, that we never will. and maybe we are just better off accepting that, and make the current 4.0 the best we can without worry about 5.0.

nunomaia

Heavy customized Navision implementations it’s quite common. Many businesses processes are too specific to be coverage by add-on.

The add-on approach it’s a good solution, because the customer will implement a proved solution and the normally it’s well documented the have partner and tools to make easy upgrades. The add-on owner will become responsible to upgrade his add-on to future versions. The final customer hasn’t to worry about making again the merge with the standard.

For some business it’s difficult to update to every new versions. Some customizations can take several months to a year to customize,, so it can be prohibitive to upgrade to every new version.

The new object approach is the way to go, because the Microsoft upgrade tools will move the standard without any problems.

The upgrade to 5.0 version, it’s better to wait for service pack 1 or 2, because it seems to have many new features and need some time to correct new bugs.

Savatage

[quote="themave What I am starting to think, is it is going to be so costly to upgrade to 5.0, that we never will. and maybe we are just better off accepting that, and make the current 4.0 the best we can without worry about 5.0.

[/quote]

I hear ya! - We love our Navision 3.7 product but our company had determined that the upgrade isn't worth the cost at this point. The decision makers believe in "if it's not broke , don't fix it." We have everything working great, just what we need w alot of little custom changes here & there. We'll probably be stuck at this version for a long while, but it's a nice place to be stuck.

ara3n

That's good to hear Savatage. Because I'm thinking that in ~5 years? It would be a lot cheaper to just do a re-implementation than upgrade all the code to whatever language Dynamics product is going to be.