Manufacturing is one of the most software-dependent industries in the world, and almost none of it is modern. Your MRP system was probably commissioned in the late 1990s or early 2000s. Your shop-floor data collection runs on something written in VB6 or Visual FoxPro. Your warehouse management talks to a 20-year-old serial-port barcode scanner. And the developer who built it has either retired, passed away, or moved on. That's the situation we deal with every week.
Typical legacy stacks we see in manufacturing
- FoxPro and Visual FoxPro — MRP, BOM, and inventory systems built in the 1990s by a single in-house developer. Still running because they work, still terrifying because nobody knows how.
- Visual Basic 6 / VB.NET — Shop-floor data collection, machine telemetry, custom HMIs that talk to PLCs and barcode scanners.
- Classic ASP and ASP.NET WebForms — The "internal portal" that ships customer order status, generates pick lists, and prints labels.
- .NET Framework 2.0 - 4.8 — Custom integration layers between SAP / Microsoft Dynamics / Sage and your bespoke MES.
- Access and dBase databases — The "side spreadsheet" that grew into a real system because someone needed to track quality control, supplier scoring, or maintenance schedules.
- FoxPro DBF files on a shared drive — Still serving 30+ concurrent users across the plant because the original developer figured out how to make it work.
The risks unique to manufacturing legacy software
Manufacturing software failures don't just inconvenience users — they stop production. A typical large factory loses $50,000 to $250,000 per hour of downtime. That changes the risk calculus for everything.
- Single point of dependence. One person knows how the system works. When that person leaves or retires, the knowledge is gone. We see this every quarter.
- Tightly coupled to physical hardware. Your software talks to scales, scanners, label printers, PLCs, conveyor controllers, vision systems — often through serial ports, parallel ports, or proprietary drivers that only work on Windows XP / 7.
- Compliance constraints. ISO 9001, FDA 21 CFR Part 11, automotive IATF 16949, aerospace AS9100 — any change to validated software has to be re-validated. Modernizing in-place beats rewriting almost every time.
- You can't take it offline. The factory runs 24/7 or in tight scheduled batches. "We'll deploy this weekend" is rarely an option. We work in parallel: old system keeps running, new components are tested alongside, then cut over at a controlled moment.
- Operator muscle memory. Your floor staff have used this UI for 15 years. The screens are ugly, but they're fast. Replacing them with a "modern" UI often slows production. We modernize the bones and leave the interface workflow intact unless there's a clear reason to change it.
Our approach for manufacturing rescues
We start with a free consultation. After understanding your situation, we propose what makes sense — sometimes a short technical assessment (2 to 3 days of reading your codebase and watching your operators), sometimes a targeted fix, sometimes a phased modernization. The proposal is specific to your plant, not a template.
From there, common rescue work includes:
- Stabilizing the database layer (DBF or Access → SQL Server with a compatibility shim so legacy clients still connect).
- Wrapping the legacy app in a modern API so new dashboards, mobile apps, or supplier portals can read live data without touching the original code.
- Replacing the most brittle module (often a custom integration with a piece of hardware) with a modern equivalent that's easier to support.
- Documenting the system so your team isn't dependent on tribal knowledge or a single developer.
Where appropriate, we also modernize the front-end — converting Classic ASP or WebForms to ASP.NET Core MVC or Blazor — while keeping all the original screens reachable so operators can fall back to what they know.
Related case study
Read how we rescued a distribution and inventory system that was running a factory and warehouse network for a manufacturer whose original developer had retired without documentation. We stabilized the FoxPro core, wrapped it in a REST API, and migrated reporting to a modern web dashboard — without ever stopping production.