Upgrade to NAV2009 SP1

RChurchill

Hi,

We are upgrading a customer to NAV2009 (from 3.60). Fairly extensive customisation.

We are approaching the end of converting the objects to NAV2009 and due to give the customer something to start testing with in a couple of weeks.

Now that NAV2009 SP1 is here, what should we do? They won't be using the RTC and use a Native database NOT sql.

Should we just let the go with NAV2009 or at this late stage go with NAV2009 SP1?

All advice would be most appreciated.

Thanks

matttrax

The customer paid for an upgrade to NAV 2009, not NAV 2009 SP1. Assuming your company properly informed them of the expected release date of SP1 they should get exactly what they paid for and have no complaints. If they want to move to an SP1 code base charge them for the time it will take you to merge the objects.

Alex_Chow

matttrax wrote:

The customer paid for an upgrade to NAV 2009, not NAV 2009 SP1. Assuming your company properly informed them of the expected release date of SP1 they should get exactly what they paid for and have no complaints. If they want to move to an SP1 code base charge them for the time it will take you to merge the objects.

I'd like to see the customer's reaction when you explain this to them.

If I was the owner, I would evaluation how much it would take to get the objects to 2009SP1. If not that much, I would eat the cost and put the customer on SP1.

matttrax

Obviously it should be evaluated on a customer by customer basis. If there were delays in the project or if things happened that were not the customer's fault, absolutely I would put them on SP1. While a pain, code merging is pretty easy.

Is it your call on what to do? I haven't worked for a partner in a while, but usually a member of "upper management" would make the call on whether or not to give something away for free...and with us it was usually yes

Alex_Chow

No, most of the time, it's not the developer or the implementor's call. That's why I put in "If I was the owner". I'd be pissed if someone within my company made that decision without my consent.

It's not profitable, but (in my opinion) it's the right thing to do.

DenSter

matttrax wrote:

Is it your call on what to do? I haven't worked for a partner in a while, but usually a member of "upper management" would make the call on whether or not to give something away for free...and with us it was usually yes

As the owner of a NAV partner company, Alex is speaking from a knowledgeable position, and he did specify "if I were the owner"

themave

Yes you should upgade them to SP1, I am an end user and went through this same thing with an upgrade from 2 to 4.

Service packs have a general timeline, but nothing specific, you are way more knowledgeable on the time frames then the customer ever could be, you should have started with the sp1 work when the objects became available. A customer could almost never upgrade to the current version under some of the responses here. let say they wanted to be on the most current version, so they we will have to wait until SP1 is released, so now you have to give a new quote based on SP1 objects, this takes a while, you give the quote and he approves it, and by this time SP2 is around the corner. It takes several months from quote to approval to actually time to begin testing at the customer.

If you give an estimate and you know the sp is coming out, you should account for it.

For us, our partner took the attitude, I quoted 4.0, not 4.0 sp1, and we were pissed, especially when several problems popped up after we were live, and the fix was in SP1, and we had to pay to downgrade the fix to 4.0 non service pack one. this is not a way to gain customer favor.

themave

matttrax wrote:

The customer paid for an upgrade to NAV 2009, not NAV 2009 SP1. Assuming your company properly informed them of the expected release date of SP1 they should get exactly what they paid for and have no complaints. If they want to move to an SP1 code base charge them for the time it will take you to merge the objects.

Mattrax, how would you have been able to give an accurate estimate to move to 2009SP1 back before it was realeased which is when the project started. you only knew a timeline for service pack 1, you had no idea what would be in it. so you could not give an accurate estimate to begin with. Also, the customer didn't know what would be in it either, so how could they make an informed decision about the upgrade. Plus service packs are supposed to be mainly bug fixes, so if they paid for 2009, and went through a massive upgrade from 3.6, they should at least be entitled to the bug fixes that are available when they go live. Otherwise you are knowning charging them for a bug ridden product. I am sure when it was quoted they weren't told they would be paying for known bugs, and if they wanted them fixed they would need to pay extra.

RChurchill

HI Guys,

Thanks for all your input. Most helpful as per usual.

DenSter

themave wrote:

Otherwise you are knowning charging them for a bug ridden product. I am sure when it was quoted they weren't told they would be paying for known bugs, and if they wanted them fixed they would need to pay extra.

To be fair here, when you quote an upgrade to the current version before an SP comes out, you don't always know which "bugs" are going to be fixed. At that time there are no "known bugs", and I would hardly call any of them "bug ridden", although the opinions vary wildly there

I get your point, and I agree that as an end user it is frustrating to get upgraded to a certain version at the same time that there is a better version available, especially if you don't know about it. If your organization had known about the timeline of the SP's, you would have been able to make an informed decision, i.e. upgrade to current and miss the upcoming SP, or wait until the SP comes out. The way that I see it is that when an upgrade is quoted, proper expectations should be set. So if I know as a partner that an SP is around the corner, I should let the customer know that this is happening, and explain the implications of upgrading now or waiting for the SP. I've been in many conversations about upgrades where customers knew full well that a SP was on its way, and they decided to upgrade to the current version anyway, knowing that the SP would come out before they'd go live with the upgrade.

At some point you have to make a decision to start the project, you can't wait for ever for SP's to come out. Saying that customers should always get SP's merged for free if they come out during an upgrade project is not a realistic thing to suggest, because it can significantly change the scope of the upgrade.

matttrax

Sorry Alex, my original "Is it your call..." was directed at the original poster. Just appeared that it was you since you had made the last post. Should have clarified

matttrax

DenSter wrote:

I get your point, and I agree that as an end user it is frustrating to get upgraded to a certain version at the same time that there is a better version available, especially if you don't know about it. If your organization had known about the timeline of the SP's, you would have been able to make an informed decision, i.e. upgrade to current and miss the upcoming SP, or wait until the SP comes out. The way that I see it is that when an upgrade is quoted, proper expectations should be set. So if I know as a partner that an SP is around the corner, I should let the customer know that this is happening, and explain the implications of upgrading now or waiting for the SP. I've been in many conversations about upgrades where customers knew full well that a SP was on its way, and they decided to upgrade to the current version anyway, knowing that the SP would come out before they'd go live with the upgrade.

At some point you have to make a decision to start the project, you can't wait for ever for SP's to come out. Saying that customers should always get SP's merged for free if they come out during an upgrade project is not a realistic thing to suggest, because it can significantly change the scope of the upgrade.

That's what I was going for. It just depends on what expectations were set at the start of the project. I have a weird view being a developer at an end user with a full partner license. Much different than an owner, or even developer at a partner. Plus I am literally outsourced to other companies under our umbrella and have to bill for my time...so bizarre.