A nine-figure distributor on Visual FoxPro. On a clock they don’t control.

The business serves retailers, B2B accounts, and direct-to-consumer customers across multiple channels. Forty years in operation. The kind of mid-market distributor where one warehouse mistake costs a customer relationship, and one delayed integration locks a revenue channel that’s been on the wishlist for years.

The system that runs the operation was built decades ago by the original owner. It’s been maintained and extended ever since by a single in-house developer who eventually became CTO. He’s done remarkable work keeping it alive. But the platform is the limit now, not him.

The application is custom from top to bottom. It runs the warehouse, the orders, the inventory, the customer data, the accounting touchpoints. Forty years of business logic, encoded in a language that hasn’t had a security update or platform fix in over a decade.

The risk profile is asymmetric. The system works today. It might work tomorrow. But the next Windows compatibility update, the next vendor-side change, the next time something breaks at 3 AM and the CTO is unreachable, the entire operation goes dark. There is no documented codebase to hand off. There are no Visual FoxPro developers to hire. The platform’s user community has been shrinking every year since support ended.

The CTO has done remarkable work. The platform is the constraint, not him. Visual FoxPro can’t connect cleanly to the modern marketplaces and partner integrations that would unlock new revenue channels. The team has been trying to access those channels for years. The technology has been the only thing in the way.

He also doesn’t want to be the only person who can read this codebase forever. He’s been doing it for decades and would like to retire someday. The rebuild serves him as much as it serves the business. As long as the platform is Visual FoxPro, there’s no successor to hand the work to. The key-person risk is just as real for him as it is for the company.

Off-the-shelf platforms have been evaluated. None of them fit forty years of niche-distribution business logic without the kind of customization that costs more than building custom from scratch. The honest answer was the one nobody wanted: a custom rebuild, no shortcuts. And it had to happen without the business going offline for a single day.

Before we wrote a line of new application code, we duplicated the data. The Visual FoxPro database is now mirrored continuously into a modern SQL database that we manage and maintain. The two run side by side. The legacy system keeps the operation alive while the new database accumulates everything in a structure built for the next forty years.

This is the dual-database approach we use for legacy modernizations. It’s slower than a flag-day cutover. It’s also the only approach that doesn’t put the business at risk during the rebuild. At any moment, if something goes wrong on the new system, the legacy stays running. Customers don’t notice. Orders don’t drop. The CTO keeps maintaining the existing application while we build the future of it alongside him.

With the data layer secured, the work moved to the application itself. One section at a time, working alongside the department heads who actually use the screens every day.

We’re rebuilding the application piece by piece, in priority order. The first section is in active development now. Every new section ships against the SQL database we already secured, runs alongside the legacy version, and only replaces it when the team is ready.

Every screen starts with a working session with the department head who owns it. We replicate what they recognize. The muscle memory the team has built over decades stays intact, so adoption isn’t a battle. Then we improve where the platform was holding them back: faster lookups, cleaner data, and the integrations to marketplaces and partner systems the legacy stack couldn’t support.

The end state is a modern, integrated, SQL-backed application connected to the channels the business needs to grow into. The path there is incremental, low-risk, and visible to the team at every step.

The dual-database setup is live. Data flows continuously from the Visual FoxPro database into the new SQL database with full redundancy. Forty years of business data is now mirrored on infrastructure we control.

The first application section is in active development, with the department head as a working partner. Familiar workflows are being replicated. Improvements the legacy platform never allowed are scoped and building in parallel.

The next sections are in queue, prioritized by operational impact and revenue upside. The marketplace integrations the team has been waiting years to enable are now part of the modernization roadmap, not a separate project to be funded later.

This is an active engagement. We’ll update the page as the rebuild progresses and outcomes are real enough to publish.

Visual FoxPro reached end-of-life in 2010. Microsoft ended support in 2015. The community of developers who can safely modify a Visual FoxPro codebase has been shrinking every year since, and most of the working ones are nearing retirement.

The technology itself is more durable than its support status suggests. Visual FoxPro applications can keep running for years on modern Windows. But “can keep running” is not the same as “will keep running through the next breaking change you don’t see coming.” Every quarter that passes makes it harder to find someone who can fix it when something does break.

The honest path forward is rarely a like-for-like rebuild. It’s a parallel rebuild on modern infrastructure, paced to the business’s actual operational tolerance, with the existing system kept alive until the new one is genuinely ready. We’ve done this for SASS on Visual Basic. We’re doing it now for a nine-figure distributor on Visual FoxPro. The pattern is the same. The risk is real.