What does it mean when your developer disappears?
It happens in several ways. The freelancer who built your system stops responding. A 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. Your data is there. And 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, and early .NET applications from the same era face the same pressures. Meanwhile 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 if the developer who disappeared was an AI coding tool?
A new version of this problem arrived in 2026, and it fits the same pattern exactly. Someone in the business assembled an application with an AI coding tool, it worked in a demo, it went into production, and now it breaks under real use. The person who prompted it cannot say what the code does, and the AI that wrote it was never a developer you could call back.
An AI-built application that no one on staff understands is an orphaned system from the day it goes live. The absent developer is the model. Yet the rescue method does not change: read the code and the data first, document what the application actually does, then decide whether to stabilize, migrate, or rebuild.
This is now common enough that PCG treats it as its own scenario. If your situation is a failing AI-generated application rather than a departed human developer, the specifics are covered in who fixes a vibe-coded application that is breaking in production. The rest of this guide applies to both cases, because the work of taking over code no one on staff wrote is the same whether a person or a model wrote it.
What are the warning signs your orphaned system is about to fail?
Only one person knows how to use it correctly
When the employee who understands the system's quirks leaves, the system effectively becomes unusable. If that knowledge is not documented, it is gone.
It runs on an old operating system or server
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.
Nobody can modify it without breaking something
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.
The errors are increasing
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.
You cannot get a copy of the source code
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. The specific cost of that scenario is covered in the cost of losing your business software source code.
The documentation does not exist
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. A common 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.
Get a copy of everything you can access
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. When 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.
Stop making undocumented changes
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.
Get a technical assessment before deciding anything
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.
Stabilize before you replace
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.
Migrate on your timeline, not the system's
A system that is failing gives you no control. One 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.
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.
The specific platform matters for the migration path. If the orphaned system is a Visual Basic 6 application, a Visual FoxPro system, or a Microsoft Access database, PCG has a documented path off each one. The diagnostic identifies which path fits.
Key takeaways
- An orphaned system is almost always recoverable. The instinct to panic and rebuild immediately is usually the wrong first move, because a rushed rebuild copies the old problems into new code.
- The correct sequence is stabilize first, document second, replace on your timeline. A stabilized system buys 6 to 12 months to plan a proper migration instead of an emergency one.
- Missing source code is not a dead end. PCG reverse-engineers business logic from the database structure and application behavior when the original source is gone.
- In 2026 the absent developer is sometimes an AI coding tool. An AI-built application no one understands is an orphaned system from day one, and the rescue method is the same.
- Every PCG rescue starts with a diagnostic that documents what the system actually does before recommending stabilize, migrate, or rebuild, so the decision is controlled rather than forced.