SmoothSpan Blog

Billy Marshall wrote recently about the “triple threat of legacy code”.  Billy is in the software appliance business, so he is arguing that dealing with legacy code is a compelling advantage for appliances, and he is right.  The software vendors he is speaking to are concerned about three threats legacy code presents to their business:

Higher Support Costs:  I’m very familiar with this one, having lived it.  Over time you wind up supporting a lot of different versions of the software for a lot of different reasons with conventional enterprise software.  It mostly boils down to the more choice you give your customers, the more choice they’ll exercise.  Forget customers being conscientious about staying current–some will, but the vast majority will not.  They’ll stay on whatever version they installed and got running until a compelling event happens. And why shouldn’t they?  After all, if it ain’t broke, don’t fix it.  Just one little problem: the act of doing nothing eventually breaks things for everyone. 

It gets harder and harder for the vendor to support the older versions.  Over time, 3rd party technologies the old version is dependant on become obsolete and unsupported.  Think old versions of the database, operating system, app server, and almost anything else.   For customers, they encounter bugs that are likely already fixed in the latest version and could’ve been avoided altogether had they stayed current.  Sometimes these bugs are quite serious.  Often there are ticking time bombs that a customer is certain to encounter if they stay with a release long enough.  Yet the idea that things are working is strangely calming and leads the customer to ignore warnings in release notes for later versions until they’re on the brink of some crucial event when it’s very difficult to roll in a new release.  This leads to hot fixes and other unsafe practices.  With enough patches, a customer can wind up on a version that is entirely unique to one single installation.  This is never a good place to be, but it’s all too easy to get there with the best of intentions.

Meanwhile, the mainline code base, the one the majority of new users are on, is moving further and further away.  Customers that make no effort to stay current are toting up a hidden cost that will one day come true.  The longer they wait, the more expensive it will be when they do finally have to upgrade.

Lower Revenue:  This is another familiar speed bump in the life of a conventional enterprise software company.  The Engineering group labors to produce a shiny new module that is much in demand throughout the installed base.  There’s just one problem:  it only works with the latest release of the flagship.  This one is maddening to customers and salespeople alike.  The salespeople want to know why the new modules can’t work with the old releases.  The Engineers roll their eyes and wonder how they’ll ever get the module built if they have to support so much legacy code.  Customers just want the new module without the high cost of a full upgrade, so they’re displeased and disillusioned as well.

Competitive Risk: This one is the worst.  You’ve got customers who’ve waited so long to upgrade that they now face almost a complete reimplementation.  Given the extremely high costs and pain associated with this, they naturally decide to repopen the entire decision cycle.  Suddenly they’re looking at whether they want to reimplement or replace. 

SaaS vendors avoid all of this by keeping customers painlessly current.  A virtual appliance can potentially do this if and only if the customer will allow the vendor to use the facilities of the appliance to keep them painlessly up to date.  A failure to do that means the customer is not on current code and an expensive migration will be required, appliance or not. 

While it’s doable in the appliance case, it seems considerably harder to me to manage than the SaaS alternative.  If nothing else, consider the requirements of sandboxing to make the transition easy.  There has to be some period when both systems are running in parallel.  The shorter this period can be, the easier for all concerned.  It’s not clear with an appliance how that gets orchestrated.  The  SaaS vendor can build this into their data center operations and use excess capacity to migrate a few customers at a time relatively automatically.  It seems like the virtual appliance is short machine capacity unless it is somehow prepared to flex that capacity for the purpose of the migration.  The reason is that the appliance is likely sized for the normal case of running the app, rather than the odd case of two versions of the app for a short time while things are migrated.

Savvy SaaS vendors I’ve talked to are using the Legacy Code situation as an opportunity to come in at the Competitive Risk stage when a customer faces a huge migration cost and offer them an alternative to go SaaS at that point.  Given the relative age of a lot of Enterprise Software that’s out there today, we should see steadily rising opportunity for this sort of thing as time goes on.  This also presents a cautionary tale to comapnies like Oracle that are bent on acquisitions.  If they rock the boat too much after acquiring a company, for example by requiring mass upgrades, they make themselves vulnerable to SaaS vendors and other competitors who want to swoop in at a moment of uncertainty and pain and gain converts.  If they keep support too broad, their internal costs will be higher.  It’s a Hobson’s choice for anyone in the Legacy Code business.