ORPHANWARE Step 1: Freeze and back up what runs
The working installation you have today is now the most valuable copy in existence, and it is fragile. Before anything else, protect it. Image the machine or the virtual machine the software runs on, so the entire environment can be restored as it is. Copy the installers, license files, configuration files, and the data itself to storage that does not depend on that one machine. Write down the exact versions of the program and the operating system, and photograph or export any settings screens that would be hard to reconstruct.
Then freeze the environment. Postpone updates, cleanups, and migrations until the situation is documented. The most common way orphaned software dies is not the vendor closing. It is a well meant IT cleanup, a replaced workstation, or an automatic update that wipes or breaks the only working copy in the weeks after the vendor disappears.
Step 2: Hunt for the source
Source code survives in more places than owners expect, and the search is cheapest while memories are fresh. Work through these sources in order:
- Former employees of the vendor, and the vendor principals themselves. Small vendors often close the company but keep personal copies, backups, or old development machines.
- Any escrow arrangement. If a software escrow agreement existed, contact the escrow agent and ask what release conditions apply and whether a deposit was ever made and verified.
- Your own records: old email accounts and attachments, file shares, retired servers, backup tapes or drives, and the files of any employee who managed the vendor relationship.
- The original contract. Read its intellectual property and source delivery terms carefully. Some contracts promised source on vendor failure, and some licenses included it from the start.
Ask early and ask politely. People who have just closed a business are far more reachable in the first weeks than they will be in a year, and a hard drive that exists today may be wiped, sold, or discarded by then.
Keep a written log of the hunt: who you contacted, when, and what they said. If source turns up later through a former employee or an estate, that log is what proves the chain of custody and your right to use what you found.
Step 3: Establish your rights
In general terms, an owner or licensee maintaining software for its own continued operation is in a very different position from someone copying software to resell it. That said, rights depend on your license and your contract, not on general terms. Read both. Note any terms covering maintenance, backup copies, transfer to new hardware, and what happens on vendor insolvency.
Our own rule is strict and simple: we only work on binaries the client owns or has the right to reverse engineer, and we take no work involving malware, cracks, keygens, or DRM circumvention. If your paperwork is ambiguous, get it read by a lawyer before commissioning recovery work. When the license is clear, recovery for continued operation of your own system is a normal maintenance decision, and it should be documented as one.
Step 4: Stabilize the environment
With the installation protected and the source hunt under way, make the day to day setup resilient. Keep at least one spare machine or a tested virtual copy that can run the system if the main machine fails, and verify that your backups actually restore. Print or export the documentation of daily workflows: how orders are entered, how reports are run, where files land. Knowledge that lives only in one long serving employee is the same single point of failure as knowledge that lived only in the vendor.
Stabilization is not a long term answer. It is how you buy the time to make the long term decision without a deadline imposed by failing hardware.
Step 5: Decide the long game
Four paths are open, and each carries a different risk:
- Maintain as is. Lowest immediate cost, highest long term exposure. Every year the hardware and the knowledge base get thinner.
- Recover the source. Rebuild the source from the binary you have, verify it against the original, and return to a system that can be fixed, changed, and moved. The right path when the behavior of the program itself is the asset.
- Reimplement. Build a replacement guided by the behavior of the old program. Sensible when the old platform itself must go, but the behavior has to be documented first, or the replacement will quietly differ.
- Migrate. Move the data to a modern product and retire the old system. The right path when the data matters and the program does not, provided the data can be extracted completely.
The cheap fact finding step before choosing is the Recon Report. For $45, with delivery in about 3 days, it documents what the program does, its interface, and the file formats it handles, and gives an honest verdict on whether recovery is realistic. That report makes every other quote you collect more accurate too, because any replacement vendor is pricing the same unknowns the recon removes.
A note on timing
The worst time to start any of this is the day the machine fails. While the system still runs, everything is easier: behavior can be observed, outputs can be captured for comparison, data formats can be confirmed against live data, and the people who use the program can still show you how it works. A vendor closing feels like a slow problem because the software keeps running. Treat the announcement as the starting gun anyway. The work in this guide takes days while the system runs, and months of archaeology after it stops.
Intake at Orphanware Recovery is by email only, at aperturesurvivor@gmail.com. Describe the program and your situation in the first email, and do not attach the binary to it. After an initial reply, we will arrange the transfer. NDAs are available, and every engagement is directed and signed off by the operator, Josiah Wilson.