In this guide 6 sections
Secure access first, then capture knowledge. Move the repository and cloud accounts into company ownership, list every credential and scheduled job, and use the notice period for recorded handover sessions. Then decide between an augmented engineer to keep building or a rescue project to stabilise the code.
Secure the accounts on day one
Do this before anything else, and do it calmly. The developer is not your enemy. Still, a departing person who owns the only admin login is a risk to everyone, including them, and a clean transfer protects both sides.
Open each system and check who the owner really is. Often the domain sits in a personal registrar account, the app store listing uses a personal Apple ID and the repository lives under a personal GitHub profile.
Add yourself, or a trusted person, as owner on each one. Do not remove the developer’s access yet. That waits for the last working day.
- Domain registrar and DNS provider
- GitHub, GitLab or Bitbucket organisation
- Cloud console root user and billing email
- Apple Developer and Google Play accounts
- Email sending service, payment gateway and SMS provider
Find what lives only in one head
Sit with the developer for a half day and ask them to walk the production system aloud. Record it. Ask where code runs, how it is deployed and what happens at night when nobody is watching.
Look for scheduled jobs on the server crontab, certificates that expire in the spring, environment files copied by hand and scripts that run from a laptop. These break first. They break quietly. Nobody notices.
Ask the awkward question. What would you not touch without a backup? The answer usually points to the oldest and riskiest module, the one where a single careless edit could stop invoices, bookings or logins.
Use the notice period for handover, not just goodbyes
Turn the weeks ahead into a plan with dated sessions. One on deployment, one on the database, one on third party integrations and one on the known bugs. Record each and file the video next to a written summary.
Ask the developer to do a real deploy while someone else watches, then have your replacement do the next one with the developer watching. Doing it once is the best check that the notes are true.
Agree the last day in writing. Cover laptops, tokens and any personal repositories that hold copies of your code, and ask the developer to confirm deletion in an email.
- Deploy walkthrough done by the outgoing developer
- Second deploy done by the new person
- Database backup restored to a test server
- Every API key listed with its owner and expiry
Cover the gap: augmented engineer or rescue project
An augmented engineer suits a product that works but needs a person. They join before the resignation takes effect, shadow the developer and take over tickets from the backlog.
A rescue project suits a product nobody dares to change. A small team audits the code, adds tests around the risky parts, upgrades old frameworks and writes the missing documentation before feature work resumes.
Many businesses need both, one after the other. Ask for a short code review first. It tells you which of the two you are really buying.
What to do this week
Make three lists today. Accounts and who owns each. Scheduled jobs and what they do. Open customer promises that depend on the product, such as a release date or a fix.
Tell the developer you want a respectful handover and ask what they would need to make it work. Many will help if treated fairly.
Then book a call with a vendor who can place an engineer within the notice period. Send them the first of your three lists.
Developer departure triage sheet
Four blocks share a single sheet. Accounts lists each system, current owner, new owner and date changed. Hidden knowledge lists scheduled jobs, manual deploy steps and expiry dates. Handover plan lists dated sessions with a recorded video link. Cover decision holds the choice of augmented engineer or rescue project and the start date.
Open a blank worksheet to printQuestions owners ask
Should we cut the developer’s access straight away?
Not usually. Give yourself ownership first, then remove access on the last day or when trust is lost. Cutting it early can make handover harder.
Can a new engineer take over a codebase in the notice period?
Often a working handover is possible if the system is small, deployments are scripted and the developer cooperates. For tangled code, expect a slower takeover and consider a code review first.
What if the developer will not share credentials?
Check the contract for ownership of work and company accounts. Many credentials can be reset through the service provider because you own the account. Take legal advice if the dispute is serious.
How do we avoid this next time?
Keep accounts in the company’s name, document deployment and add a second engineer who reviews code. Even a part time second person removes the single point of failure.