The developer left. The code still runs.
That does not mean anyone can safely change, deploy, or recover it.
Software handoff feels like a code problem, but the dangerous part is usually operational memory: one laptop, one forgotten cron job, one production table, or one manual release step nobody else has ever run.
Before you rewrite everything or rush a hire, recover control with these seven handoff facts.
1. Source code and release history
Confirm the canonical repository, production branch, latest deployed commit, dependency versions, build command, and where release notes live. If the app only runs because the original builder remembers five missing steps, you do not have a handoff yet.
2. Deployment path and rollback path
Write down how production is deployed, who can deploy, what happens on failure, and how to roll back without relying on memory. If deployment lives in one person's terminal history, that is the first risk to close.
3. Environment and access map
List required cloud projects, domains, DNS records, email services, app stores, analytics, and admin consoles. Do not pass raw secrets around. Rotate them and store them in the right place.
4. Database, files, and backups
Identify production databases, storage buckets, migrations, manual edits, backup frequency, and the restore procedure. An untested backup is not a backup. It is a hope.
5. Integrations and scheduled jobs
Find every payment, CRM, messaging, spreadsheet, webhook, cron, worker, and third-party API dependency. Check what fails silently when a token expires or a service goes down.
6. Critical user workflows
Name the workflows the business cannot pause: signup, payment, quote request, report generation, admin approval, inventory sync. Confirm how each one starts, where its data lands, and how failure shows up.
7. Maintenance owner and change rule
Assign one person to own incoming requests, incidents, and release decisions for the next 30 days. Define which changes are allowed before the audit is complete.
Green, yellow, or red?
- Green: repo, deploy path, database, backups, and critical workflows are documented and repeatable. Continue maintenance and add small tests around the risky workflows.
- Yellow: the system works, but deployment, data, or ownership rely on one person's memory. Run a handoff audit before feature work.
- Red: no one can safely deploy, restore, test, or explain a critical workflow. Freeze non-urgent changes, recover access, map production, and diagnose whether rescue or rebuild is safer.
The first 72 hours
If the business depends on the software, use the first 72 hours to reduce unknowns, not add features:
- Freeze risky changes. Keep only urgent fixes, access recovery, and backup verification in scope.
- Map what is live: domain, hosting, database, jobs, integrations, analytics, and active users.
- Test one critical workflow end to end.
- Choose the smallest safe path: maintenance, rescue, a build-ready blueprint, or a data and deployment review.
Should you rewrite when the developer is gone?
Not by default. A rewrite moves every hidden rule into a new project while the business still needs the old system to run. Before choosing rewrite, answer three questions: does the system still match the business workflow, can the dangerous parts be isolated behind a stable interface, and can the team explain the data and integration rules well enough to rebuild them? If the answers are unclear, diagnose first.
For a second opinion, Omni Care keeps two free routes:
- Software handoff guide and risk levels: https://care.omniai.one/blog/software-handoff-when-developer-leaves/?utm_source=devto&utm_medium=article&utm_campaign=software_handoff&utm_content=handoff_guide
- Software diagnostic: https://care.omniai.one/software-diagnostic.html?utm_source=devto&utm_medium=article&utm_campaign=software_handoff&utm_content=software_diagnostic
The useful next step is simple: recover the operating map, close the risks that block real users, then decide whether to maintain, rescue, or rebuild.
Top comments (0)