The Runtime Expired. The Business Did Not.

A North American specialty distributor had run order-to-cash, inventory, and pricing on Visual FoxPro 9 for twenty-two years. The system worked. Microsoft had stopped supporting the runtime in 2015. Two developers—both near retirement—were the only people who could change it. We, at Futluz, rebuilt the estate as an ASP.NET Core application with a React front end, taking over capability by capability until FoxPro could be switched off. Not one warehouse missed a pick.

TL;DR

Problem: Visual FoxPro 9 SP2, 180 forms, 4,200 PRGs, DBF/CDX tables, 32-bit desktop on Windows 10. Unsupported runtime, no hiring market, no APIs, two people holding the business.

Approach: Strangler replacement, not a rewrite. SQL Server as the system of record first. ASP.NET Core 8 APIs and React for new modules. FoxPro coexisted against the same database until each module was proven. Pricing, then orders, then inventory, then purchasing, then AR.

Scale & results: $420 million distributor, 3 DCs, 12 branches, 40 EDI partners. Sixteen months. FoxPro decommissioned after 90 days of read-only. New engineers could ship in the first sprint they joined. EDI moved off nightly file drops onto APIs.

Why it worked: The reason to move was the people and the platform ceiling, not a dislike of FoxPro. Scope was the processes the warehouse actually ran. Reports that nobody opened were left behind.

The client challenge

The client distributes specialty industrial components across the United States and Canada: roughly $420 million in revenue, three distribution centres, twelve branches. Order entry, inventory, contract pricing, purchasing, and accounts receivable all lived in one Visual FoxPro 9 SP2 desktop application that had grown since 2003. One hundred and eighty forms, ninety-plus reports, 4,200 PRG files, and a thicket of DBF/CDX/FPT tables with Rushmore indexes that only two people still understood.

The application did the job. That was why it had survived. Visual FoxPro’s mainstream support ended in January 2015. The runtime is 32-bit. Windows 10 was heading off support. Windows 11 and 64-bit-only images were already breaking installs on new branch PCs. Terminal Server sessions were fragile. There was no supported path to the cloud, no REST surface for e-commerce or EDI, and no labour market. The last two FoxPro developers were 58 and 61. When either of them was on leave, pricing changes waited.

Forty trading partners exchanged 850, 856 and 810 documents through nightly file drops that a FoxPro scheduled program parsed into DBFs. A half-built e-commerce experiment sat on a separate SQL database that had to be reconciled by hand every morning. Cyber insurers had started asking how long an unsupported runtime would remain in production. None of that is a reason to hate FoxPro. All of it is a reason you cannot run a $420 million distributor on it indefinitely.

Why not a big-bang rewrite

A greenfield rewrite of 4,200 programs as one release is how FoxPro migrations become folklore. You freeze change for a year, miss the undocumented pricing exceptions, and cut over on a weekend into a system the warehouse has never used at volume. We evaluated that option so the steering committee could reject it in public.

1. Rewrite everything, switch on a weekend: Rejected. The pricing matrix alone had twenty-two years of customer-specific exceptions that existed as code, not as data. A big-bang cutover would have discovered them in production.
2. Buy an ERP and retire the custom estate: Evaluated. The client’s contract pricing, catch-weight handling, and branch-level allocation were not a configuration exercise in a mid-market ERP. The fit-gap would have been a longer programme than a targeted rebuild, with more process change than the branches would absorb.
3. Wrap FoxPro forever and put a web UI on it: A useful first step, not a destination. The runtime, the hiring problem, and the 32-bit ceiling would still have been there.
4. Strangler replacement onto .NET: Selected. SQL Server becomes the system of record. New capabilities ship as ASP.NET Core services and a React UI. FoxPro keeps running against the same database until each module is proven, then that FoxPro code path is deleted.

Our solution

1. Inventory the estate before touching a line
   • We ran usage telemetry on the production EXE for eight weeks: which forms opened, which PRGs executed, which reports printed. Of 180 forms, 47 had not been opened in those eight weeks. Of 90 reports, 31 had no runs. They were not rewritten. They were retired with named owners who confirmed they did not need them.
   • The two FoxPro developers walked us through the pricing engine on a whiteboard for eleven days. That session was the specification. The code was the evidence, not the design.
