Legacy System Modernization for AV Software: Rebuild vs. Refactor

In January 2021, Adobe began blocking Flash content from running altogether (Adobe, 2020), and the AV control panels built on Flash went dark with it. For at least some of them, there was no way to convert the old interface. The only fix was a rebuild, on a deadline someone else had set.

Most legacy AV software never gets a warning that clear. The in-house scheduling platform, the custom bridge between the control system and the booking tool, and the room interface designed for hardware that's since been swapped out all keep running, so replacing them never quite makes the list. Meanwhile, each new device takes longer to support, releases get held until after the busy season, and fewer people on the team understand how it all fits together.

That's usually when companies start looking at legacy system modernization, and the question they bring us is a blunt one: fix what we have, or start over? Either can be the right call. Which one fits depends on what the business needs the software to do next and how much disruption it can absorb while it changes.

What Legacy System Modernization Means for AV Companies

Legacy system modernization is the work of updating software that still runs the business but no longer fits it. That might mean improving the existing code, moving it to new infrastructure, rebuilding it, or some combination. Age alone doesn't make a system legacy. A platform built a few years ago on a framework that has since lost support can be harder to live with than a much older tool that still does its job.

In AV, the systems that usually end up in this conversation include:

• Booking and scheduling platforms: the tools that assign crews, rooms, and gear to jobs, often built in-house when nothing on the market matched how the company worked.
• Control and user interfaces: touch panels, room control apps, and software panels that sit between people and the hardware.
• Rental and inventory systems: platforms that track serialized equipment, kits, and maintenance status from one job to the next.
• Custom middleware: the connecting code that moves data between control systems, monitoring tools, booking software, and accounting.

Each of these touches revenue directly, so how to modernize them is a business decision as much as a technical one.

For a broader look at modernization options outside AV, see our guide to legacy system modernization approaches.

Signs Your AV Software Has Become a Liability

Legacy software rarely announces itself with a crash. The warning signs show up in planning meetings, in support tickets, and in how much time the engineering team asks for whenever someone requests a small change. These are the four we see most often.

The Vendor or Platform Has Moved On

Every piece of AV software depends on things it doesn't control: an operating system, a framework, a manufacturer's control protocol, or a third-party library. When any of those stops receiving updates, the software built on top of it takes on the risk. Microsoft ended support for Windows 10 on October 14, 2025 (Microsoft, 2025), so room PCs, signage players, and control servers still running it no longer get standard security patches.

Third-party scheduling and control platforms create the same exposure when a vendor is acquired, sunsets a product line, or stops prioritizing the version you rely on. Support rarely ends overnight. Response times slow, the roadmap stops mentioning the features you use, and eventually the renewal quote arrives with a migration offer attached.

New Hardware Keeps Needing Workarounds

AV hardware refreshes on its own schedule, and custom software has to keep pace with every new display, codec, audio processor, or camera a client specifies. If the system was designed around a fixed set of devices, each new model turns into a small project: a custom driver, a translation layer, or a manual step someone performs on site.

Each workaround makes sense on its own. Over time, though, they pile up into a list of exceptions that only their authors can maintain, and supporting a new device starts taking weeks instead of days.

For a closer look at when custom connections between AV systems pay off, read our article on whether custom API work is worth it for your AV platform.

Your Engineers Avoid Touching It

This sign rarely appears in a report, but it's often the clearest one. It tends to show up as a pattern of behavior:

• Padded estimates: anything that touches the older system gets a generous buffer, because past changes caused surprises.
• Release freezes: updates get scheduled around the event calendar instead of around readiness, and some never ship at all.
• A single point of knowledge: one or two people understand how the pieces connect, and most of what they know was never written down.

We've seen this many times, and it usually reflects a capable team that has kept a demanding system running for years. It's also one of the most common ways legacy risk builds up without anyone noticing, until that one person takes a new job.

IT and Security Teams Keep Raising Flags

As more AV equipment connects to corporate networks, it goes through the same security reviews as every other device on those networks. Older control software can rely on shared passwords, unencrypted connections, or open ports that a security team wouldn't approve today.

Once the answer to an audit finding becomes "the software can't support that," the problem is no longer just technical. It now affects compliance and, for integrators, the relationship with the client's IT department.

[Stat placeholder: a primary-source AVIXA figure on the share of AV systems or devices deployed on IP networks, to show how much AV now sits under IT governance.]

The cost of living with these signs is easy to underestimate because it's spread across so many budget lines.

The U.S. Government Accountability Office (GAO, 2023) reported that federal agencies typically spend about 80% of their more than $100 billion in annual IT spending on operating and maintaining existing systems.

Government IT is its own world, but the pattern holds wherever older software stays in service past its fit. The longer that goes on, the larger the share of the budget that goes to keeping the system alive instead of improving it.

Rebuild vs. Refactor: What's Actually the Difference

