Picture a furniture manufacturer's dealer ordering system. It was built four years ago by a freelance developer, and since then a few small changes have been requested every month, all made by the same person. Then the developer moves on to another job. The goodbye is polite, with a "call me if anything comes up". Three weeks later a dealer reports that the order screen won't open, and nobody in the company knows how to log in to the server.
This happens more often than people think. The agency that built the software closes, or turns to other work, or the only in-house developer resigns. The code usually still sits somewhere; what disappears is the knowledge of how the system stays up. In this story we walk through which steps to take, and in which order, during the first two weeks of handing such a project to a new team or a new vendor. The goal is not to build anything new yet; it is to know what you actually have.
1. Start with a list of every access
Accounts come before code, because a company that has the code but cannot reach its domain is in a worse position than one with no code but every account in hand. Put these in a table: the registrar for the domain and whose email the account is under, where DNS is managed, the server or cloud account, the database, the repository holding the code (GitHub, GitLab, Bitbucket), the App Store Connect and Google Play accounts, the email sending service, the payment provider, the SMS provider, and paid API keys such as maps or AI.
Add two questions next to each row: is the account in the company's name, or in the departing person's personal account? And can someone at the company log in to it today? Anything sitting in a personal account should be transferred to the company while the relationship is still good. After the transfer, remove the departing person's permissions and rotate passwords and API keys. You are doing this not to blame anyone, but to make clear whose hands the system is in.
2. Find out which code is actually running
The code in the repository and the code running on the server are not always the same. An urgent fix may have been made directly on the server and never pushed back. Or a half-finished branch that never shipped may look like the most recent version.
The most reliable way to tell is to compare: download the files from the server and diff them against the last released version in the repository. For a mobile app the same question applies to the version number in the store: which commit was version 2.4.1 on the App Store built from? If you cannot answer that, every later change is made on top of an unknown codebase. Once you find the differences, commit all of them and tag the result as "what is live now"; every piece of work from here starts at that point.
3. Set the system up from scratch on a clean machine
The new team's first concrete task should be to install and run the project on a clean machine. This is where every unwritten piece of knowledge surfaces: which PHP or Node.js version is needed, which environment variables must be set, how the database is created, which service has to be mocked locally.
Note every point where setup gets stuck and put those notes in a README at the root of the project. When you are done, you have a system the next person joining the team can bring up in a day. If setup never succeeds, that is a valuable finding too; it shows the system only runs on that one server in its current state, and that the smallest server problem could turn into a long outage.
4. Take a backup and try restoring it
The answer to "are we backing up?" is usually "yes, I think so". The right question is: can you rebuild the system from that backup? Take a current copy of the database and of the files users have uploaded, restore it in a separate environment and confirm the application opens with that data.
This test tells you two things: whether the backup actually works, and how long it would take to bring the system back in a disaster. After that, make sure backups run automatically, that the copy is stored somewhere other than the same server, and that someone runs a restore test once a month.
5. Scan dependencies and known vulnerabilities
On projects one person has looked after for a long time, framework and library updates usually get postponed. List the packages and put the version in use next to the current version for each. Tools such as npm audit, composer audit or GitHub's dependency alerts quickly list known security holes.
You are building this list to see the risk, not to start updating right away. A library two minor versions behind and a server running an operating system that no longer receives security updates are not equally urgent. For mobile apps, the stores' yearly requirements come on top of this; an app whose target SDK version has fallen behind may not have its next update accepted by the store at all.
6. Talk to the people who use it
Code tells you what the system does; it does not always tell you why. Hold half-hour conversations with two or three people who use the system every day in accounting, the warehouse or the field. Ask which screen they use most, which job they solve outside the system in Excel, and which error they now accept as "normal".
These conversations often uncover business rules buried somewhere in the code: a different discount for a particular dealer group, a transfer triggered by hand at month end, a report only one specific person can make sense of. Writing them down keeps the new team from breaking a rule without realising it.
7. Pull everything into one written report
At the end of the two weeks you should have a short document: the access table and which accounts were transferred, which version of the code is live, the setup steps, the result of the backup test, the dependency list and the risks found, and the business rules that came out of the user conversations. In the last section, sort the risks into three groups: what must be fixed this week, what to plan within the next three months, and what can safely wait for now.
This report is the ground every later decision stands on. The scope of a maintenance agreement, the first month's task list, even the question of whether the system needs to be modernised, are all discussed with this document on the table. Without a written assessment, any price or timeline you are given is no more than a guess.
In short
When the person or company that built your software leaves, the first job is not to add features but to learn what you have. Move the accounts to the company and rotate the passwords first, then find which code is live, set the system up on a clean machine, try restoring from backup, scan the dependencies, listen to the people who use it and gather everything into a single report. Those two weeks turn the years of maintenance that follow from guesswork into a plan.
Our software maintenance and support service starts with exactly these steps: we review the source code, dependencies, servers and access, share a written report of risks and priorities, and only then take over the maintenance.
Planning a project like this?
Plan it in 10 steps