The Final Straw: Why Companies Replace Once-Beloved Technology Brands

What causes a business to abandon hardware, software, or tools it once relied on? Enumerating the common reasons helps you recognize when it’s time to move on.

Once upon a time, your company ran Lotus 1-2-3 and WordPerfect on Novell servers, wrote its custom applications in Turbo Pascal and Visual Basic, and used Nortel or Cascade Communications to connect to the nascent Internet, which you still unapologetically described as the Information Superhighway.

Don’t snort in derision. Your business relied on those tools and technologies because they worked. Users knew the product’s features. IT support understood its configuration foibles. The budget was predictable, and those vendors were trustworthy, safe choices.

But life moves on. Despite company and user loyalty, at some point, someone chose to replace that software, hardware, or infrastructure with something else. What made the business stop using them?

This isn’t an idle #GetOffMyLawn contemplation. Change management is a regular concern for CIOs, IT managers, and the CFOs who glower at them. The best way to determine, “Is it time to abandon this known supplier?” is to contemplate why enterprise organizations left behind the established brands of their past.

Companies usually hold onto existing hardware, software, computing environments, programming languages, databases, or whatever, let’s call it the Turbo Encabulator, for as long as possible. This is supported by file formats, established workflows, supplier contracts, and other elements that contribute to corporate inertia and technical debt.

Eventually, a “final straw” tips the balance, and the organization commits to a transition. “That does it!” they say. “It’s time to switch.”

Here’s how I categorize those final straws, which may operate singly or as part of a hay bale.

There are two kinds of fools. One says, “This is old, and therefore good.” And one says, “This is new, and therefore better.”
Dean Inge

Functionality. It no longer does what you need. Or it doesn’t do it the right way.

The ideal scenario is the path of innovation: Better products replace obsolete ones.

In that situation, the Turbo Encabulator’s once-unique capability becomes commonplace. Now, another supplier has useful, new, and attractive features. Those capabilities may be related to product operation rather than product function, such as vastly improved performance, trustworthy security, better automation, or other “how it works” stuff.

Organizations have to be careful when they seek new functionality, warding against buzzword snipe hunts (surely you don’t need examples of AI-infused anything?). Just because the functionality is new doesn’t mean it’s relevant and valuable.

Quality. “Good enough” is no longer good enough.

When the user experience sucks, it’s time to look for alternatives.

The predictable examples: New versions are buggy. Connectivity fails. Reliability falters. Tech support is slow, incompetent, or difficult to access. You can’t find a knowledgeable human to answer questions.

Less obvious quality failures: A new version is too different. New features make the user experience inefficient, complicated, or disorganized. For instance, the new Turbo Encabulator Pro changes its dashboards or APIs, so experienced users must relearn how to interact with them. The vendor repeats this error with the next version, too. Hosting companies turn “Where to modify DNS records” into a scavenger hunt. Or the vendor dumbs down the Turbo Encabulator features to cater to non-tech-savvy users, obfuscating the system for experts.

Integration issues. The leg bone no longer connects to the thigh bone.

Plenty of businesses can and do hold onto vintage computing technologies because those internal systems don’t need to talk to anything outside the company. For instance, the San Francisco Muni Metro light railway, launched in 1980, boots its Automatic Train Control System from a floppy disk. And companies stay with older versions of operating systems as long as they can find printer drivers. That’s fine- until it isn’t.

Eventually, business and technical standards move on. For instance, a business may be compelled to migrate to a new system when the only way to connect to a data provider is with an API that the Turbo Encabulator does not support. Application changeovers got underway when clients demanded Word files even though the company was internally happy with WordPerfect.

Environmental shifts encourage other migrations. The decision to change one element causes people to reconsider the overall architecture. When companies adopted Windows, they often changed application vendors (from Lotus 1-2-3 to Microsoft Excel). When enterprise organizations moved to cloud environments, they considered alternative suppliers that had grown up with the Internet rather than wait for an established provider to scramble to keep up.

Loss of confidence in the provider. When trust disappears, it’s over.

It’s common for customers to jump ship when a provider is in financial or other trouble. Management shakeups, tech leadership changes, and product cancellations are tip-offs. So are missed ship dates.

Mergers and acquisitions make businesses nervous. Look at the uncertainty when Broadcom acquired VMware, accompanied by layoffs and fears about dismantling product lines. [CJ1] 

‍

The lack of confidence may not directly relate to a supplier’s financial future. The company could change AI data collection policies or data sharing practices (such as Sonos), drop its support for open source (as Redis did), change the structure of enterprise licensing, or publicly engage in corporate drama.

It could be personal, too, such as when a reliable technical contact jumps ship to a competitor. 

Price. The cost goes up significantly without adding value.

Money is the obvious reason. It’s easy to connect cost issues to the organization’s bottom line. If a product isn’t worth the investment, a replacement is justified. You might put up with other problems, but if it costs too much? Game over.

Cost concerns drove enterprise acceptance of open source. Techies extolled the open-source advantages in features and support for years. Yet, the corporate transition to Linux occurred only after financial decision-makers realized the significant savings they could achieve.

Need examples? I know one team that switched project management systems when the entrenched application – for which staff had created dozens of integrations and other customizations – raised its licensing fee to double that of a perfectly adequate competitor. Nobody needed any of the “new and improved” features. Variations: Unity’s price increase was so egregious that it had to roll it back. The photo-sharing site Flickr’s subscription model changed so much that, for a while, it couldn’t even attract free subscribers.

Peopleware. Decisionmakers make political or emotional choices.

Sometimes, the final straw has nothing to do with the product, which still works great. Personal politics and corporate favoritism often override other factors.

These examples may sound familiar to experienced IT workers:

·  A new CEO prefers a different product and insists the company switch.

·  A new IT manager sees no value in the Turbo Encabulator, emphasizes different areas, or is sure it could be built better and cheaper internally. An executive reads an article about “Why everyone should…” and – on what others might charitably call a whim – insists the company make a significant change.

·  New leadership wants to prove its worth by eliminating what the last team acquired or built.

Those peopleware issues do not emanate only from the C-suite. For instance, migrations happen after the people who initially adopted the Turbo Encabulator leave the company. With the team membership changing, different preferences may prevail, justly or otherwise. Given an opportunity, some teams choose to switch away from established but hated tools out of spite.

It’s the final straw. Not the only one.

Sometimes, it’s hard to discern which element is the final straw because everything is interconnected. A security breach causes your company management to lose trust in the vendor. An established provider increases its subscription pricing at the same point where users complain about the new version’s bugs. The organization likes everything about a computing environment, but the ecosystem doesn’t support a critical need, such as an application vendor dropping support for a favored operating system. But I think they all fall in one or another of these categories.

In most cases, the Turbo Encabulator providers – the vendors, open-source developers, and product designers – earnestly want to keep customers. Sometimes, they stumble: A competitor makes a genuinely innovative advancement or is faster to comply with an attractive buzzword. In other circumstances, they make avoidable mistakes, such as deploying confusing user interfaces or choosing greed over customer delight.

Esther Schindler began writing about the intersection of technology and business before your company ran Lotus 1-2-3 and WordPerfect on Novell servers.

‍