2. SQL Server first, so both runtimes share one truth
   • DBF tables were upsized to SQL Server 2022 with types, constraints, and keys the DBFs never had. FoxPro was pointed at SQL via SQL Pass-Through and CursorAdapters so the desktop application kept running while new services wrote to the same tables.
   • Reconciliation jobs compared row counts, balances, and open-order totals every night for the first three months. Discrepancies had named owners. That discipline is what made coexistence safe.
3. ASP.NET Core as the new system of record for behaviour
   • Domain services in .NET 8: pricing, orders, inventory, purchasing, AR. Each bounded context owned its tables. The API is the product the React UI, EDI, and the future e-commerce site all call. FoxPro stopped being the place business rules lived, one module at a time.
   • We did not wrap 4,200 PRGs in a compatibility layer. Rules that were still load-bearing were re-implemented with tests. Rules that were accidents of 2007 were not.
4. React for the people who actually use it
   • Order entry, inventory lookup, and buyer worklists were rebuilt as a browser application the branches could open without a 32-bit install. Keyboard-first, because the old FoxPro users would not tolerate a mouse-only rewrite of a screen they had used for twenty years.
   • Crystal and FoxPro reports that still had volume were rebuilt in a managed reporting layer against SQL. The rest were dropped.
5. EDI and e-commerce get an API instead of a file drop
   • Trading-partner 850/856/810 flows moved onto the order and shipping APIs, with a translator in front for partners who could not change. The morning reconciliation to the failed e-commerce database went away because both channels wrote to the same service.
6. Cut over a module, not a company
   • Sequence: pricing (the risk), then order entry, then inventory movements, then purchasing, then AR. Each module had its own dual-run, its own warehouse pilot branch, and its own go/no-go. FoxPro screens for that module were removed from the menu only after two weeks of identical results.
   • The last FoxPro EXE was frozen read-only for 90 days, then uninstalled. The two developers spent those 90 days on the .NET team, not on a separate “legacy” island.

Sixteen months, one product

Peak team of twenty-two: a product owner from operations, the two FoxPro developers, six .NET engineers, four React engineers, three QA, a data engineer, and programme management. The FoxPro pair were not an obstacle to be interviewed once. They were on the squad. Pricing exceptions that lived only in their heads were written down as tests before the PRG was retired.

QA automated the journeys that would stop a truck: price a contract customer, place an order, allocate from the right DC, print a pick ticket, confirm a shipment, post AR. Playwright covered the new UI. Character-level checks covered the API. Three times we replayed a full day of production orders into the new stack before that module went live. Two of those replays found something.

Programme management held the line that FoxPro migrations usually lose: no “while we are in there.” Branch-level promotions, a new loyalty scheme, and a warehouse-management fantasy were logged for after FoxPro was gone. The product had one job until then: replace the load-bearing system without stopping picks.

What changed for the people using it

Branch clerks enter orders in the browser instead of a desktop EXE that IT had to image. Buyers see inventory without phoning a DC. The two people who used to be the system are no longer on call every time a price looks wrong. None of this required FoxPro to have been a mistake in 2003. It required the company to stop betting the warehouse on an unsupported runtime and two retirements.

Business impact

Risk: Off an unsupported 32-bit runtime and a two-person knowledge monopoly, onto a stack the labour market can staff and insurers will underwrite.

Cost: Dual runtime and the standing “only those two can do it” queue came out after decommission. Unused forms and reports were not rebuilt.

Speed: Pricing and order changes ship on a normal release train. EDI and e-commerce stop being overnight batch problems.

A FoxPro to .NET migration is not a verdict on Visual FoxPro. It is a judgement that a distributor cannot keep its order-to-cash system in two people’s heads on an expired runtime. We bring the strangler discipline and the .NET product engineering; the reason has to be the operating risk, or the rewrite should not start.