The developer retired. Now who maintains your application?

First: secure everything that still exists

Before any decisions, gather and protect the physical and digital remains of the system. This week, not eventually:

• The installers. Installation disks, setup files, update media, and any patched versions. If the only copy of the installer is on the machine itself, copy it off today.
• License material. Keys, dongles, activation files, registration emails. A working program you cannot legally or technically reinstall is a countdown.
• The data. Full database backups plus a plain export (CSV or the native table files) stored somewhere other than the machine the program runs on.
• The machine. If the program runs on one aging computer, image that computer's drive. A disk image preserves the entire working environment and can be restored or studied later. This is cheap insurance and it is the step everyone wishes they had taken.
• Credentials and configuration. Admin passwords, database passwords, network shares the program expects, printer and report settings. Write down where they live.
• Any paper trail. Contracts, invoices, emails with the developer, manuals, training notes. Anything that names versions, dates, or how the system was set up.

One more step that is worth doing quickly and politely: ask. If the developer retired, they or their family may still have the source code, a backup drive, or build notes, and may be glad to hand them over. If the developer has passed away, an estate sometimes holds their equipment. Ask early, while drives are still readable and memories are fresh. If the source turns up, your problem just became much smaller. If it does not, you have lost nothing but a phone call.

Second: document what the program does

Whatever path you choose next, you need a record of the program's behavior that does not depend on the program. Walk through it with the people who use it daily and write down:

• Every screen and what it is for, with screenshots.
• Every report the business relies on, and who reads it.
• Every file the program reads or writes, and every system it exchanges data with.
• Scheduled and seasonal jobs: month end, year end, tax time, renewals.
• The workarounds. Every long-running program accumulates unofficial procedures that live in people's heads. Those are requirements too.

This inventory is not busywork. It is the specification any maintainer, rebuilder, or recovery starts from, and it is the only protection against discovering a critical report the week after the old system is switched off.

Your real options

Option 1: Find a new maintainer for the program as it stands

Sometimes possible, with limits you should understand. A capable developer can often work around the edges: reports run against the database, integrations, data fixes, wrappers. What they cannot do without source is change the program itself. Every fix inside the compiled code stays impossible, and the pool of developers who know legacy platforms shrinks every year. This option buys time; it does not restore maintainability.

Option 2: Rewrite the system from scratch

The most expensive path, and occasionally the right one, for example when the business process itself is changing. The standing risk is the hidden rules: years of edge cases, exceptions, and quiet fixes that exist only inside the old program and in no document anywhere. Rewrites discover them by missing them, usually in production. If you rewrite, the behavior inventory above becomes the most valuable document you own, and an analysis of the old binary is how you complete it.

Option 3: Recover the source code from the program

The program itself is the one complete record of what it does. Recovery works backward from the compiled binary: decompile it, reconstruct readable source, rebuild it, and verify the rebuild against the original across thousands of test cases. What you get back is maintainable source, the thing the retirement took away. From that point, any competent developer can maintain, fix, and extend the system, including developers who were not born when it was written. This is the work Orphanware Recovery exists to do, and it starts with a $45 recon verdict on whether your specific binary is a realistic candidate.

Option 4: Freeze it and buy time

Image the machine, move the environment to a virtual machine if it tolerates it, restrict changes, and run the system as a sealed appliance while you decide. Legitimate as a bridge, dangerous as a destination: the data keeps aging, the hardware knowledge keeps thinning, and the eventual decision arrives anyway.

Why this situation is exactly what recovery is for

Vendor death and developer retirement are the same event at different scales: the knowledge that maintained the program is gone, and the program remains. Recovery does not depend on finding the original developer, their backups, or their cooperation. It depends on the binary, which you already have. The honest limits are stated up front: original names and comments never come back, because they were never in the binary. The behavior, the data structures, and the business rules do come back, tested against the original. For most owners in this situation, behavior is the part that matters.

What to do this week

1. Image the machine the program runs on, and copy the installers and data off it.
2. Ask the developer, their family, or their estate about source code and backups, while asking is still possible.
3. Start the behavior inventory with the daily users.
4. Get a verdict on the binary itself. That is the intake checklist and a $45 Recon Report, in whichever order you prefer.