The most dangerous point in an application takeover is often not the day the repository changes hands.
It is the first time the new team needs to change production.
The code is available. Access has supposedly been transferred. A few architecture diagrams exist. Everything looks under control until an engineer needs to modify a service and starts finding questions the handover never answered.
Which configuration is production actually using? Is the documented deployment process current? Does this database migration need to happen before or after the application release? Is the unusual-looking code a mistake or an intentional compatibility requirement? Which external account owns the production webhook?
Until the new team can answer questions like these using evidence rather than assumptions, it does not fully control the application.
Taking over an app built by another development team is the process of turning inherited code, infrastructure and knowledge into a system the incoming team can independently understand, build, test, deploy, monitor and recover.
That means a good takeover is not primarily a repository transfer.
AWS's Well-Architected guidance recommends evaluating the operational readiness of the workload, its processes, procedures and personnel, supported by runbooks, playbooks and explicit production-support plans. AWS: Operational Readiness and Change Management
That is a useful way to think about application takeover as well. The incoming team needs to prove that it can operate the system, not merely inspect its source code.
A new team will almost immediately find things it wants to change.
Naming conventions look strange. Architecture feels unnecessarily complicated. Old dependencies are visible. Several modules appear overdue for refactoring.
Resist the urge to clean everything up during the first week.
The incoming team does not yet know which unusual decisions are accidental and which exist because of an important constraint.
A piece of duplicated code may look like technical debt until you discover that two customers are running different API contracts.
An old worker may appear unused until you discover that it processes an important overnight reconciliation job.
The first stage should therefore be discovery before modification.
Record observations and suspected risks, but separate:
We know this is a problem
from:
We do not yet understand why this exists.
That distinction prevents a takeover from turning into an accidental redesign.
The incoming team should first verify that it actually controls the systems it has been asked to maintain.
That normally means confirming access to source repositories, cloud environments, CI/CD, databases, monitoring, logs, ticketing systems, documentation and important third-party services.
Do not assume access has transferred because somebody sent a credential spreadsheet.
Log in.
Verify permissions.
Confirm who owns the underlying organization or account.
Production-critical assets should generally remain under appropriate organizational control rather than relying on a former developer's personal email address or cloud account.
Repository permissions deserve particular attention. GitHub, for example, allows teams to define code ownership and require review from relevant owners before changes are merged. GitHub: About CODEOWNERS
When ownership changes, repository protections, administrators and CODEOWNERS definitions should change with it.
A team should not discover during an urgent fix that the only person authorized to approve production code left the previous vendor three months ago.
Before reading thousands of lines of code, create a system inventory.
The objective is to understand the application's major moving parts.
Capture the important repositories, deployable services, databases, background workers, queues, scheduled jobs, infrastructure components, environments and external integrations.
Then connect them.
A useful first architecture map does not need every function or table. It should answer questions such as:
Where does a user request enter?
Which service handles it?
Where does data live?
Which systems communicate asynchronously?
Which external services participate?
Which processes run without a user request?
The Microsoft Azure Well-Architected Framework recommends clearly defined practices across design, deployment and operation, including standardized source control, documentation, infrastructure, testing, monitoring and incident management. Microsoft: Operational Excellence Checklist
For an incoming team, the first objective is to determine which of those systems already exist and where important gaps are hiding.
One of the best takeover tests is deceptively simple:
Can an engineer who did not work on the original application get it running from the repository and documentation?
Use a clean development environment rather than a machine that already contains years of undocumented configuration.
Follow the stated setup process.
Install prerequisites.
Configure local services.
Run database migrations.
Start the application.
Run its tests.
Every undocumented intervention is evidence.
If a former developer has to say:
“Oh, you also need this environment variable.”
write it down.
If a dependency only works with one specific runtime version, record that version.
If a database seed file is missing from the repository, identify how test data is supposed to be created.
DORA's guidance on version control recommends storing far more than application source code: teams should also version test and deployment scripts, infrastructure definitions, database-migration assets, supporting configuration and other artefacts needed to reproduce environments. DORA: Version Control
A successful local build is therefore an early proof that the system is beginning to become reproducible rather than dependent on the previous team's machines and memory.
Architecture diagrams tell you where components are.
Real workflows tell you how they behave together.
Choose several business-critical journeys and trace them through the application.
For example:
User submits order
↓
Web application
↓
Orders API
↓
Database
↓
Queue
↓
Fulfilment worker
↓
External fulfilment provider
Follow the actual code, logs and infrastructure rather than assuming the documentation is correct.
This exercise reveals hidden dependencies quickly.
You may discover that an apparently simple feature depends on a nightly batch process, a shared database table or an integration that nobody included in the original architecture diagram.
It also gives the incoming team a much better model for future diagnosis.
When a customer later says “orders are stuck,” engineers already understand where an order can become stuck.
Being able to build the application locally is not enough.
The next major takeover milestone is reproducing the release process.
Ideally, begin in a non-production environment.
The incoming team should be able to answer:
How is a release created?
Which tests and approvals run?
Where are artifacts stored?
How are database changes applied?
What configuration differs between environments?
How is deployment verified?
How is the previous version restored?
DORA's deployment-automation guidance recommends repeatable processes that use the same deployment approach across environments, separate environment-specific configuration from application packages and perform deployment tests after release. DORA: Deployment Automation
An inherited application may be far from that ideal.
The takeover still needs to reveal the actual process.
If deployment contains five manual console changes that only the previous developer understood, those steps belong in the takeover risk register.
Do not wait for an urgent production fix to discover them.
Running the tests once is not enough.
Determine what the existing test suite actually protects.
Look for evidence around critical workflows, integration behavior and historically fragile areas. Identify tests that are routinely skipped, flaky suites nobody trusts and functionality that relies almost entirely on manual regression.
The question is not:
How many tests are there?
It is:
If we change this application, which failures can the existing tests reliably warn us about?
DORA's test-automation research emphasizes that automated tests need to be reliable enough that passing tests increase confidence in release readiness and failing tests represent meaningful feedback. DORA: Test Automation
If the application's test protection is weak, record that explicitly.
The incoming team can then compensate with more cautious changes and targeted manual testing while improving coverage in high-risk areas.
Pretending weak tests provide confidence is considerably more dangerous than knowing they do not.
A takeover is incomplete if engineers can change the application but cannot understand its live behavior.
Review:
Then test whether the information is actually useful.
Pick a known request and trace it.
Can the team find the corresponding application logs?
Can it distinguish application failure from third-party failure?
Does an alert identify an owner and a next action?
AWS recommends treating observability as part of operational health and establishing baselines that help teams investigate, intervene and improve workload operations.
For Levelworks, Observable and Explainable & Debuggable App Health become particularly important during takeover. The incoming team should not inherit a production system whose behavior can only be understood by reproducing customer problems manually.
Some of the most important takeover knowledge lives outside everyday development.
Ask the incoming team to demonstrate how it would handle routine and emergency procedures such as restarting a failed worker, restoring data, rotating an important credential or investigating a production alert.
AWS recommends maintaining runbooks for understood operational procedures, including required tools, permissions, error handling and escalation paths. AWS: Use Runbooks to Perform Procedures
A good takeover should test those instructions.
If a runbook says:
Restore database from backup.
the incoming team still needs to know which backup, where it is stored, who has permission, what happens to dependent services and how recovery is verified.
Operational documentation becomes trustworthy when another person can execute it.
Third-party integrations create a common takeover blind spot because part of their configuration exists outside the codebase.
For each important provider, determine the purpose of the integration, authentication mechanism, production account, technical owner and relevant configuration.
Pay particular attention to:
A secret may exist in production without anybody knowing which vendor account created it.
A webhook may point to the correct application but belong to an account controlled by the outgoing agency.
That is not merely a documentation problem.
It is an ownership problem.
Transfer organizational control before assuming the application can be operated independently.
Knowledge-transfer sessions are most valuable when they capture things that cannot easily be inferred from code.
Do not spend the limited overlap period watching someone read the README aloud.
Ask questions such as:
What parts of the system make you nervous?
Which components fail most often?
What should never be changed casually?
Which manual procedures still exist?
What technical decision looks strange without its history?
Which upgrade has been postponed?
Which customer-specific behavior is easy to miss?
These questions uncover the reasoning behind the application.
Record important answers in durable documentation.
DORA's documentation research emphasizes clarity, findability and reliability as characteristics of useful internal documentation. DORA: Documentation Quality
[Internal Link: “The Application Handover Checklist: What Documentation Should Your Development Team Provide?”]
That article covers what the outgoing team should provide. During takeover, the incoming team needs to test whether the material is actually sufficient.
One of the best takeover artefacts is not a document describing what the team knows.
It is a list of what the team does not yet know.
Examples might include:
Purpose of legacy_customer_sync job still unclear.
Production database restore has not been rehearsed.
Ownership of mapping-provider account unresolved.
No evidence yet that rollback works after schema migrations.
These are not admissions of failure.
They prevent assumptions from becoming invisible.
Give important unknowns an owner and decide whether they must be resolved before full operational responsibility transfers or can remain as tracked maintenance risks.
This is considerably safer than allowing uncertainty to disappear into somebody's notes.
Once the incoming team understands enough of the system, record the starting condition.
For Levelworks, the App Health framework can help organize that baseline without turning takeover into a giant audit.
The most relevant aspects may include:
App Health aspect
Takeover evidence
Observable
Can engineers understand production behavior?
Tested
Can important changes be validated confidently?
Version Controlled
Are important code, configuration and delivery assets traceable?
Well Documented
Can knowledge survive without the original developers?
Current & Updated
Are major technologies within supported ranges?
Seamlessly Updatable
Can the application be released safely and repeatedly?
Explainable & Debuggable
Can failures be traced without extensive guesswork?
The purpose is not to fix every weakness before takeover.
It is to stop inherited weaknesses from being mistaken for problems caused by the incoming team later.
This baseline also helps separate transition work from ordinary ongoing maintenance.
[Internal Link: “How to Scope an Application Maintenance Engagement”]
Once control has transferred, resist the temptation to prove the new team by tackling the hardest architectural problem first.
A smaller, low-risk change can validate the entire operating path:
Understand
↓
Change
↓
Review
↓
Test
↓
Deploy
↓
Observe
That gives the team evidence about the repository, test suite, release process, permissions and production monitoring without combining every unknown into one risky release.
AWS recommends frequent, small and reversible changes because limiting the scope of change makes troubleshooting and remediation easier. AWS Well-Architected: Prepare for Operations
The first few releases are part of the takeover.
Treat them as controlled validation of the team's understanding.
The calendar alone should not decide when transition ends.
A stronger set of acceptance criteria asks whether the incoming team can independently:
Capability
Evidence
Build
Reproduce the application from source
Understand
Explain major architecture and critical workflows
Test
Run and interpret existing test suites
Deploy
Release safely through the agreed process
Observe
Diagnose production behavior using available telemetry
Operate
Execute important runbooks and support procedures
Recover
Understand backup, rollback and recovery paths
Administer
Access and control required accounts and environments
Maintain knowledge
Update documentation without the outgoing team
Not every inherited application will score well on every capability.
The incoming team simply needs to know the gaps, the associated risk and the plan for addressing the important ones.
[Internal Link: “Why Good Documentation Makes an App Cheaper to Maintain”]
Taking over an application does not require understanding every line of code before accepting responsibility.
That would be unrealistic.
It does require replacing hidden dependency on the previous team with evidence: reproducible builds, controlled access, understood architecture, tested deployment, usable telemetry, documented procedures and a clear list of remaining risks.
There will still be surprises months later. Mature applications contain history that no transition process can completely uncover.
The difference is how the new team meets those surprises.
Instead of beginning with “Who from the old team might know this?”, it has repositories, logs, architecture, runbooks, ownership and operational evidence to investigate from.
That is the real point at which an inherited application becomes maintainable by its new team.
The code may have changed hands on day one.
Operational ownership is earned by proving that the team can work with it safely after everyone else has left the room.
