Few businesses can survive without some sort of software. It could be a web site, a mobile application, a point of sale, your Intranet with custom proprietary workflows, or Excel, but software is needed. For many of our clients, software is the business’s primary offering. This vital resource to your business is something you should not purchase once and forget about. Software is like a vehicle; there are many makes and models of differing capabilities and quality, it requires maintenance by trained professionals, and it will need to be replaced at the end of its lifecycle – usually at about the 10-year mark.
Over 50% of our consulting engagements include recreating an application that’s been in use for a long time. Why recreate something you already have? In most cases the project owner has known that the application needed to be rebuilt for some time, and has been putting off the inevitable. Other times the owner is forced to switch quickly due to external forces – to keep up with new competitors, a failing offshore development team, or due to pressures from their superiors, regulators, or the marketplace. We refer to these types of projects as “rescue projects” – those that are already underway or are live and must be overhauled or replaced.
Most rescue projects were introduced in the late 1990s and early 2000s. It was the beginning of an exciting new era, one in which everyone was rushing to get online with their dial-up modems to get onto America Online, and when crazy business models such as selling books or holding auctions online seemed promising. The “information superhighway” was destined to be the next great frontier of business. Businesses responded by smacking together rudimentary web pages that grew into web applications and sometimes became critical to the business’s lead generation, customer interactions, and internal processes. Most mid-sized businesses saw efficiencies with their new applications and continued to use them, but do not continue to invest in the software.
Many of the consulting clients still use software built during this era. Like cars, applications fail with time. They rarely suffer a catastrophic system meltdown making an upgrade or replacement the obvious action. Instead they fail piece by piece; a form for entering data may stop working; a list of meaningful values has become outdated; a webpage randomly returns an error. Individual errors like these are often overlooked because the feature isn’t critical or there’s a workaround.
What’s wrong with an application that’s broken in a few places? For internal applications, your staff will become accustomed to the workaround and the inefficiency that comes with it. Over time the number of workarounds makes the overall process required to interact with the application so inefficient that it robs your staff of significant productivity. Worse yet, the legacy application dictates your business processes. Applications should not dictate process; process should dictate the application, and applications need to change as processes are improved. Think about the increase in efficiencies that can be had if you were to implement a perfect process and the application supported it. That’s the goal.
The situation for consumer facing legacy applications is less rosy. Consumers just won’t put up with inefficiencies and confusion. Consumers will be put off if an application looks old. When compared with modern applications, those built just 4-5 years ago can look ancient. If it looks old, consumers will rightly assume it’s not maintained, and who wants to move to a platform that’s not maintained? Unlike employees, they can’t be forced to use an old application and will simply find another provider.
Another catalyst to change is that technologies and software platforms that applications are built on top of change over time. Internet browsers that were in use in the 90s are not used anymore, standards have changed, and third party integration points may have been replaced. If the application is old enough, the technology used to build it is no longer in vogue with developers so it can be difficult to find someone competent to work on it. We have a client in California that continues to use a FoxBASE database – last released in 2004 by Microsoft – for billing thousands of clients. That client is relying on technology that’s been deprecated for almost a decade, yet they’re just now interested in upgrading.
Instead of postponing change for years and suffering with antiquated systems in the meantime, plan for regular maintenance of your information management systems. At a minimum, you’ll want a software developer that is knowledgeable of the application, who has access to the source code and database, and is comfortable enough with the system that they can fix issues quickly and can add features as needed. Hire a software consulting company and get them under a retainer to be sure you have support when you need it. Or hire a full-time software developer if you’re comfortable interviewing and managing technical personnel and have enough work.
Plan for the day you’ll need to invest in upgrading the platform when significant changes happen in the software world. If your business still relies on FoxBASE, it’s long past time that you consider upgrading to SQL Server. If you’re still on Classic ASP, you’re missing out on significant advantages that newer technologies such as ASP.NET or NodeJS offer. When the software development industry changes, you will either need to change with it or risk all the disadvantages of trying to maintain a legacy application using legacy technologies.
Treat your software like other assets in your business. Don’t buy and forget. Instead treat software like a vehicle – change the oil, wash it every once in a while, replace broken parts, and when the time is right, trade it in for a new model.