Quick answer
When your software developer leaves, first secure ownership and access to source code, hosting, domains, databases, email services and third-party accounts; rotate credentials; confirm backups; document how to deploy and restore; then commission a technical assessment of code quality, security and risks before planning further development with a new team.
Key takeaways
- Secure access to every account before anything else.
- Rotate credentials the departing developer used.
- Confirm backups and the ability to deploy.
- Assess the system before committing to new features.
Who this guide is for
Business owners whose developer, freelancer or agency has left, stopped responding or is ending the relationship.
List everything you need access to
Make a list: source code repositories, hosting and cloud accounts, domain registrar, DNS, SSL certificates, databases, email delivery services, payment gateways, app store accounts, analytics, third-party APIs and admin panels. For each, confirm who owns the account and whether your organization has administrator access. Check invoices and email receipts for services you may have forgotten, since these often reveal subscriptions and accounts created by the developer.
Secure ownership and access
Ask the developer to transfer accounts to your organization’s ownership or add your administrators. If the relationship ended badly, check contracts for ownership clauses and contact providers directly with proof of ownership where needed. Domain and hosting accounts are the most critical, because losing them can take your service offline.
Rotate credentials
Change passwords, API keys, database credentials and SSH keys the developer used, after confirming you have working access. Update applications that use those credentials so services keep running. Remove the developer from shared accounts and review access logs if available. Do this in a planned window, one service at a time, and test after each change so a missed configuration does not take the system offline unexpectedly.
Confirm backups and recovery
Check whether backups of code, databases and uploaded files exist, where they are stored and when they last ran. Perform a test restore to a separate environment if possible. If no backups exist, create them immediately before making any changes. Store at least one copy of the backup in an account your organization controls and the former developer cannot access, and record where it is.
Document how the system runs
Gather or create documentation on architecture, environments, deployment steps, scheduled jobs, integrations and known issues. If the developer is cooperative, a recorded walkthrough is valuable. If not, a new developer will need time to reverse-engineer this, which should be planned and budgeted. Even a short document covering servers, environments, deployment commands, scheduled tasks and external services greatly reduces the risk of the next transition.
Commission a technical assessment
Before adding features, have an experienced engineer review code quality, dependencies, security vulnerabilities, test coverage, hosting setup and maintainability. The assessment should identify urgent risks and estimate the effort to stabilize. This informs whether to continue with the current codebase, refactor or plan a rebuild.
Plan the transition
Choose a new maintenance arrangement with clear ownership terms. Start with stabilization tasks such as security updates, monitoring and documentation before resuming feature work. Keep all accounts under your organization and require documentation as part of every future engagement, so you are not dependent on one person again.
Scope checklist
- Do you have administrator access to every account?
- Are domain and hosting owned by your organization?
- Have credentials been rotated?
- Has a backup been restored successfully?
- Is there documentation on deployment and integrations?
Frequently asked questions
What should I do if my developer stops responding?
Secure access to accounts you can control, especially domain and hosting, check contracts for ownership terms, back up data and engage a new developer for assessment.
Can a new developer take over existing software?
Usually yes, with access to source code and infrastructure. Expect an assessment period, especially if documentation is missing.
Who owns the source code of custom software?
It depends on your contract. Many contracts assign ownership to the client upon payment; check your agreement and ensure future contracts state it clearly.
Prepared with AI assistance as an engineering decision guide. Examples are illustrative unless explicitly labelled as an internal implementation. No independent expert review or customer outcome is claimed.
Concerned about an existing system?
Share what the system does, who maintains it today and what is going wrong. Scope, access, dependencies and commercial terms are agreed before delivery. Do not submit passwords, API keys or confidential records.
