The developer is gone: how to keep the application running

When the person who built the application leaves, the first problem is not the code. It is the question of who controls servers, domains and access. After that come weeks in which nobody knows exactly which parts of the system are business-critical.

The first 30 days decide whether operations continue. This article describes the order in which the most important tasks make sense.

Secure access and control first

Start with a list of every access path. This includes servers and root access, the hosting or cloud console, the domain registrar, DNS, administrative email accounts, CI/CD, the Git remote, package registries, monitoring, backup storage, database access and third-party dashboards such as payment providers.

Check which accounts are tied to the person's private address. A password reset for an account whose owner is unreachable can take weeks, and for domains it is a real risk. Move those accounts to company addresses and enable two-factor authentication.

Do not remove any access before a replacement is proven to work. Lock accounts only after the new person has signed in and completed the most important tasks.

Use a password manager where every account has its own entry. Also review SSH keys and API keys: who holds them, where do they live, and which systems still accept them?

A system whose access nobody in the company owns is not owned by the company.

A full backup and a proven restore

Create a backup of files, database, configuration, secrets and certificates. Treat it as unverified until a restore has actually worked.

Rebuild the application from the backup in an isolated environment. Measure how long it takes. Store the result somewhere that does not depend on the failed system, and write down every step you perform. Those notes are the beginning of your operations documentation, and they are written while the system is still running.

Also check whether the existing backups are complete. A green backup job says nothing about whether the database is included or whether anyone can find the decryption key.

Build a picture of the system

Collect what the system consists of: repository and branch structure, deployment scripts, web server configuration, cron jobs, systemd units, running processes, open ports, queue workers, scheduled tasks, external integrations and DNS records.

Local changes on the server are a common find. Look for files that are not in the repository and for services nobody recognizes. A comparison between repository and server quickly shows where the real state lives.

The result does not have to be a complete architecture document. An overview of components, data flows and external dependencies is enough so that changes are not made blindly. Write down open questions next to the answers. An area nobody can explain is a finding in itself and belongs on the risk list.

Find and freeze critical dependencies

List everything outside your own server: payment providers, email and SMS sending, maps, tax services, ERP interfaces, commercial PHP packages, licenses, themes and fonts. Record deadlines and who owns each contract.

Domain names and TLS certificates belong at the top. An expired certificate takes the application down, and an expired domain endangers more than reachability. Also check whether invoices for third-party services go to an address nobody reads anymore.

Small services count too. A cron job that sends invoices through a provider API whose account runs on a private address becomes an outage as soon as the account is locked.

Until the system is understood, freeze changes: no framework updates, no new features, no server moves unless they are required for operations. This rule protects against changes whose effects nobody can judge. Security updates need an exception, but with a test and a fallback path.

Prioritize by business value

Not everything matters equally. List the flows that involve money or customer relationships: login, checkout, payment callbacks, invoice generation, exports, the customer portal and administrative approvals. Those get attention first.

A small safety net is enough to start: an uptime check, error alerts by email, a central log and a documented way to restart the application. A runbook for the most common failure is worth more than an extensive monitoring concept that does not exist yet.

For each critical flow, check whether it is tested today. Where no test exists, a manual walkthrough before the first change makes sense.

Cosmetic topics, outdated design or messy data can wait. They cost time but do not remove operational risk. The question is not whether a failure can happen but what it costs. A checkout that is down for two hours is a different problem from an export sorted incorrectly at the end of the month.

Communicate honestly with stakeholders

Avoid optimism that gets disproven two weeks later. Report what is secured, what is still unknown and where the risks are. Access, backup, system picture and dependencies are concrete items that can carry a status.

Name decisions rather than only problems. For example: by when will a named person take over operations? When will the decision on modernization or replacement be made? Which features can be dropped if the application fails?

Keep a simple risk list with four columns: item, status, owner, deadline. That document replaces long status reports and keeps the important decisions visible.

This communication is not an admission of weakness. It is the basis for the company making an informed decision instead of waiting for the next surprise.

Conclusion

The first 30 days do not decide how modern the application is. They decide whether operations are under control. The measure is not completeness but control over the systems the business depends on. Access, a proven restore, a system picture and a clear view of the dependencies create the basis for everything else.

If the application needs to be taken over and stabilized, that starts with code rescue. For ongoing operations and step-by-step improvement, application management is the right framework. The article takeover without documentation covers how to recover missing knowledge systematically, and signs of technical debt shows which risks to tackle afterward.