A missing developer does not automatically mean the application is broken or that the previous work was poor. It does mean knowledge and access may be concentrated in one place. The first goal is to reduce uncertainty without disrupting a system that may still be serving users.
Do not begin with a rewrite
A rewrite is a major product decision, not an emergency reflex. Preserve the current application, collect evidence, and understand the architecture before deciding what should be repaired, replaced, or left alone.
1. Inventory the accounts that keep the product alive
- Domain registrar and DNS provider.
- Source-code organization and repositories.
- Hosting, deployment, database, file storage, and background-job services.
- Transactional email, authentication, payments, analytics, monitoring, and other integrations.
- App-store, certificate, package-registry, and vendor accounts where applicable.
2. Confirm organizational control
Record the account owner, recovery email, billing owner, administrators, and multi-factor authentication method for each critical service. Move away from personal accounts where the provider supports organizational ownership. Do not remove existing access until replacement access is tested and the effect is understood.
3. Preserve before changing
Capture the deployed version, current environment configuration, database and storage backup status, DNS records, active integrations, scheduled jobs, and current billing. Rotate a credential only when the team knows where it is used; an unplanned rotation can take a healthy service offline.
4. Find the source of truth
Locate the repository and determine whether it matches production. Review branches, deployment history, environment setup, database migrations, issue tracking, and any runbooks. If code exists only on a machine or in a generated platform, preserve an export before experimenting.
5. Establish operational visibility
Collect recent application errors, hosting events, failed jobs, support reports, and security notifications. Confirm who receives alerts and whether logs are retained long enough to investigate recurring problems.
6. Freeze unnecessary risk
Pause nonessential releases and major dependency upgrades until the incoming team understands deployment and rollback. Urgent security or availability work may still be necessary, but it should be isolated and documented.
What a new team should deliver first
- A verified access and ownership inventory.
- A plain-English system map and list of immediate risks.
- A backup and recovery assessment.
- A prioritized stabilization plan with assumptions and unknowns clearly labeled.
- A communication cadence appropriate to the urgency of the system.
A safe takeover begins by making the system understandable and recoverable—not by changing everything at once.