A leadership team that approves a "refactor" expecting a new platform will be disappointed when the budget runs out. So will a team that pitches a "rebuild" when it really means cleaning up a few troublesome modules.

Refactoring: Recabling the Venue

Refactoring improves existing software without changing what it does from the outside. Engineers restructure code, replace outdated components, add automated tests, and fix the areas that cause the most trouble, while users keep working the way they always have. It's closer to recabling a venue than building a new one. The stage, seats, and sightlines stay where they are, and the work happens behind the walls and above the ceiling.

Because the work happens in pieces, a refactor can usually run alongside normal operations, and each completed piece pays off on its own.

Rebuilding: New Construction on the Same Lot

A rebuild replaces the system with new software designed around today's needs. The business rules and data carry over, but the architecture, technology, and often the user interface are new. A rebuild can fix problems a refactor can't reach, such as a platform designed for a single location that now has to support operations across many.

It also has the most ways to go wrong. Timelines run longer, there's usually a stretch where two systems run side by side, and the new version has to reproduce years of small behaviors that users rely on without realizing it.

Other Terms You'll Hear

• Rewrite: usually a synonym for rebuild, though some teams use it for replacing a single component.
• Replatform: moving software to new infrastructure, such as the cloud, with only the changes it needs to run there.
• Re-architect: changing how the major parts of a system are structured and connected, which puts it somewhere between a deep refactor and a full rebuild.

Neither option is safe by default. A refactor that avoids the real problem spends money without reducing risk. A rebuild started for the wrong reasons can take years to pay for itself.

When Refactoring Is the Right Call

A refactor is the less dramatic option, and for many AV companies it's the right one. If the software still does what the business needs and the trouble is in how it was built, a well-planned refactor usually brings improvements sooner and with less disruption than starting over.

The Business Rules Still Match How You Operate

Software captures how a company works: how jobs are quoted, how crews get assigned, how gear is reserved and returned, and how changes get approved. If those rules are still accurate, they're worth keeping. They hold years of decisions that would otherwise have to be rediscovered, often the hard way.

A refactor leaves that logic intact and improves the code around it.

One question tests this well. When your operations team walks through how a job moves from booking to wrap, does the software follow the same path, or are people working around it?

The Problems Are Concentrated in a Few Places

In most legacy systems we review, the pain isn't spread evenly. A handful of modules account for most of the bugs, slowdowns, and support requests. These are often the device connections, a reporting engine, or an aging invoicing component. When trouble clusters like that, addressing those areas delivers most of the benefit for much less than the cost of replacing everything. A short technical review usually shows quickly whether a system fits this pattern.

The Event Calendar Won't Allow a Big Cutover

AV companies rarely get to pause operations for a migration. Peak seasons, recurring client events, and installs booked months in advance leave short windows for change, and a major cutover during a busy stretch puts live shows at risk. A refactor fits those windows. Changes ship in small pieces during quieter periods, each one is tested before the next begins, and if something goes wrong, the rollback is small.

Budgeting follows the same logic. A refactor can be funded in stages and paused when priorities shift, which is much harder to do halfway through a rebuild.

A Practical Order for a Refactor

When we plan a refactor with a client, the work usually follows a similar sequence:

1. Map what the system does: document the workflows, device connections, and reports people depend on before changing anything.
2. Protect the riskiest areas first: add automated checks around the parts that break most often, so every change can be verified quickly.
3. Start with what costs the most: prioritize the modules behind the most support tickets, delays, or manual workarounds.
4. Release between events: schedule updates into quieter windows, with a rollback plan for each one.

Where Refactoring Runs Out

Refactoring has a ceiling. It can make software faster, more stable, and easier to change. It can't turn a tool built to run on one server in the office into a cloud platform that supports remote monitoring across many sites. A refactor aimed at the wrong problem usually shows it within a few months: the same issues return, estimates keep growing, and each release improves less than the last. When that pattern appears, the conversation needs to move to a rebuild.

When a Rebuild Is Worth It

Rebuilds have a reputation as the expensive, risky option, and much of that reputation is earned. Some situations still call for one, though, and putting it off only raises the eventual price.

The Architecture Can't Support Where the Business Is Going

Architecture is how the major pieces of a software system are organized and connected. Every system is designed around assumptions about the business at the time it was built: how many locations it serves, how many people use it, which devices it talks to, and where it runs. When the business outgrows those assumptions, cleanup alone won't change them.

In AV, this tends to happen at a few predictable moments:

• From installs to managed services: remote monitoring, alerting, and recurring billing need software that runs continuously and connects to equipment across many client sites.
• From one warehouse to several: inventory, crews, and gear have to be visible across locations as they move.
• From internal tool to client-facing product: clients expect self-service portals, mobile access, and permission levels that an internal tool was never designed to handle.

Technical Debt Has Compounded Past Incremental Fixes

