Taking responsibility for an existing application is not a matter of receiving source code and hoping the setup instructions still work. A safe takeover transfers access, operating knowledge, deployment control, support responsibility and an honest record of what remains uncertain.
01
A repository is not a software handover
Imagine an established business with a customer portal that handles orders, documents and account updates. The current supplier is leaving in four weeks. The source repository has been shared, a folder of notes has appeared and everybody would quite like the change of developer to feel administrative.
The application is still live. Somebody is paying for its hosting, renewing the domain, running releases, receiving error alerts and answering support questions. Scheduled jobs may move data every night. Payment, email and identity services may depend on accounts that are not mentioned anywhere in the code.
Receiving the repository transfers one important asset. It does not prove that the incoming team can operate the service. A takeover is complete when the business can identify what is running, control the accounts around it, build and release the software, diagnose a failure and recover the important data without depending on the outgoing supplier.
That is the standard this checklist is built around. The first goal is continuity and evidence. Refactoring, new features and larger modernisation decisions come later.
02
Start with the business service that must keep working
Before reading controllers or arguing about architecture, follow the work the application supports. Which journeys protect revenue, customer service, compliance or the daily operation? Who notices first when one fails? What is the busiest or most time-sensitive period?
For the customer portal, the important journeys might be placing an order, uploading evidence, taking payment, issuing a confirmation and giving staff the correct status. A small background job that sends orders to another system may matter more than a large untidy section of the interface.
Record the people involved, the information used, external systems, manual workarounds and the acceptable length of an interruption. This creates a business map for the technical review. Without it, the incoming developer can spend a week tidying code that looks unpleasant while missing the quiet scheduled task that creates every invoice.
It also gives the takeover a useful stopping point. The aim is not to understand every historic decision before accepting responsibility. It is to know enough about the critical journeys to protect them, support them and make the first safe change.
03
Transfer ownership and access without breaking production
Build an account inventory before removing anybody. The outgoing developer may have a personal deploy key, integration token or billing account that production still uses. Revoking every account on the first morning can turn a tidy security action into an outage.
For each service, record the business owner, technical purpose, current administrators, recovery route, payment contact and anything that depends on it. The business should control the important organisations and accounts. Guest access inside a supplier-owned account is useful during a project, but it is not the same as ownership.
| Area | Evidence to obtain | What can fail if it is missed |
|---|---|---|
| Source and delivery | Repositories, history, pipelines, registries and deployment identities | The team has code but cannot reproduce or release it |
| Hosting and data | Cloud accounts, servers, databases, storage, queues and backups | A failure cannot be diagnosed or recovered |
| Public entry points | Domains, DNS, certificates, CDN and email delivery | The service or its communications can stop unexpectedly |
| External services | Payment, identity, messaging, analytics and API accounts | Important workflows fail outside the visible application |
| Operations | Logs, monitoring, alerts, support inboxes and incident history | Problems remain invisible until a user complains |
| Commercial ownership | Contracts, licences, billing contacts and renewal dates | A working dependency expires or cannot be transferred |
Use the least access each person needs. A developer inspecting a repository does not automatically need the power to delete it. Administrators and recovery methods should still have named owners, and critical accounts should not depend on one person's private email address or phone.
Once business-controlled replacements have been tested, rotate shared passwords, API keys, database credentials, deploy keys and webhook secrets in a planned order. Then remove outgoing access and confirm that deployments, scheduled work, alerts and integrations still operate.
04
Capture the production baseline before changing it
The repository may not match the system currently serving customers. Production can contain an emergency edit, a manually installed package, a scheduled command configured directly on a server or a database change that never reached the migration history.
Record the revision, release or artefact believed to be running. Capture runtime and framework versions, dependency lock files, environment names, deployment steps, database migration state and the infrastructure that receives the release. Do not copy secret values into the report. Record their purpose, owner and secure storage location.
Then compare the repository with observable production behaviour. Can the team identify the release that created the current screens? Does the production database structure match the migrations? Are scheduled jobs and queue workers represented in the code and deployment configuration?
If the running application cannot be traced to accessible source, say so. An unverified baseline does not mean the business must switch the application off. It means the first production change carries extra risk and needs an explicit decision, containment plan and better evidence.
05
Prove the build and release path
A setup guide is useful. A clean machine successfully building the project is evidence. Ask somebody who did not create the original environment to clone the repository, install the documented dependencies, create the application configuration and run the tests.
This exposes the private package, local certificate, missing environment variable or particular runtime version that exists only on the outgoing developer's laptop. Write down what was missing while the discovery is fresh rather than quietly fixing the machine and losing the lesson.
Next, deploy to a safe non-production environment through the same route the team intends to use in future. Confirm which checks run, who approves a release, where the artefact is stored and how the change would be rolled back. Reliable release engineering depends on repeatable builds and a defined path from source to production, not a command remembered by one person.
Do not rush to replace every manual step with a complex pipeline. First make the current process visible and repeatable. Automate the parts that remove dangerous variation, then improve the release route as the team learns how the system behaves.
06
Treat recovery as a test, not a green tick
A dashboard saying the backup completed is not proof that the business can recover. The incoming team needs to know what is included, where copies are stored, how long they are kept, who can access them and which order services must be restored in.
Restore a representative copy into an isolated environment. Check that the database opens, uploaded files are present and the application can use the restored data. Record how long the exercise took and which instructions were missing.
The test should follow the business service identified at the start. Restoring a database is not enough if the customer portal also needs object storage, encryption keys, DNS, a queue and an external identity provider before orders can be processed again.
Recovery objectives do not need impressive acronyms to be useful. The business needs a plain answer to two questions: how much recent work could be lost, and how long can the important service be unavailable? The takeover should show whether the current backup and recovery route can meet those expectations.
07
Map the work that happens outside the visible screens
Inherited systems often hide their most important behaviour at the edges. Scheduled tasks send reminders and invoices. Queues process uploads. Webhooks accept payment updates. External APIs enrich records. Server rules route traffic before the application sees it.
Create a dependency map covering databases, file storage, email, payments, identity, analytics, messaging, search, third-party APIs, queues and scheduled jobs. For each connection, record the business purpose, owner, failure behaviour, retry route and where useful evidence appears.
Then inspect the data model and migration history separately from the application code. Check for manual database changes, stored procedures, old columns still used by reports and integrations that read directly from tables. A neat set of models does not prove that production follows the same rules.
This is also the point to understand data protection responsibilities. The takeover should show what personal or sensitive information exists, where it flows, who can access it and which supplier accounts still hold a copy. The new team cannot manage software risk without understanding the information at stake.
08
Review code, dependencies and support history with restraint
Every incoming developer will find choices they would have made differently. That is not the same as finding a defect. A useful review separates personal preference from evidence that the application is unsafe, difficult to support or blocking a business need.
Check framework and runtime support, package maintenance, known vulnerabilities, authentication, permissions, secret handling, logging, error reporting, tests and the shape of the deployment configuration. Read recent incidents, support tickets and change history alongside the code. Recurring failures often reveal more than a style review.
Protect critical current behaviour with a small number of characterisation or end-to-end tests. These tests record what the inherited system does now, including awkward behaviour the business may still depend on. They create a safety net for later refactoring without pretending the existing result is ideal.
Rank findings by business consequence and likelihood. Missing ownership, an untested restore or an unsupported internet-facing component may need attention before duplicated code. The first report should help the business decide, not overwhelm it with every comment a developer could make.
09
Make the first independent change deliberately small
The clearest proof of a takeover is a controlled operation completed without the outgoing team. That might be restoring a backup, restarting a worker, investigating an alert or deploying a low-risk text change through the documented route.
Choose something observable and reversible. Confirm the expected result before starting, watch the logs and monitoring during the change and rehearse the rollback. Record what happened afterwards. The aim is not to demonstrate speed. It is to prove custody and expose the remaining assumptions while the risk is small.
Avoid combining the handover with a framework upgrade, database redesign and feature launch. Large changes destroy the baseline just as the incoming team is trying to understand it. Stabilise first, then decide which improvements are worth funding.
If the outgoing supplier is still available, ask them to observe rather than operate the change. Their knowledge remains useful, but the incoming team must be able to complete the route independently before the overlap ends.
10
Turn the audit into a takeover plan the business can use
The output should not be a dramatic code score or an automatic rewrite proposal. It should state what has been verified, what has only been inferred, which access is missing and which risks need a named owner.
Separate the work into continuity, supportability and improvement. Continuity covers the things that could interrupt the service now, such as missing business access, failed backups or expiring services. Supportability makes future work safer through monitoring, documentation, tests and a repeatable release process. Improvement covers product changes, deeper refactoring and modernisation.
Give each item a reason, priority, owner, evidence and next decision. Include commercial dependencies and business milestones so urgent technical work does not quietly consume the entire product roadmap. A good plan can protect the live application while still making room for new business value.
Agree how changes, incidents, budget and scope will be communicated after the takeover. The business should know who approves production work, who receives alerts, where decisions are recorded and how uncertainty will be reported. Clear governance is part of operational control, not project administration added afterwards.
11
A good takeover makes responsibility visible
A short review cannot reveal every hidden defect or recreate access that no longer exists. Documentation may be incomplete, production may have drifted and an external service may depend on an account the business cannot transfer. Those limits should be written down rather than polished away.
The handover is ready when the business controls the important assets and recovery routes, the incoming team can build and release the software, critical failures are visible, recovery has been tested and the remaining risks have owners. The repository matters, but it is only one piece of that evidence.
For the customer portal, the useful result is calm independence. Orders can continue, support has a route, the next release is controlled and the business can decide whether to support, modernise or replace the application from facts rather than fear.
That is what a responsible software project takeover should achieve. Transfer control first. Improve the system once the people responsible for it can see what they are changing.
Useful questions
Software project takeover acceptance checklist
- Does the business control the source repository, hosting, domains, billing and account recovery routes?
- Can the incoming team identify the exact version and configuration running in production?
- Can a clean machine build and run the application from the accessible source?
- Can the team deploy to a safe environment and explain the production release and rollback route?
- Have database migrations, the live schema, scheduled jobs and external integrations been reconciled?
- Has a representative backup been restored and checked in isolation?
- Are logs, monitoring and alerts available to the people expected to support the application?
- Are important workflows protected by a small, repeatable set of tests?
- Have shared secrets been rotated only after replacement access and machine identities were tested?
- Can the incoming team complete one controlled operational task and one small release independently?
- Are verified facts, assumptions, missing access and unresolved risks clearly separated?
- Does every immediate risk and future improvement have a named business owner and next decision?
