Previously, I had written an editorial that addressed deciding what to do with long-term clients in the context of applying the analogy of legacy systems to them: Do you upgrade them or do you get rid of them?

Of course, that got me thinking back to legacy systems themselves and again: Do you upgrade them or get rid of them?

One challenge of legacy systems is that the costs and risks of continuing to operate them outweigh their benefits. It’s typical that many end user clients won’t consider those equations until they start to encounter problems.

Issues with legacy systems will typically fall into three types: Operating costs are too high, it no longer meets their needs, or it requires older technology or expertise that is difficult to acquire, not to mention expensive, which loops back to the first point. To add insult to injury, some end user clients will have multiple legacy systems, each one requiring specific expertise to maintain. As time passes, they may be less able to meet the client’s needs, but time and money is spent maintaining them just because the initial investment in them was substantial.

So what should your clients do with their legacy systems? When discussing the path forward it’s important to present them with their options, and weigh the pros and cons in the balance.

With legacy systems you can keep maintaining them, you can update them or you can eliminate them entirely. As with anything, there are nuances to each option.

One popular option clients often take is to wait and do nothing until they have no choice. That comes with its own tasting menu of potential problems.

In the short term it’s cheaper to do nothing, but that may set them up for higher costs downs the road. “Pay the monkey now, or pay the gorilla later” is a phrase my old boss liked to say.

Another solution is to “wrap” the system. If, overall, the legacy system still meets the clients’ core needs, sometimes it’s worth updating the user interface, using what’s called “middleware” to make the user interface more updated and user-friendly, without changing the mechanics of the Band-Aid.

Wrapping is definitely a Band-Aid solution, it just happens to be a pretty Band-Aid. The basic problem — that the system can’t be easily upgraded — remains unsolved, however.

With more elaborate Band-Aid fixes, it gets more complicated to puzzle out whether or not fixes and patches are a good idea.

In a can-we-just-fix-it scenario the onus is on you, the AV pro, to puzzle out the cost/benefit equation for the fixes, ordered from most severe to least.

As you might expect, there will always be a point of diminishing returns, where the money the client is spending is no longer going to deliver enough value to justify the decision. After all, just because you can do something doesn’t always mean you should.

Also, with large and complex systems, and especially if they’re comprised of multiple sub-systems that integrate together, it’s seldom as easy as unplugging one old thing and plugging something new back in its place.
Making even one component change can have knock-on effects that need to be addressed, whether in the control programming or elsewhere. Think of that old maxim that “every solution creates two new problems.”

Eventually your client will reach the point where none of the proposed short-term fixes make economic sense anymore. That’s when it’s time to rip the whole thing out and replace it. When exactly that happens is going to be between you and the client.