What Should You Collect Before a New Team Takes Over Your Custom Software?

When a new development team takes over an existing application, source code is only part of the handoff. The team also needs to understand how the software runs, who controls its infrastructure, and which behaviors your business depends on.

Start by gathering six things: source code, account ownership information, build and deployment instructions, a map of integrations, critical business workflows, and known problems. You do not need perfect documentation before bringing in help. Missing information is itself useful: it tells the incoming team where discovery needs to begin.

This checklist helps business and technical leaders prepare for that first conversation.

1. Source code and its history

Identify where the application’s source code lives and who can grant access. If possible, preserve the repository’s history alongside the current code. Past changes can help explain decisions that are difficult to understand from the latest version alone. Useful materials include:

• Repositories for the application, background services, and supporting tools.
• The branch, tag, or release associated with the production application.
• Dependency files and build configuration.
• Automated tests and instructions for running them.
• Issue trackers and release notes.

One important question is whether the available source code actually matches the software running in production. If nobody knows, flag that uncertainty rather than assuming the latest repository version is the deployed version.

2. Account ownership and access

A team may have the code but still be unable to deploy a fix because another person controls the hosting account, domain, or application store listing.

Create an inventory of the accounts that keep the application operating. Depending on the system, this may include hosting, domain registration, databases, storage, app stores, monitoring, and third-party services.

For each account, record:

• What it is used for.
• Who owns or administers it.
• Who handles billing and renewal.
• How the incoming team can obtain appropriate access.

Keep passwords, API keys, and other secrets out of the handoff document. Record where they are managed and arrange access through your organization’s approved process.

If an essential account belongs to a former employee or contractor, identify it early. Resolving ownership may require coordination beyond the development team.

3. Build, deployment, and recovery instructions

Ask a practical question: could someone other than the previous developer build the application and deploy a change?

Gather any instructions, scripts, or recordings covering:

• Setting up a development environment.
• Building and testing the application.
• Deploying to staging and production.
• Required configuration and environment variables.
• Rolling back an unsuccessful release.
• Backing up and restoring data.

Include manual steps, even if they seem obvious to the current team. An undocumented command or configuration change can be the difference between a repeatable deployment and a process that depends on someone’s memory.

For backups, record when restoration was last tested, if known. Having backup files and knowing how to recover a working system are separate things.

4. Integrations and recurring jobs

Applications often depend on systems that are not visible in their main interface.

List external services, internal systems, scheduled jobs, and data exchanges. Examples might include payment processing, authentication, accounting systems, reporting feeds, or software that communicates with hardware.

For each connection, capture what it does, who supports it, and what happens if it fails. Note any deadlines or schedules that matter: a nightly import or month-end export may be critical even if it runs infrequently.

An approximate diagram is useful. It does not need to be polished to help the new team ask better questions.

5. Business workflows and exceptions

Documentation should explain what people need the software to accomplish.

Choose a few critical workflows and walk through them with the incoming team. Include examples of expected inputs and outputs, using sanitized data where needed.

Pay particular attention to exceptions:

• A customer receives different pricing.
• An approval follows an unusual sequence.
• A report uses a calculation that differs from its apparent definition.
• Users follow a workaround to avoid a known problem.

Identify who can explain these behaviors and confirm whether they should remain. Something that looks unnecessary in the code may represent a business rule that still matters. These walkthroughs give engineers a basis for reviewing and testing future changes.

6. Known problems and immediate commitments

Give the new team a clear picture of what needs attention first.

Bring together known defects, recent incidents, performance concerns, and outstanding requests. Add upcoming commitments such as a customer launch, contract renewal, or required platform update.

Separate urgent operational problems from desired improvements. “Users cannot complete orders” calls for a different response than “we would like a new reporting dashboard.”

This helps the incoming team plan its first work without assuming every item belongs in an immediate rewrite.

What if the original developers are already gone?

Gather what you can and mark the gaps. Do not delay the conversation until the checklist is complete.

Existing staff, support tickets, system logs, repository history, and vendor records can all contribute to discovery. A new team can investigate missing technical details, but it will still need access to people who understand how the business uses the application.

The first deliverable may be an assessment of what is known, what remains uncertain, and what must be addressed before changes can be made confidently.

Start with a walkthrough

A useful handoff package can be simple: an inventory of systems and account owners, links to available technical materials, a list of known issues, and a walkthrough of the workflows that matter most.

At Art+Logic, we begin by understanding the application and its business context. That assessment helps determine what needs stabilization, what can remain, and where modernization would be worthwhile.

For a broader explanation of the process, read The Original Developers Are Gone. What Happens to Your Custom Software Now?. If you are preparing to transition an existing application, talk with Art+Logic about the handoff.