There is a class of software that keeps small businesses alive and nobody writes about. It is a desktop application, built twenty years ago, that people open every single day to do their real work. Client records. Progress reports. Case tracking. It was written by one developer, in a language most programmers today have never touched, and it runs on a machine sitting under someone's desk at the office.
We are rebuilding one of those applications right now. The company behind it has been around for decades, their agencies depend on it daily, and the whole thing is racing a deadline it did not choose. Here is what that actually looks like, and why this category of software is running out of time.
The wall it just hit
The first wall is Windows. Microsoft ended support for Windows 10 in October 2025. That does not mean the old machines stop working tomorrow. It means no more security updates, no more patches, and every year the risk grows. Agencies that run their business on a desktop app have two options: keep machines off the internet, or upgrade.
Upgrading is where the second wall hits. This class of software was built on Visual Basic 6, a tool Microsoft stopped supporting more than fifteen years ago. VB6 code does not run on Windows 11 the way it used to. It needs compatibility shims, virtual machines, and careful configuration. Every new laptop, every Windows update, is a small gamble that the app keeps working.
And the third wall is the quietest one. The developer who built the system, the only person who truly understood it, is gone. There is no documentation that matches the actual behavior. No one left in the company can answer the question "why does it do that?" The people running the business today inherited the software along with the business, and they have spent years working around it instead of changing it.
That is the moment we usually get called.
What "works on my computer" really costs
The surface problem is technical. The real problem is operational.
In this app, every agency runs its own copy. Each one has a local database installed on whatever desktop computer they could spare. Some of those computers are fine. Some are old gaming PCs. Some are the receptionist's machine. When a DLL conflicts with a Windows update, when the database gets corrupted, when the server machine is rebooted at the wrong time, the agency cannot do client work.
Who gets the call? The software company's owners. They have become de facto IT support for every agency they serve. They spend their days troubleshooting someone else's desktop instead of selling to new agencies, improving the product, or growing the business. The help desk is not a department. It is the founders' calendar.
This is the cost of legacy software that people rarely put a number on. Not the license fees. Not the hardware. The hours that the people running the business lose to machines that should have been replaced years ago.
What modernization actually takes
The big-bang rewrite is the reason most modernization projects fail, and the reason most businesses never start. A 10-year-old codebase, three times the size you think, an executive who wants a full replacement in a quarter, and a team that barely understands the domain. It is the most expensive way to do the wrong thing.
The realistic path looks different. You keep the data. You keep the business rules. You move the workflows.
That means the first phase is not writing code. It is understanding what the system actually does, not what the documentation says it does. Every screen, every rule, every report, every edge case that someone patched in 2009 and forgot about. We spend the early weeks mapping the system and the business before we touch the build.
Then you move the application to a web app, one workflow at a time. No client installs. No machine under a desk acting as a server. One central system, agencies sign in, data lives where the company can actually see it and back it up. The owners get an admin portal with real control over users, agencies, and billing codes. The help desk problem mostly disappears because the app no longer lives on a thousand different computers.
This is not fast and it is not cheap. It is honest. You modernize the parts that hurt the most first, you keep the parts that work, and you do not pretend the old system was worthless. It kept the business alive for twenty years. You just should not bet the next twenty on it.
The window is closing
The people who understand this generation of software are retiring. The machines it runs on are losing support. The businesses that depend on it have a few years, not a few decades, to make the move while it can still be done carefully instead of in an emergency.
If your company runs on a desktop application from another era, the question is not whether to modernize. It is whether you do it on your schedule, or on Microsoft's.
Book a discovery session if you are running a legacy system that is losing support and need someone to tell you honestly what modernization will take.