Legacy Software Modernization

The application still works. That's exactly what makes this decision hard.

It was written for a version of Windows that's long gone. It runs on one server nobody reboots. The company that sold it doesn't exist, or doesn't return calls. And it has run your scheduling, your quoting or your production floor reliably for fifteen years.

Nobody wants to touch it. Everybody knows they'll have to.

"Legacy" isn't about age

Plenty of old software is perfectly fine. What makes an application a liability is none of these things being true any more.

It isn't the age. It's these four. Nobody left can change it It needs an OS you can't patch The vendor is gone One person understands it Any one of these is a risk. Two of them is a plan.
The second box is the one that tends to force the timing, because it eventually becomes a security and insurance conversation rather than an IT one.

That second test is usually what moves this up the list. An application that only runs on an operating system you can no longer patch stops being a preference and starts being something your cyber insurer and your auditor want to talk about.

Four options, and one of them is "leave it alone"

Can still be changed Nobody can change it Leave it alone and keep it patched Extend it add what's missing, keep the core Rehost or wrap it buy time, reduce the risk Rebuild it as a modern web application Still does the job Doesn't any more
Only the bottom-right box is a rewrite. Most of the applications we're asked about are in one of the other three, and they're far cheaper to deal with.

Leave it alone. If it does the job and you can still change it, the right answer is often to keep it patched, keep it backed up, and spend the money somewhere it earns more. We'll say this when it's true.

Rehost or wrap it. Move it somewhere it can be secured, isolated and backed up properly — or put a modern interface in front of it so the outside world never touches the old thing directly. This buys real time and removes most of the security risk without a rewrite.

Extend it. Sometimes the application is fine and the gap is a report, a mobile screen, or a connection to a system that didn't exist when it was written. That's integration, not modernization, and it costs a fraction as much.

Rebuild it. When the thing genuinely no longer fits the business and nobody can change it, you rebuild — as a web application, on a real database, that works from anywhere and that more than one person can maintain.

What we modernize

  • Client-server desktop applications. Old VB6 and early VB.NET business applications, still doing critical work in Northwest Ohio plants and offices.
  • Applications tied to an unsupported operating system. Usually the one running on a server nobody is allowed to touch.
  • Software from a vendor who has disappeared. Or who still exists but has stopped developing the product you bought.
  • Databases that outgrew their container. Microsoft Access databases have their own page, because they're a different job with a different answer.
  • The spreadsheet that quietly became an application. Macros, lookups, one owner, no backup, and the business depends on it.
  • Reporting built on a system nobody can query any more.

Why these projects fail

Not for technical reasons. Almost never for technical reasons.

  • Nobody wrote down what it does. The specification is the running software, and the only way to recover it is to read the code and watch people use it. Budget for that honestly or the rebuild will miss things.
  • The exceptions get discovered late. Every one of these applications has rules that exist because of one customer, one regulation or one argument in 2011. They surface during testing, not during planning.
  • Big bang cutover. Switching everything over one weekend is how modernization projects become stories people tell years later. Run both, compare, move in pieces.
  • The old data comes across dirty. Fifteen years of accumulated inconsistency doesn't clean itself up during a migration. It gets decided on, or it gets carried forward.
  • Nobody owns it afterwards. A new application with no maintainer becomes the next legacy application, just with better fonts.

Why Argyle

Modernization sits across three skills that are usually in three different companies: understanding the old thing, building the new thing, and running the infrastructure under both while they overlap.

We write software in .NET — including VB.NET, which matters when the thing you're replacing was written in it — as well as Java, Node.js, Python and Ruby on Rails. We administer Microsoft SQL Server, Oracle, PostgreSQL and MySQL, so the data side is ours rather than subcontracted. And we run the servers, the backups and the security, which is what makes "run both for a while" a practical option instead of a risk.

We're a Microsoft, Cisco, VMware, Fortinet and Sophos partner, we're based in Perrysburg, and for work like this — where you need someone sitting with the people who actually use the application — being local is the point.

Start with the honest assessment

Tell us what the application does and why you're worried about it. We'll tell you which of the four boxes you're in. If the answer is "leave it alone and patch the server," that's what we'll say.

Call 419-419-5737 or send us a message and ask about modernization.

Argyle IT Solutions · 28304 Cedar Park Blvd., Suite A, Perrysburg, OH 43551 · Serving Toledo, Perrysburg, Maumee, Sylvania, Bowling Green, Findlay and all of Northwest Ohio and Southeast Michigan.