In this guide 6 sections
Start by confirming who has legal authority to hand the software over, then collect every account and document. Reproduce the application in an isolated environment to learn what really runs. Assess dependencies, data and security, and fix continuity risks before any cosmetic change.
Confirming authority and collecting everything
Confirm authority before any technical work. That usually means the business itself, or someone it has authorised, requesting access from the current or previous vendor, and the new team should never act on assumption. Once authority is clear, ask for everything at once: source repositories, database access, hosting and domain credentials, API keys, deployment scripts and whatever documentation exists, however thin.
Take a showroom whose agency closed overnight. The agency built its catalogue and quoting tool, and the new team should not write a line of code when the export arrives. The first job is an inventory. Is there a database backup, are there keys for the payment and SMS services, and is there a deployment script, or only application code with nothing to run it?
Reproducing the application in isolation
Next, run it somewhere safe. Build a staging environment, separate from production, using only what was handed over, because that is the fastest way to find what is missing. Typical gaps include a build that fails without an undocumented environment variable, a dependency version that no longer installs, and configuration that lived on the previous vendor’s machine.
Isolation also protects customers. Discovery work in staging carries no risk to the live system, and each gap found becomes an item on a punch list instead of a surprise during an incident.
Dependencies, data, security and deployment
Now assess what the application depends on. Note which third-party services it calls, which of those accounts the business controls and which belong to the previous vendor, what data is stored where, and how deployment works. Draw the map on one page. Boxes for the application, database, mail service, payment gateway and scheduler, with an arrow for each call between them, make hidden connections visible.
Check basic security hygiene here too. Credentials found in the codebase may still be live, so rotate them now that a new team has seen them, and scan the dependencies for known vulnerabilities. Aim for a working list, not perfection. Nothing should keep running silently on an account or subscription that only the previous vendor can reach, because that is how a service disappears without warning.
Continuity risks before anything else
Continuity beats improvement at this stage. A credential still held by the previous vendor, a domain close to expiry, a certificate about to lapse and a backup job that stopped each threaten the software’s survival. Check expiry dates in a spreadsheet today. Registrar, certificate authority, cloud billing and every paid API each have a renewal date, and a lapsed card on any one of them can take the application offline overnight.
Larger changes can wait. Refactoring old code, upgrading a major framework or redesigning a workflow raises outage risk in a system whose dependencies are still being mapped. Wait until continuity is secured.
Takeover report and staged support plan
End with a short written report. It records what arrived, what was missing, which continuity risks were fixed and what technical debt remains, giving the business a document instead of one engineer’s memory.
Then stage the support. Start with a period of closer monitoring while the new team learns the unfamiliar system, and move to a standard maintenance cadence once the highest-risk unknowns are resolved. Give every open item a named owner. A named engineer and a named business contact, with a review date in the calendar, keep technical debt from turning into forgotten debt.
Application takeover checklist
A running checklist for the handover itself. It lists the access and credentials to request and what to verify by rebuilding the application in isolation. Dependency and security items to assess follow, then the contents of the final takeover report.
Open a blank worksheet to printQuestions owners ask
Can takeover proceed without documentation?
Yes, though slower and riskier. The isolated rebuild becomes the main source of truth, so the new team learns what the application needs by trying to run it instead of reading a manual.
What access should the business supply?
As close to everything as exists. That means repository access, hosting and server credentials, domain registrar access, a database login or recent backup, third-party API keys and any deployment or pipeline configuration. More access means less guessing.
How long does a takeover take?
It depends on what arrives. A small application with a clean export and a recent backup can be reproduced within days, while one with missing keys and undocumented configuration may need weeks of discovery.
Should the old vendor be involved?
Yes, if the relationship allows it. A single call with the previous team about undocumented environment variables, scheduled jobs and third-party accounts can save days of reverse engineering, even when the handover is otherwise unfriendly.