Dynamics Nav 4.0 Enhancement Plan
videsh
Member Posts: 32
Hi
Our company is still using Microsoft Dynamics Nav 4.0 (no service pack installed) for which we still pay the yearly enhancement plans. Looking at the Microsoft Product LifeCycle, I find these info for the above product.
Product Release: Dynamics NAV 4.0
Main Stream Support End Date: 12/01/2010
Extended Support End Date: NOT APPLICABLE
Service Pack Support End Date: 09-01-2007
Can anyone help advise whether it is necessary or there is a need to pay for this renewal plan ?
However, every now and then, we still seek assistance from our consultant to customise some objects on some operational and financial modules without buying new objects for these developments.
Thanks for your help
Regards
Videsh
Our company is still using Microsoft Dynamics Nav 4.0 (no service pack installed) for which we still pay the yearly enhancement plans. Looking at the Microsoft Product LifeCycle, I find these info for the above product.
Product Release: Dynamics NAV 4.0
Main Stream Support End Date: 12/01/2010
Extended Support End Date: NOT APPLICABLE
Service Pack Support End Date: 09-01-2007
Can anyone help advise whether it is necessary or there is a need to pay for this renewal plan ?
However, every now and then, we still seek assistance from our consultant to customise some objects on some operational and financial modules without buying new objects for these developments.
Thanks for your help
Regards
Videsh
0
Comments
-
Overall it means that product support has REALLY come to an end and MS REALLY stopped support for the product (no service packs, hotfixes, partner support,...). There is no obligation to pay for the Enhancement Plan but the main reason for paying it is (besides other goodies) to get product upgrades/new versions free of charge and support from the principal. It seems that your partner company is doing a lousy consulting job...0
-
Just by the fact that their customer is still using NAV 4...0
-
rhpnt wrote:Just by the fact that their customer is still using NAV 4...
Lots of clients still run NAV 4, or even earlier versions, and are still quite satisfied with their NAV partner. You ever think that maybe the partner has proposed upgrading but the client has not funded the project?There are no bugs - only undocumented features.0 -
...and that their customer is on a forum asking for explanation something he should be asking them.0
-
rhpnt wrote:...and that their customer is on a forum asking for explanation something he should be asking them.
I still would not draw such a sweeping conclusions. Maybe he did ask the partner and is just looking for confirmation.There are no bugs - only undocumented features.0 -
Sure they are, until the moment they feel the need for a functionality which is not supported in that version - then the s#%t hits the fan.bbrown wrote:Lots of clients still run NAV 4, or even earlier versions, and are still quite satisfied with their NAV partner.
An upgrade is not a matter of proposal or even customer decision. It is something the customer HAS to comply with. He has agreed to the terms of usage for the product by signing the license agreement and should be advised on the lifecycle of the product at the beginning of the project. Sadly those things are the least importand part in a ERP project - the ones that always count are the price, discount and the partner service contract.bbrown wrote:You ever think that maybe the partner has proposed upgrading but the client has not funded the project?0 -
rhpnt wrote:
Sure they are, until the moment they feel the need for a functionality which is not supported in that version - then the s#%t hits the fan.bbrown wrote:Lots of clients still run NAV 4, or even earlier versions, and are still quite satisfied with their NAV partner.
An upgrade is not a matter of proposal or even customer decision. It is something the customer HAS to comply with. He has agreed to the terms of usage for the product by signing the license agreement and should be advised on the lifecycle of the product at the beginning of the project. Sadly those things are the least importand part in a ERP project - the ones that always count are the price, discount and the partner service contract.bbrown wrote:You ever think that maybe the partner has proposed upgrading but the client has not funded the project?
While I may agree with some of what you are saying, I strongly disagree with the blanket conclusion that it's solely the partner's fault. Based solely on the context of the original post. Remember that these are business relationships. The client bears as much responibility to make it work.
There is no "requirement to upgrade". There may be reasons for cleint to upgrade, but there may also be valid reasons for other clients not to. And yes, cost will always be a factor in client decisions. (note that I said cost and not price)There are no bugs - only undocumented features.0 -
rhpnt wrote:
A forum is not the place to ask for confirmation on licensing matters. Another partner should be ask for a statement or MS directly.bbrown wrote:I still would not draw such a sweeping conclusions. Maybe he did ask the partner and is just looking for confirmation.
Licensing information is in the public domain, so why would it be inappropriate to ask questions about it in a public forum?There are no bugs - only undocumented features.0 -
Guys
I understand your points and most of them make sense depending where you stand. I thank you a lot for that.
However, in our case, it is neither a question of our company refusing to accept the consultant's offers or having the fund.
Anyway, the consultant did not propose new upgrades. On our side, it was not a priority either but a consultant's job is also to inform that products will be desupported and require upgrade.
I wanted an independent view of this situation and I guess this forum is the best to get an answer. This would help me estimate the cost/benefit of this renewal plan if i'm not planning to buy new objects.
Thanks and regards
Videsh0 -
I disagree. It's the partner company that has proposed to implement the software in the first place and it's the partner company who is responsible that the sale, implementation and aftersale services comply to the "rules of engagement" of the principal company (owner). As you wrote - these are business relationships and in such there are no mixed responsibilities. Everything is usually clearly defined in contracts. Sadly, many partner companies fail to provide the basic info regarding those rules to the customer - on purpose or not?bbrown wrote:While I may agree with some of what you are saying, I strongly disagree with the blanket conclusion that it's solely the partner's fault. Based solely on the context of the original post. Remember that these are business relationships. The client bears as much responibility to make it work.
Sure, no one can force anyone to do anything - but don't complain afterwards either. I can't think of no "valid" reason for not doing an upgrade except that the customer maybe saves a little money which is afterwards lost when the competition starts using functionality provided in new versions. There are no "costs" in an upgrade project. There are only benefits and profits.bbrown wrote:There is no "requirement to upgrade". There may be reasons for cleint to upgrade, but there may also be valid reasons for other clients not to. And yes, cost will always be a factor in client decisions. (note that I said cost and not price)0 -
You can't plan on not buying objects - you don't know what the future will bring, what the competitors are up to, what other business branches your company will acquire, what technologies will emerge,... - you have to be prepared for those things. An expired version of NAV is certainly not a good starting point for that...videsh wrote:This would help me estimate the cost/benefit of this renewal plan if i'm not planning to buy new objects.0 -
videsh wrote:This would help me estimate the cost/benefit of this renewal plan if i'm not planning to buy new objects.
One of the most common issues with our customers who have chosen to lapse on enhancement is when it comes time to buy new computers, and the operating system they choose can't run older version. Certainly there are ways around it for now, but I have to imagine eventually there will be a point where 2.6, 3.6, 4.0 just can't be run period. Then you have to choose to upgrade, or find a new ERP. Having to swallow the cost of the upgrade after being forced to purchase new hardware as their machines die is a more difficult decision.
Just thought I would add my 2 cents.0 -
rhpnt wrote:There are no "costs" in an upgrade project. There are only benefits and profits.
I disagree and I can give you a real world examples. NAV 2009 licensing guidelines state specifically that any system outside of NAV that accesses NAV data must have its users licensed for access to NAV, albeit on a cheaper user price. There is nothing to force a company to do it, but it is the right thing to do. There is nothing to grandfather companies in either, so a reporting solution outside of NAV that was in existence before the upgrade, suddenly has to be licensed and paid for separately, even though there is no new functionality, nothing gained, to the tune of about $50,000. That $50,000 does not buy them a single new feature.
There have also been talks about forcing old modular based licenses onto business ready licensing. Again, same company. They own practically every module in the system. They get hardly anything by switching to business ready licensing, but the transition would cost them over $100,000 to do it. And again, little to no new functionality that they want to use.
A small company on the native database that has no expansion plans and does not need new functionality at the moment. Forced to upgrade to SQL Server and pay licensing for it.
Benefits are different than profits. And you only get either of them if you have a use for the new functionality. Not every company needs web services, or kitting, or whatever comes out with every release. I'm not saying customers should not pay maintenance, they absolutely should. But they should not incur the additional cost of an upgrade (partner services like code merging and testing, time lost by employee testing and deployment) unless there is a reason for it, one of those being that the version of their product is no longer supported. To say that there are no costs, or that every customer should upgrade every time a new service pack or version comes out is just bad advice.
Back to the original point of this thread. Is there a need to pay for enhancement? Do the cost benefit analysis. It is 16% / year, so it takes 7 years to break even. At that point you would buy the software again and it would have been cheaper. If you know for a fact (which you don't) that you will not need to add ANYTHING to your license for seven years, then don't pay it. If you don't pay it, and determine that you do need something, you will have to back pay it plus penalty fees. My advice is to almost always pay it.0 -
Confessions of a Dynamics NAV Consultant = my blog
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book0 -
Ok, here we get back to the very start of a software implementation project. The SLA is the key to what the customer gets by acquiring one. He must be fully briefed and has to accept the licensing terms which leave everything open for the future. Most of the companies I got to know in my NAV ERP time were convinced that they own NAV and so can do whatever they want with it.matttrax wrote:I disagree and I can give you a real world examples. NAV 2009 licensing guidelines state specifically that any system outside of NAV that accesses NAV data must have its users licensed for access to NAV, albeit on a cheaper user price. There is nothing to force a company to do it, but it is the right thing to do. There is nothing to grandfather companies in either, so a reporting solution outside of NAV that was in existence before the upgrade, suddenly has to be licensed and paid for separately, even though there is no new functionality, nothing gained, to the tune of about $50,000. That $50,000 does not buy them a single new feature.There have also been talks about forcing old modular based licenses onto business ready licensing. Again, same company. They own practically every module in the system. They get hardly anything by switching to business ready licensing, but the transition would cost them over $100,000 to do it. And again, little to no new functionality that they want to use.
If you go for a IT related product such as an ERP system you have to consider that it will change in it's lifecycle and that the acquisition was just the starting investment.matttrax wrote:A small company on the native database that has no expansion plans and does not need new functionality at the moment. Forced to upgrade to SQL Server and pay licensing for it.
That's the point. If the ERP implementation project is done right from the start and continues so through its lifecycle then the upgrade is a smooth process with no additional costs/time lost for the customer.matttrax wrote:Benefits are different than profits. And you only get either of them if you have a use for the new functionality. Not every company needs web services, or kitting, or whatever comes out with every release. I'm not saying customers should not pay maintenance, they absolutely should. But they should not incur the additional cost of an upgrade (partner services like code merging and testing, time lost by employee testing and deployment) unless there is a reason for it, one of those being that the version of their product is no longer supported. To say that there are no costs, or that every customer should upgrade every time a new service pack or version comes out is just bad advice.0 -
rhpnt wrote:
Ok, here we get back to the very start of a software implementation project. The SLA is the key to what the customer gets by acquiring one. He must be fully briefed and has to accept the licensing terms which leave everything open for the future. Most of the companies I got to know in my NAV ERP time were convinced that they own NAV and so can do whatever they want with it.matttrax wrote:I disagree and I can give you a real world examples. NAV 2009 licensing guidelines state specifically that any system outside of NAV that accesses NAV data must have its users licensed for access to NAV, albeit on a cheaper user price. There is nothing to force a company to do it, but it is the right thing to do. There is nothing to grandfather companies in either, so a reporting solution outside of NAV that was in existence before the upgrade, suddenly has to be licensed and paid for separately, even though there is no new functionality, nothing gained, to the tune of about $50,000. That $50,000 does not buy them a single new feature.There have also been talks about forcing old modular based licenses onto business ready licensing. Again, same company. They own practically every module in the system. They get hardly anything by switching to business ready licensing, but the transition would cost them over $100,000 to do it. And again, little to no new functionality that they want to use.
Correct, the client does not "own" their copy of NAV. They've only acquired a "right to use" license. This is true of any software package. However, you seem to be inferring that the SLA sets a requirement for the client to regularly upgrade. Could you post the specific SLA language that sets this requirement?There are no bugs - only undocumented features.0 -
So you upgrade all of your customers for free? You don't make them pay for the time to merge code between versions? Pay for the time to see if they have a customization that is now covered by the base product? Apply every hot fix to every customer as they come out? Transform forms to pages? Old reports to RDLC? The customer doesn't test out the new version instead of or in addition to their normal duties? Spend time evaluating the new version before committing to an upgrade?rhpnt wrote:If the ERP implementation project is done right from the start and continues so through its lifecycle then the upgrade is a smooth process with no additional costs/time lost for the customer.
That wasn't what you said before. You said "There are no "costs" in an upgrade project. There are only benefits and profits." But in this statement you are saying that the customer should expect additional costs. These are examples of direct costs that add no immediate benefit and don't allow the company to profit more unless they change their business. You can put quotes around costs all you want, it doesn't change what it means. Please tell me how that $50,000 was not an additional cost of the upgrade and how getting nothing new for it allowed the customer to benefit / profit.rhpnt wrote:Ok, here we get back to the very start of a software implementation project. The SLA is the key to what the customer gets by acquiring one. He must be fully briefed and has to accept the licensing terms which leave everything open for the future...If you go for a IT related product such as an ERP system you have to consider that it will change in it's lifecycle and that the acquisition was just the starting investment.
Usually I can always understand both sides of a discussion, but not here. I don't know how you can lump every single NAV customer into the same pile. Every customer has unique business needs, which may or may not fit with a pre-defined upgrade path.0 -
I think the big problem is enhancements are typically not done with future upgrades in mind.
This is a problem that we all (Microsoft included) need to address and start planning upgradeability into the lifecycle.
I prefer not customize standard reports - my preference is to copy them to a custom range and modify them there.
Card forms are more complicated - pages have a big advantage since fields cannot accidentally overlay other fields.
Anytime there has been a big rewrite or replacement of an old area (like jobs) where there is a lot of customization, upgrades become much more complicated since it is not a straight functionality move any more - and this will always remain a problem.
However, if we can make our mods with upgrades in mind, we can make it simpler and less costly for our customers to keep up to date - which will be good for all those who are already paying or it in annual maintenance plans - and make Microsoft happy since they will be more likely to stay on the maintenance plans.David Machanick
http://mibuso.com/blogs/davidmachanick/0 -
Well, if 4.0 works, then it works. A navision upgrade can require a significant amount of effort. If you plan on staying on 4.0 forever and have no desire to ever upgrade then sure... you could stop the licensing, but I think Microsoft is gonna ding you if you decide to try to restart the program.0
-
And you plan never to upgrade any of your operating systems, Office, etc.
NAV2009R2 is the last version supporting Classic, so you can do a technical upgrade for minimal cost, and if you stay on maintenance, you will get platform upgrades - until 2019 or so if I understand how extended support works.
Then you may end up doing a software migration because an upgrade may be too painful.David Machanick
http://mibuso.com/blogs/davidmachanick/0 -
ok
thanks a lot for your help.
Just 1 more question. Is there any consultancy service incuded in this enhancement plan like free installation of new service packs ?
Thanks and regards
Videsh0 -
I never wrote that. BREP delivers objects for free the implementation services are settled between the partner and the customer.matttrax wrote:So you upgrade all of your customers for free?
If the current version is more or less standard then there is no need to do that. Less modifications = less merging.matttrax wrote:You don't make them pay for the time to merge code between versions?Pay for the time to see if they have a customization that is now covered by the base product?
Yes, whenever possible.matttrax wrote:Apply every hot fix to every customer as they come out?
The services impact of the versions to come has to be included in the long term TCO strategy plan on both sides - partner and customer.matttrax wrote:Transform forms to pages? Old reports to RDLC? The customer doesn't test out the new version instead of or in addition to their normal duties? Spend time evaluating the new version before committing to an upgrade?
Maybe this will straighten things out - in an upgrade project there are only payables. What I mean by that is that an upgrade is a normal thing to do and it must be included in the long term ERP budget at the start of the implementation project.I dare to say that 99% of the NAV partners of which projects I came across or took over failed to do that and so an upgrade project was always considered as big, expensive and something the customer does not want to bothered with in the first place.matttrax wrote:That wasn't what you said before. You said "There are no "costs" in an upgrade project. There are only benefits and profits." But in this statement you are saying that the customer should expect additional costs. These are examples of direct costs that add no immediate benefit and don't allow the company to profit more unless they change their business. You can put quotes around costs all you want, it doesn't change what it means. Please tell me how that $50,000 was not an additional cost of the upgrade and how getting nothing new for it allowed the customer to benefit / profit.
I understand that, because (based on your writing) you are looking at this matter mainly from the technical sidematttrax wrote:Usually I can always understand both sides of a discussion, but not here.
I have to because every single customer agrees to the same SLA, gets the same basic NAV version and localization. No customer gets a special treatment from MS.matttrax wrote:I don't know how you can lump every single NAV customer into the same pile.
It always has to fit (it always does) and it's the partners job to keep it this way.matttrax wrote:Every customer has unique business needs, which may or may not fit with a pre-defined upgrade path.0 -
Nobody ever plans for an upgrade because everyone only cares about the now. It's hard to forsee what changes your business will require in the next 5 years vs. the expense that you'll be paying every year that may/may not affect your cash flow.
It's not uncommon that the owners would rather spend that money on a new BMW or new kitchen than pay that to Microsoft. Frustration only arises when there's that "oh shit" factor (i.e. they can't use Windows 7).Confessions of a Dynamics NAV Consultant = my blog
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book0 -
Exactly!0
-
Hi all
Thanks a lot for your advices and for this i-thought-never-lasting-debate but enriching one.
Thanks and regards
Videsh0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.7K Microsoft Dynamics NAV
- 18.8K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 328 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
