Define what “recovered” must mean
Operational recovery
Reproduce the deployed application on controlled hardware with its data and integrations.
Build recovery
Restore source, compiler, references and packaging so a verified release can be produced.
Knowledge recovery
Document dependencies and behavior sufficiently for support or replacement when editable source remains incomplete.
Evidence hierarchy
- Preserve the working or last-known system as an image before repairs.
- Collect every source copy, installer, executable, OCX/DLL and configuration file.
- Inventory registry entries, DSNs, services, scheduled tasks, shares and connected devices.
- Match binary timestamps and versions to candidate source trees.
- Rebuild in isolation and compare critical workflows with the deployed application.
Recovery choices
If the executable works, preserve it while reconstructing deployment separately. If source builds but output differs, investigate conditional constants, binary compatibility and missing generated artifacts. If essential source is absent, characterize required behavior and decide whether a narrow adapter or replacement is safer than attempting to recreate the entire application.
A program that simply will not start should first receive focused runtime diagnosis. Known control errors belong in OCX troubleshooting. Use source analysis when the codebase exists, and reverse engineering when behavior must be recovered from binaries.
What to provide
Disk images or access to the old PC, all source candidates, original setup media, sample data, exact business-critical workflows and acceptable downtime.