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.
🚨 What does it mean when your developer disappears?
It happens in several ways. The freelancer who built your system stops responding. The small development shop closes. The internal IT person who maintained everything leaves the company and takes institutional knowledge with them. A vendor goes out of business or is acquired, and support for your system quietly ends.
In every case, the result is the same: you are running software that nobody currently available fully understands. The code exists. The data is there. The system still runs, for now. But nobody can fix it when something breaks, nobody can modify it when your business changes, and the longer it runs without maintenance the more fragile it becomes.
In 2026 this situation is more common than it was ten years ago. The generation of custom software built on Visual Basic 6 and older Access databases is aging. Early .NET applications from the same era face the same pressures. is aging. The developers who built those systems are retiring, moving on, or simply unreachable. PCG has been handling these rescues since before most of those platforms were considered legacy.
🔍 What are the warning signs your orphaned system is about to fail?
When the employee who understands the system's quirks leaves, the system effectively becomes unusable. If that knowledge is not documented, it is gone.
Software built for Windows XP, Server 2003, or 32-bit environments will eventually stop running as hardware is updated. Many businesses discover this during a routine upgrade.
If adding a field or changing a report requires careful manual workarounds, the system has reached the point where maintenance costs more than the work it saves.
A system that threw one error per month and now throws one per day is on a trajectory. Data corruption and rejected records accumulate silently. Calculation errors surface last, often after months of bad data.
If the developer left without transferring source code ownership, you may be running compiled software with no way to modify or migrate it. This is a critical risk that needs to be addressed before the system fails entirely.
No documentation means no new developer can understand what the system does without spending weeks reverse-engineering it. That time adds directly to the cost of any future rescue or rebuild.
🛠️ What should you do right now?
The sequence matters. The instinct when a system feels vulnerable is to rebuild it immediately. That is usually the wrong move. A rushed rebuild often replicates the same problems in a newer codebase. The right sequence is stabilize first, document second, then replace on your timeline rather than the system's timeline.
Source code, database files, documentation, any notes the previous developer left. If the developer is reachable, contact them now and request a full handover package. If they are not reachable, work with whoever has server access to pull what exists. Do not wait until the system breaks to discover what you do and do not have.
Every undocumented change to an orphaned system is a trap for the next developer. If something must change before a proper handover, document it in writing: what changed and when. The reason for the change belongs in that record too. A system that has been quietly patched for years without documentation is significantly harder and more expensive to rescue than one that has been left alone.
Before committing to a rebuild, a patch, or a migration, have someone who can read the code tell you what you actually have. PCG's diagnostic engagement does exactly this: we map what the system does, identify where it is fragile and assess the data. A written recommendation with a fixed-price proposal follows from that assessment. Schedule a free 30-minute consultation to start.
If the system is still running, the goal is to keep it running long enough to execute a controlled migration rather than an emergency one. Emergency migrations produce data loss and missed requirements. Rushed deployments create the next set of problems. A stabilized legacy system buys you the time to do the replacement correctly.
A system that is failing gives you no control. A system that is stabilized and documented gives you 6 to 12 months to plan and execute a proper replacement. That difference determines whether the new system is built correctly or built in a panic.
The communications dispatch system PCG rebuilt for an ambulance company came in as an emergency. The DOS-based system was actively failing and interfering with the company's ability to reach clients. PCG patched it to keep it running while rebuilding the replacement in parallel, deploying in modules to avoid a single risky cutover. The company kept operating throughout.
A separate data rescue project came in as a different kind of emergency: a vendor was holding a client's data after a failed CRM deployment. PCG negotiated the extraction, rebuilt the record linkages from a corrupt SQL Server dump, and migrated 400 member records to a new platform without loss. Neither situation required a panic rebuild. Both required a methodical approach that started with understanding exactly what existed before deciding what to do next.
💡 Can PCG reverse-engineer software the original developer left behind?
Yes. This is one of PCG's specific capabilities, developed across 31 years of working with legacy systems in industries where the original developer was long gone. The work involves reading the existing code, tracing how data moves through the system, identifying the business logic embedded in formulas and stored procedures, and producing documentation that did not previously exist.
That documentation becomes the foundation for whatever comes next, whether that is a patch, a migration to a modern platform, or a full rebuild. A system that was undocumented and understood by nobody becomes a system with a clear picture of what it does and what it costs to maintain. What replacing it would require is documented in the same report. That clarity is what makes a controlled decision possible instead of a forced one.
Frequently asked questions about orphaned software
Allison has been building and rescuing custom software since the early 1980s, including work as a data analyst for the U.S. Air Force before founding PCG in 1995. Orphaned software rescue is one of PCG's core capabilities, developed across 31 years and 500+ projects in industries where a system failure is not an option. Every rescue starts with a diagnostic that maps what exists before recommending what to do next.
PCG founded 1995. Allison Woolbert's personal experience in software development predates PCG's founding. Project examples referenced on this page are drawn from PCG's documented project history.