Software Knowledge Transfer Checklist When the Developer Is Gone

Reviewed by the DESSS engineering team

A software knowledge transfer checklist tells you what to secure and record when the person who built your application has left, retired or gone out of business. Taking over such a system is mostly detective work, done in a sensible order: protect access first, prove you can recover it, then work out what it does. Many companies handle part of this themselves and bring in application maintenance support for the rest. These are the steps, whichever route you take.

Protect Access Before Anything Else

The most dangerous moment is often the first one. Accounts may belong to someone who has left, and domain names or cloud subscriptions may sit on a personal credit card.

Start by listing every account the application touches, and find out who controls each one. That includes servers, cloud consoles, DNS, certificates, source control, email services, payment gateways and vendor portals. Move ownership to a shared company account, change shared passwords and record where the credentials are stored. If a former developer still has access, deal with that through the proper channels, and keep the relationship civil. You may want to ask them a question later.

If a departing developer is still reachable, ask for an hour of their time. Even one recorded conversation about the awkward parts of the system can save days of guesswork.

Prove You Can Recover It

Next, find out whether the backups work. Many teams discover the truth about their backups on the worst possible day.

Locate the most recent backup of the database and any uploaded files, restore them to a separate machine and confirm the application runs against that copy. If you cannot do this yet, it becomes your most urgent task. Check how often backups run, where they are kept and whether anyone gets told when one fails.

Find the Code and Check That It Is Real

Having source code and having the right source code are two different things. Older systems were often patched directly on the server, leaving the copy in the repository out of date.

Compare what is in source control with what is actually running. For compiled applications, try to build the code and compare it with what is deployed. Look for installers, third-party libraries, license keys and old development tools you would need in order to build it again. Put everything into a modern source control system, even if it is messy, so that every future change leaves a trail.

When the source is missing

Missing code changes the picture considerably. Decompilers may recover part of some older languages, though you should check the license terms and expect rough results. Often the better path is to treat the application as a black box: keep it running in isolation, document what it does from the outside and plan its replacement.

Map What Connects to It

Applications rarely stop at their own edge. Make a list of what feeds this system and what depends on it.

• Scheduled jobs and scripts, including ones running on someone's desktop
• File drops, shared folders and FTP transfers
• Database links, stored procedures and direct queries from other tools
• Reports and exports that finance or operations rely on
• APIs, email alerts and third-party services

Look at scheduled tasks on every server, then ask the people in each department what would break if the system vanished. Month-end and year-end jobs are easy to miss, since nothing visibly depends on them most of the time.

Capture the Business Rules

The most valuable knowledge is usually buried in code and in people's heads. Sit with the heaviest users and watch them work. Ask why they do things in a particular order and what they do when the system gets something wrong. Their workarounds often point straight to a defect or a missing feature.

Then trace the most important calculations through the code, such as pricing, commissions or inventory valuation. Write down each rule in plain language, together with a real example showing inputs and the expected result. Those examples become your first test cases.

Knowledge Transfer Checklist

Tick these off in order. Anything you cannot complete belongs on your risk list.

• ☐ All accounts and subscriptions are listed, with a company owner for each
• ☐ Shared passwords are changed and stored in a managed vault
• ☐ Domain names and certificates are held in company accounts
• ☐ A database and file backup has been restored and tested
• ☐ Source code is in company-controlled source control
• ☐ Deployed code has been compared with the repository
• ☐ Build tools, libraries and license keys have been located
• ☐ A separate test environment runs the application
• ☐ Scheduled jobs and integrations are listed
• ☐ Reports and their owners are identified
• ☐ Key business rules are documented with examples
• ☐ Known defects and workarounds are written down
• ☐ Deployment and restore steps have been tested by a second person
• ☐ Software versions are checked against vendor support dates

What to Document, and How Much

Long documents go stale, so aim for a small set people will actually open.

Keep these with the code, and update them as part of each change.

Decide What Comes Next

With the facts in hand, you can make a calm decision. Three outcomes are common. The system may be sound and only need steady maintenance. It may be valuable but fragile, which calls for tests and targeted cleanup. Or it may be so tied to unsupported parts that planning a replacement makes sense, and our application modernization services page describes that path.

Avoid deciding on appearances. Old code that works is not automatically a problem, and shiny new code can carry plenty of risk of its own.

Frequently Asked Questions

What if we no longer have the source code?

First, search everywhere: old servers, backups, former staff laptops, contractor archives and vendor agreements. If nothing turns up, keep the application running in isolation, document what it does from the outside and plan to replace it. Decompiling may help with some older languages, but check your license terms and expect incomplete results. Treat the application as high risk meanwhile.

Can we contact the original developer?

Yes, if you can do so properly. Check any contract for ownership and confidentiality terms, and offer to pay for their time. Ask specific questions about deployments, unusual jobs and known problems, and record the session with permission. Keep expectations modest, since memories fade, then verify what they tell you against the code and the running system.

Who owns the code a former contractor wrote?

That depends on your agreement and on applicable law, and the answer may surprise you. Do not assume that paying for software automatically transferred its copyright. Locate the contract and any later assignment, then ask your attorney if the wording is unclear. This matters most before you modify, resell or hand the code to a new vendor.

How do we know whether the application is worth keeping?

Compare how much the business depends on it with how risky and expensive it is to change. Look at incident history, the backlog of requests, support status of its components and how many people understand it. If it works well and changes rarely, keeping it may be the best decision. Reassess whenever a major component loses vendor support.

Need Help Taking Over an Application?

Contact DESSS and tell us what you have, even if that is only a server and a login. We can work through this list with your team and give you a plain-language risk report.