Technical debt is the accumulated cost of shortcuts and outdated decisions in software. Like financial debt, it carries interest, because every new change takes a little longer due to what's already there. Some debt is normal, and taking it on to hit a deadline is often a reasonable trade.

A refactor pays that debt down in installments, which works as long as the payments shrink the balance. When they stop doing that, the signs are hard to miss: fixing one area breaks another, and the team spends more time on stability than on new work. At that point, replacing the system often costs less than continuing to pay.

The Platform Underneath Has Disappeared

Sometimes the decision is made for you. When the language, framework, or runtime a system depends on reaches end of life, as Flash did, there may be nothing left to refactor toward.

The same thing happens when a manufacturer discontinues the control protocol or development kit your software was built around. It also happens when the people who know an older programming language have moved on and new hires with that skill are hard to find.

The Honest Costs of Starting Over

Research from McKinsey and the University of Oxford (McKinsey, 2012) found that large IT projects with budgets above $15 million ran 45% over budget and 7% over schedule on average, while delivering 56% less value than predicted.

Those were large enterprise programs, and the study is more than a decade old, but the risks it describes apply at any size. Three come up repeatedly in the rebuilds we see:

• The feature-parity trap: older systems carry years of small behaviors people rely on without thinking about them, from a report format finance expects to a shortcut the warehouse team uses daily. Miss them, and the new system feels like a step backward on launch day.
• Running two systems at once: most rebuilds need a stretch where old and new run side by side. That means double the maintenance and a careful plan for keeping data in sync.
• Scope creep: once a rebuild is approved, every wish-list item starts to look like it belongs in the first release, and the timeline stretches to match.

The best protection is time spent up front. When we rewrote the ticket and cash management system that IMS Management Services runs at festivals and fairs, the first three months went to product definition, before any new code was written.

Our developers reverse-engineered data flows from the legacy application and worked through each workflow with the client's subject matter expert. The result was a 115-page product definition document and 54 sample screens, which gave development a clear target.

"Definition is very important in areas where there are a lot of unknowns and we need to provide an exact estimation." Lyubomyr Nykyforuk, Softjourn Ticketing Technology Expert

A Middle Path: The Progressive Rebuild

A rebuild doesn't have to happen all at once. In a progressive rebuild, new components replace old ones one at a time while the legacy system keeps handling everything else. Teams usually start with the area that causes the most trouble or blocks the most growth. Each new piece goes live on its own schedule, between events, and the old system shrinks until it can be retired.

This approach takes longer overall, and it needs careful planning around how the old and new parts exchange data. In return, the business keeps running throughout, and the cost spreads across several budget cycles.

How to Decide Between Refactoring and Rebuilding

Code quality matters, but it rarely settles this decision on its own. The right call usually comes from weighing business risk against the cost of change, and a handful of questions get you most of the way there.

Five Questions to Answer Before You Commit

1. Cost of failure: What would an hour of downtime cost during a live event? If an outage means refunds, contract penalties, or a lost client, a big-bang cutover carries real exposure, and a refactor or progressive rebuild is usually the safer route. Software that supports back-office work with room for a short disruption makes a full rebuild easier to absorb.
2. Platform lifespan: How long will the operating system, framework, and hardware the software depends on stay supported? If the honest answer is "not long" or "it already isn't," refactoring may only buy time.
3. Business fit: Does the system's logic still match how you sell, schedule, and deliver work? A close match favors a refactor. A growing list of workarounds, side spreadsheets, and manual steps points toward a rebuild.
4. Knowledge risk: Who understands the system today, and what happens if they leave? Documentation and a technical review lower this risk on either path, but a system only one person can maintain is a liability until that changes.
5. Cost of standing still: What will the current system cost to keep running over the next few years? That figure should include maintenance, workarounds, lost deals, and the features you can't build, and it's the real baseline for comparing both options.

Answers rarely all point the same way. More often the outcome is a mix: refactor the parts that work, rebuild the one or two areas that block growth, and plan the sequence around the event calendar.

Getting an Outside Read

Several of these questions are hard to answer from the inside, especially when the people closest to the system are also the ones keeping it running day to day.

These are often the situations where clients bring us in for a code audit. An audit is a structured review of the codebase, architecture, and dependencies that shows where problems cluster, what's at risk, and what each option would realistically involve. It gives leadership something concrete to weigh before committing a budget to either path.

Learn more about how our software development audits work.

Making the Call Before the Next Hardware Refresh

Legacy AV software tends to give out at inconvenient moments: the week a new display line ships, the month before a major client renewal, or the night before a show. Deciding between a refactor and a rebuild while there's still time to plan lets you choose when the change happens, instead of leaving the date to a vendor, a framework, or a failure.

We've helped companies across ticketing, fintech, and live events modernize the software their operations depend on, from careful refactors of live systems to full rewrites built around new workflows. Contact Softjourn to get started on your AV software development project, or to talk through which path fits your system.