When the original Visual FoxPro developer is gone and the application is still running the business, the immediate priority is preserving access to the source code, the database, and any documentation that exists. PCG performs an emergency source recovery and a written application inventory, typically within the first 2 to 4 weeks, before any migration decision needs to be made.
This situation arrives in a predictable way. Nobody currently on staff can answer a real question about how the application works. The source code lives on a network share that nobody has touched in years. Yesterday a Windows update made a report fail, and now the operations team is asking what happens next.
This article is for the business owner, CEO, or operations leader who is in that situation right now. It does not address the strategic evaluation of a planned migration. The audience here is someone who has woken up to a problem and needs to know what to do this week. If your situation has not yet reached emergency, the strategic version of the conversation is in Visual FoxPro Migration in 2026. This piece focuses on what happens when the planning window is already closed.
What does "developer is gone" actually mean for the business right now?
There are three operational realities behind the phrase, and each one has different consequences. Knowing which one applies to your situation determines what the rescue actually requires.
Developer unavailable but reachable
The original developer retired, changed careers, or moved on. They are still alive and possibly willing to answer questions, but they are not actively maintaining the application.
Developer entirely unreachable
The original developer has passed away, gone out of business, or cannot be located. Whatever knowledge they had about the application is no longer recoverable from them directly.
Developer never properly engaged
The application was built by a contractor or vendor that the business has no current contract with. Source code ownership may be unclear, and documentation may never have existed.
The rescue path is similar across all three situations because the technical work is the same: PCG reads the Visual FoxPro source code and the database schema directly. Documentation that exists in the developer's head is helpful when accessible, but it is not the primary input. The compiled application, the source code, and the production database together describe what the system actually does, and that is what gets inventoried during the rescue phase.1
What are the first three actions to take this week, before anything else?
The actions below are not about migration. They are about preserving the option to do anything at all. Each one can be completed within the first week, and each one significantly reduces the risk that the rescue becomes harder later.
First, locate every copy of the source code and back it up to a controlled location. Visual FoxPro source files are typically PRG, SCX, FRX, and VCX files in directories scattered across old development machines, network shares, and possibly a backup tape from 2014. Make a full copy to a current storage location that the business controls. If the source code lives only on the original developer's old workstation, image that machine before anything else happens to it. A workstation that boots today may not boot next month.
Second, identify and back up the production database. Visual FoxPro applications typically store data in DBF files alongside compiled executables, or in a separate data directory on a Windows file share. The DBF files are the actual business data. Take a current backup. Verify the backup is readable. If the application uses a SQL Server back-end accessed through ODBC, also take a current database backup using SQL Server tools. The data is significantly more valuable than the application that reads it, and the data is what enables any rescue scenario.
Third, document what is currently working, what is not, and who depends on each piece. A short written list of the application's main functions, the reports staff run on what schedule, the external systems it connects to, and the regulatory or compliance use cases it supports. This document does not need to be exhaustive. It needs to exist. PCG's discovery phase will produce the complete inventory, but the initial list helps prioritize which modules carry the highest business risk if the application fails.2
Visual FoxPro lost Microsoft extended support on January 13, 2015. In 2026, every VFP application is running on borrowed time. The window to act is not when the application fails. It is now, while the source code and the data are still available to recover.3
How does PCG recover the source code when nobody on staff has access?
Source code recovery is the first technical step of the rescue. PCG begins by inventorying every possible location where the source code might exist. Old development workstations, network shares, backup tapes, cloud storage accounts associated with the original developer, vendor archives, and any version control system that may have been used. PCG works with the buyer's IT team to access these locations and retrieve whatever source files can be found.
When the source code is incomplete or partially missing, PCG reconstructs what is recoverable. Visual FoxPro source files have predictable structures that PCG reads directly. PRG files contain procedural code. SCX files describe forms. FRX files describe reports. VCX files describe class libraries. Each file format is documented and readable without the original developer's interpretation. The compiled APP or EXE file also contains useful information about what the application does at runtime, even when corresponding source is unavailable for parts of the codebase.1
The output of source recovery is a controlled archive of every recoverable source file, indexed by module and function, with a written assessment of what was found and what could not be located. This archive becomes the input to the application inventory phase. The buyer ends source recovery with a definitive answer to the question of what source code the business actually possesses, which is more than many businesses had at the start of the rescue.
What happens during the application inventory phase?
The inventory phase produces a written document describing what the Visual FoxPro application actually does. What you receive is not a code-level walkthrough. It is an operational description written for the business owner, the operations team, and any future development engagement that needs to understand the system. The inventory has five components.
Functional module map
Every screen, form, and operational function the application provides, organized by business area. Staff who use the application can verify that the map matches their daily work.
Data model
Every DBF table or database object, the fields each contains, the relationships between them, and the volume of data currently stored. The data model often reveals undocumented business entities that staff did not know existed.
Business rules inventory
Validation rules, calculation logic, approval workflows, and conditional behaviors embedded in the source code. This is the component most often missing from existing documentation, and the most valuable to recover.
Reports catalog
Every report the application produces, who runs it, on what schedule, and what data sources feed it. Reports are often the most visible part of the application to non-technical staff, and their inventory has immediate operational use.
External connections
Every system the application connects to: accounting platforms, payroll, EDI partners, hardware devices, regulatory reporting systems. Each connection becomes a dependency the business must plan around.
The five components together form a deliverable the business owns regardless of what happens next. Should the decision be to migrate, the inventory becomes the foundational scope document. When the choice is to continue running the existing application for another two years, the inventory becomes the operational manual that the business never had. If the application fails before any decision is made, the inventory is the document that allows a replacement to be built without losing the embedded business knowledge.2
Speak directly with the engineer who would lead your rescue
A free 30-minute consultation to assess the urgency of your situation. No obligation, no sales handoff.
How urgent is the migration decision once the inventory is complete?
Once the inventory exists, the urgency of migration changes. The business now knows what it owns. A choice between migrating, integrating, or continuing to run the existing application becomes strategic rather than reactive. Most buyers who complete the rescue phase find that the migration question has a clearer answer than they expected, because the inventory reveals which parts of the application are truly business-specific and which parts could be served by an off-the-shelf replacement.3
The strategic version of this decision is described in detail in Visual FoxPro Migration in 2026. That article walks through the three real options of migration, integration, and replacement, and describes how each one fits a different situation. The rescue inventory is the input that allows that conversation to be productive rather than speculative.
What does not change after the inventory: the underlying technical risks of running on Visual FoxPro in 2026. Microsoft ended extended support on January 13, 2015.3 The 2 GB per-table ceiling continues to limit database growth.4 The 32-bit compatibility layer in Windows 11 continues to be a source of fragility with every feature update. The talent pool of developers who can productively work on Visual FoxPro applications continues to shrink. These conditions argue for some form of migration on a planned timeline, not on the timeline forced by the next system failure.
Before the rescue
Business is reactive
- No documented inventory of what the application does
- Source code location and completeness unknown
- Database backup status uncertain
- Business rules embedded in code that nobody can read
- Migration scope cannot be quoted without weeks of investigation
- System failure forces emergency response with no plan
After the rescue
Business has options
- Written inventory of every functional module and business rule
- Controlled archive of all recoverable source code
- Current database backup verified and stored
- Operational manual for staff and future engagements
- Migration scope quotable on real numbers from the codebase
- Decision to migrate, integrate, or continue made on the business timeline
What does emergency support cost compared to a planned migration?
Emergency support and planned migration are different engagements with different cost structures. PCG provides a fixed-fee quote for the rescue phase, including source recovery and application inventory, after a free initial consultation that assesses the situation. This quote is independent of any subsequent migration commitment. Buyers can complete the rescue phase, receive the inventory deliverable, and pause the engagement before deciding whether to proceed with migration.
The cost comparison that matters for the business owner is rescue-now versus rescue-after-failure. A planned rescue completes on a predictable schedule with the existing application still operational, staff still able to use the system, and the IT team able to support the engagement during normal business hours. When a rescue is triggered by a production failure, it runs on whatever schedule the broken business can survive. Staff who normally would contribute to discovery are instead doing manual workarounds for a system that is not working. The technical work is similar, but the operational cost of running the business during the rescue is significantly higher.2
The cost of waiting is not theoretical. It is the cost of running a rescue under emergency timeline pressure instead of a planned timeline.
PCG has been executing legacy software rescues since the late 1990s. The pattern is consistent across hundreds of engagements: businesses that initiate the rescue before a system failure spend less, lose less staff time, and arrive at the migration decision with better information. Businesses that wait until the application has broken pay a premium for compressed timelines and reduced operational flexibility. The technical work is the same. The business cost is not.
How does this differ from a planned Visual FoxPro migration?
Both engagements end with the buyer owning a clear path forward. The starting point is different. A planned migration starts with the strategic question of whether to migrate, integrate, or replace, because the business already understands what the existing application does. An emergency rescue starts earlier in the process, because the business does not yet have that understanding and cannot answer the strategic question without it.
The deliverables also differ. A planned migration produces a migrated application, the documentation package, and a reconciliation report. An emergency rescue produces a source code archive, a written application inventory, and an assessment of the next-step options. The rescue deliverable can stand on its own. Buyers who complete the rescue and decide not to proceed to migration still own a document that allows them to operate the existing system more reliably than they could before.
The two engagements connect naturally. A buyer who completes the rescue phase has, in effect, completed the discovery phase of a future migration. If the decision is to migrate, the migration engagement begins with the inventory already in hand, which compresses the overall timeline and reduces the total cost compared to a migration that includes its own discovery work from scratch.1
Find out what your Visual FoxPro application actually contains
A free 30-minute consultation, followed by a fixed-fee rescue phase if it is the right next step.
The application runs until it does not. Visual FoxPro lost Microsoft extended support on January 13, 2015, and any Windows feature update, server replacement, or compliance audit can break it without warning. The urgency is not that the system has failed. The urgency is that the business has no path to fix it when it does fail, and no documented inventory of what the application is actually doing. Building that inventory before the system breaks is significantly less expensive than building it under emergency timeline pressure.
Yes, the source code is the single most valuable asset in a rescue situation. PCG reads Visual FoxPro source directly and reconstructs what the application does without needing the original developer's interpretation. The audit phase produces a written inventory of forms, reports, business rules, stored procedures, and external integrations. The buyer ends the audit knowing what they own, which is the foundation for any decision about migration, replacement, or continued operation.
The inventory phase typically completes in 2 to 4 weeks for a mid-sized Visual FoxPro application with the source code available. Larger applications, applications with hundreds of reports, or situations where the source code must be retrieved from old backup media extend that timeline. PCG provides a fixed-fee quote for the inventory phase based on the initial assessment, separate from any subsequent migration decision.
Nothing changes in the production system during the inventory phase. PCG works against copies of the source code and the database, not the live system. Operational staff continue using the application exactly as they did before the rescue began. The first time the live system is touched is during migration cutover, and even then PCG runs in parallel rather than replacing the production system in a single weekend.
An emergency rescue starts with source code recovery and application inventory because the business does not yet know what it owns. A planned migration starts with the strategic question of whether to migrate, integrate, or replace, because the business already understands the existing application. The rescue is the first deliverable. The migration decision comes after. Buyers who go through the rescue phase often discover that they have a clearer migration scope than they would have with months of internal investigation.
1 Phoenix Consultants Group, Visual FoxPro Migration in 2026: The Real Risks and Real Path Forward. phxconsultants.com
2 Phoenix Consultants Group, My Developer Disappeared: What Do I Do? phxconsultants.com
3 Microsoft, Visual FoxPro 9.0 product lifecycle: mainstream support ended January 12, 2010; extended support ended January 13, 2015. learn.microsoft.com/en-us/lifecycle/products/microsoft-visual-foxpro-90
4 Microsoft Learn, Visual FoxPro Frequently Asked Questions: confirmation of 2 GB per-table limit and 32-bit architecture.
This article is informational and reflects PCG's experience executing emergency legacy software rescues since the late 1990s. It is not legal, regulatory, or financial advice for any specific situation. For guidance tailored to a particular Visual FoxPro application, contact Phoenix Consultants Group directly. PCG was founded in 1995.
If your business software stopped working today, PCG can be on the phone with you within hours. We have been stabilizing and rebuilding broken software since 1995. Most emergency situations get an initial diagnosis within one business day. Your system gets stable first. The longer-term decision about what to do next comes after that.
🔴 What counts as a software emergency?
A software emergency is any situation where a broken or failing system is actively costing you money, blocking operations, or creating compliance exposure right now. It is not a feature request. It is not a slow system. It is the point where work has stopped, data is at risk, or a deadline cannot be met because the software is failing.
- Database corruption, missing records, or data that will not open
- Software that ran yesterday and is refusing to start today
- Developer who built the system is gone, unreachable, or out of business
- Critical process that only one person knew how to run, and that person left
- Windows update, server migration, or IT change that broke a working application
- Year-end, audit, or regulatory deadline in days and the reporting tool is down
- Access database throwing errors no one on staff can diagnose
- Legacy application running on a machine that just failed with no backup
The common thread is operational paralysis. When the software that runs a core part of your business stops working and there is no one to call, that is when PCG gets the phone call. In 2026, orphaned legacy systems and single-developer applications fail constantly. The developers who built them have retired, moved on, or are simply unavailable. PCG has been diagnosing exactly these situations for 31 years.
⏱ How fast can PCG actually respond?
PCG answers the phone. That is not a marketing line; it is how the business has operated since 1995. For genuine emergencies, the initial call happens same day or next business day. The diagnostic review of what is broken and what it will take to fix it is delivered within one to two business days depending on complexity.
Speed matters here, but so does accuracy. A wrong diagnosis in an emergency situation makes things worse. The first conversation is a triage call where PCG determines the severity, identifies what data is at risk, and establishes whether the system can be stabilized in place or needs to be bypassed immediately. That call takes 30 to 60 minutes and costs nothing.
For PCG-built applications, emergency response is even faster. Clients on a monthly support retainer get same-day response with full system access already established. Most issues on PCG-built software get resolved within hours, not days, because PCG has the source code and the institutional knowledge of exactly how the system was designed.1
🛠 What does the emergency response process actually look like?
PCG runs a structured emergency process that has been refined over decades of exactly these situations. The goal is to stop the bleeding first, then figure out what caused it.
30 to 60 minutes. PCG asks the questions that establish what is actually broken versus what appears broken. The failure mode matters. A database that will not open is different from one with corrupted records, which is different from a login that stopped working after a server change.
PCG reviews the application and the error logs. The database state is examined alongside the environment. For legacy systems with no documentation, this phase takes the most time. The diagnosis report identifies what is broken and whether data is at risk. Recovery options are laid out before any work begins.
Getting the system functional enough to operate while the longer-term fix is scoped. Not every emergency requires a full rebuild. Many situations can be stabilized in hours. PCG will tell you honestly which category your situation falls into before any work begins.
Once the immediate crisis is resolved, PCG delivers a written assessment of what happened and what was done. The options going forward are documented clearly. Some clients stabilize and stay. Others use the emergency as the moment to finally migrate off a system that has been fragile for years.
🔍 Can PCG fix software built by someone else?
Yes. The majority of emergency calls PCG receives are for software built by developers who are no longer available. This is one of the defining realities of custom software in 2026: a significant portion of the applications keeping businesses running were built by individual contractors, small shops, or in-house developers who are no longer around to support them.
PCG approaches these situations the same way a structural engineer approaches an older building with no blueprints. The work begins with understanding what the system does before touching anything. PCG reads the code and traces the data flows, building enough working knowledge of the system to diagnose it safely. Dependencies are mapped as part of that process. That process takes longer than working on PCG-built software, but it is not unusual work for this team.
The technologies that show up in most emergency calls are ones PCG has been working with for decades: Microsoft Access, Visual Basic 6, older ASP applications, Excel-based systems, and custom .NET applications of various ages. The 32-bit application running on a Windows 10 machine that just received an update is a familiar situation. So is the Access database that was last touched by a developer who retired in 2019.2
💰 How does PCG scope emergency software support work?
Every engagement starts with a free triage call. PCG will not quote a repair job without first understanding the system. Quoting emergency repair work without a proper diagnosis produces numbers that are either wildly high or dangerously low, and neither serves the client well.
After the triage call, PCG delivers a written diagnosis that identifies what is broken and what data is at risk. Repair options are scoped from that diagnosis with realistic timelines. The repair work is scoped and quoted from that diagnosis. Nothing starts until the scope and cost are agreed in writing.
Clients who move to a monthly support retainer after an emergency engagement eliminate the emergency call scenario entirely for PCG-managed systems. Every call gets answered. Issues get resolved before they become crises. Schedule a free 30-minute consultation at phxconsultants.com to get the conversation started.
⚠️ What if the system is too old or too broken to fix?
Some systems are genuinely not worth repairing. PCG will tell you that directly, and it happens more often than the industry admits. A VB6 application running on a 15-year-old server that just failed, with no source code and no documentation, and 40 percent database corruption, may not be recoverable in a way that makes financial sense.
When a system is beyond practical repair, the options are replacement or manual operation while a replacement is built. PCG scopes both. The replacement can be a modern .NET application built on PCG's FireFlight Data System or a migration to a platform that already exists in your industry. Which option makes sense depends on what the system does and how many people use it. Budget is scoped after the diagnostic.
The worst outcome is paying for emergency repairs on a system that fails again in six months. PCG will not take that work. If the only honest path forward is replacement, the diagnostic report says so clearly.
Your system is down. Call PCG.
The triage call is free. PCG answers the phone. Get the conversation started today.
Contact PCG NowFrequently Asked Questions
1 PCG internal support data. Response times for clients on monthly retainer agreements, April 2026.
2 Microsoft Windows 10 32-bit application compatibility documentation, Microsoft Support, 2025. Legacy software failure rates for applications built prior to 2010 are significantly higher on systems running Windows 10 version 22H2 and later.
Phoenix Consultants Group | phxconsultants.com | Founded 1995.