Did you know that there are entire companies that have gone out of business because their software did not upgrade well? I remember being on design committees with the Dynamics Great Plains teams in the old days and we were looking at Realworld and SBT’s accounting software. Once you modified their accounting software you were off the upgrade path and you had to recode all of your changes into the new version. Most (all?) of their clients didn’t bother renewing because they didn’t want to spend the same amount to upgrade as they spent for their original software.
These companies had no reoccurring revenues and were unable to compete. They are long gone. This was also tough for their clients for several reasons:
1) They are on old/unsupported software. Support becomes expensive or unavailable.
2) The ratio of Upgrading to Original implementation expenditure (U2O%) was $1/$1 and growing every year.
3) The software is usually part of a system and integration prevents updating any of the software as they all need to be upgraded at the same time.
We have seen AMS implementation where the vendor actually bids more than one dollar for each dollar original spend on Implementation and customization. We are not sure how this happens, but it should not take more than original bid to upgrade someone. I suspect that when the U2O% > 1 there is a revenge factor or the new folks aren’t quite as bright as the original folks?
Rarely do clients ask about “Cost to Upgrade” Everyone is thinking “today” and not “tomorrow”, but there are some very obvious and important reasons to lose sleep about “Cost to Upgrade” The goal is to keep upgrade costs to < 5% of the original implementation price.
So how do we survive upgrades?
1) Understand the new system.
So many times a customer will ask for modifications that in effect are aimed at turning the new system into the old system. Use the new system for a few months before you request modifications.
2) Keep modifications to a minimum.
3) Follow the manufactures API guide lines when modifying their solution.
Manufactures all develop API’s that will tell you how to modify their system to survive upgrades.
4) Only modify “thin slices” of your solution.
A thin slice is one very small incision made into your system for the purpose of integration or customization. Have the developer draw- up a Visio of how the customization will interface with your system. If you see more than a few lines, then question it. Do I really need all of those different connections going all over the place?
5) Look at price to upgrade while looking at price to purchase.
Ask to talk to references that just upgraded. Ask for references who did the upgrade themselves. When managing a new implementation, question each and every modification request.
6) Buy a system that was designed from the ground up to be upgradeable.
Altai has several AMS implementation where the clients do their own upgrades. For TASB, a 400+ user $1,000,000+ project that upgraded from v3 to V4 was $5000 in our fees. From V4 to 2011, TASB was able to do it themselves. We want to hear from you. What has your experience been with upgrades? sales@altaisystems.com
If you are interested in learning how Altai can leverage the Cloud to help your organization digitally transform and enhance your mission, click the link below:
