Can Another Team Actually Run Your Software?

• A repository transfer proves one thing: the files moved. It doesn’t prove another team can run the product.

• Separate evidence received from evidence tested. A document can be present while the handover remains blocked.

• Accept the transition only after the receiving team can use business-owned access, identify the deployed version, build and release safely, explain operating responsibilities, name known limits and complete the agreed demonstrations.

• Every check needs a business owner, a receiving reviewer, an evidence location, a result and a next action. “We sent the docs” isn’t a result.

• A planned transition and an urgent vendor exit use the same acceptance standard. The sequence changes: planned handovers demonstrate while the outgoing team is available; urgent exits preserve authorized access and evidence before stabilizing unknowns.

• Don’t put secrets in the checklist, improvise on production or accept a gap because nobody knows who owns it.

A handover can look complete from the outside. The repository sits in your organization. A folder contains architecture diagrams. Somebody sent a password list. The outgoing team ran one final demo. Then the incoming team opens the project and discovers it can’t reproduce the build, can’t identify what version is live and doesn’t know who gets the first alert when a core task fails.

That isn’t a rare technical edge case. It’s the difference between possession and operating ability. Possession asks, “Did we receive it?” Operating ability asks, “Can the receiving team use it without the outgoing team taking over?” Your handover record needs both answers in separate fields.

This article starts after the ownership and exit terms exist. If you’re still choosing a supplier or negotiating those terms, use our guide to choosing a software development partner. Here, the question is narrower and harder: what must be demonstrated before another team accepts responsibility?

A useful acceptance sheet isn’t a list of files. It’s a decision record. Give every line the same fields:

• Item. The account, instruction, operating responsibility, known limitation or demonstration being reviewed.

• Business owner. The person accountable for the account, risk or acceptance decision.

• Evidence received. What arrived and whether it is complete enough to review.

• Access confirmed. Whether the receiving person can use their own authorized identity, not somebody else’s shared login.

• Evidence location. The repository path, provider account, release record or approved document location.

• Receiving reviewer. The person who tried the check and can describe what happened.

• Demonstration required. The observable task that turns a claim into proof.

• Test result. Pass, partial, fail, blocked, not tested or not applicable.

• Acceptance result. Accepted, accepted with conditions, blocked or not reviewed.

• Missing item, risk owner and next action. What remains, who carries the risk and what bounded step happens next.

Keep “received” and “tested” separate even when it feels repetitive. A release guide can be received while the release demonstration fails. A backup report can be received while the receiving team has never observed a restore. That tension is the point of the sheet.

Start with the accounts that can change access, billing, recovery or distribution. That usually includes source control, cloud or hosting, domain and DNS, app stores, email delivery, payments, storage, analytics and any provider that holds production data or can interrupt a critical workflow. Record the organization-controlled owner, current administrators, recovery contact and the receiving reviewer who confirmed access.

Don’t use the acceptance sheet as a secret store. Record a secret’s name, purpose, environment, approved storage location, owner and rotation responsibility. Leave passwords, private keys, recovery codes and secret values in the organization’s approved secret manager.

Provider transfers carry their own boundaries. GitHub’s repository transfer documentation says the repository history and several repository records move with a transfer, while associated settings still need review. That proves the repository moved. It doesn’t prove the incoming team can build or release it.

Distribution accounts make the same distinction visible. Apple’s app-transfer guidance describes continuity for the listing and bundle identifier but still requires direct exchange of code and build assets. Google Play’s transfer guidance lists account prerequisites and items that transfer differently or need separate handling. Use the current provider procedure for the account in front of you. Don’t generalize one provider’s steps to another.

The receiving team should be able to point from each deployed environment to an exact source revision using a release record, tag, commit or build identifier. “The main branch is current” isn’t enough. Main may have moved after the last release, and a branch name doesn’t explain which configuration or data change reached an environment.

Record the local, test, acceptance and production boundaries at the same time. Which data may appear in each one? Which external actions are real, simulated or disabled? Who can approve a production change? If nobody can answer those questions, don’t turn the handover into an experiment on production.

Then let a receiving team member start from a clean, safe workspace and follow the written setup. The goal isn’t to prove the outgoing developer can build it again. The goal is to discover every dependency that lives only in their machine, browser session or memory.

A release handover needs more than a command. It needs the approval point, the evidence an approver reviews, the expected health checks, the stop conditions and the response when a data change can’t be cleanly reversed. Run the normal path in a separate environment that is approved for the demonstration.

Ask the receiving person to drive. The outgoing team can observe and answer questions, but every undocumented intervention becomes a finding. If the outgoing developer takes over the keyboard to rescue the release, the demonstration didn’t pass.

Recovery needs the same treatment. A written backup policy or a screenshot of successful jobs is evidence received. A recent approved restore record, or a safe restore demonstration observed by the receiving reviewer, is evidence tested. Don’t copy production data into an unapproved environment to make the demonstration convenient.

A healthy planned transition should schedule demonstrations while the outgoing team is still available. Let the receiving team drive access, setup, build, release, monitoring and recovery checks. Record where it needed undocumented help, fix the instructions and repeat the failed step. The handover becomes part of normal delivery rather than a document dump on the last day.

An urgent vendor exit changes the order, not the acceptance bar. Preserve authorized business access, provider records, source history, release evidence and known contacts first. Don’t force an unplanned release, rotate a credential without understanding its consumers or test a theory against production. Mark what can’t be verified as blocked, name the person carrying the business risk and define a bounded stabilization action.

If account ownership is disputed, a provider transfer is unsupported or the contract is unclear, use the provider’s support process and qualified legal advice. A technical checklist can show an operational gap. It can’t decide legal ownership or guarantee a transfer outcome.

There isn’t a universal takeover timeline. A small web application with current instructions and business-owned accounts is a different job from a regulated product with multiple stores, data migrations and undocumented production jobs. Size the transition from the open demonstrations, not from a generic promise measured in days.

Once the build and release work, ask who notices and who responds. Name the person responsible for the first response when an important user task fails. Record who handles user reports, production incidents, stakeholder communication, provider notices, renewals, certificates, dependency updates and maintenance decisions.

Dashboards aren’t an operating model. If the receiving incident lead can see a chart but doesn’t receive the alert, the monitoring check is blocked. If two teams both believe the other one renews the domain, the renewal check is blocked. Our backend and infrastructure development page covers the broader work behind reliable releases, monitoring and recovery. The handover question is whether those responsibilities have actually moved to named people.

Known limitations deserve the same precision. Separate defects, deferred improvements, accepted constraints and unknowns. A product can be accepted with a documented limitation when the owner understands the consequence and the next action is explicit. It shouldn’t be accepted because the limitation was buried in a call nobody recorded.

1. Account and authority walkthrough

The business owner opens the account inventory. Receiving reviewers sign in through individual, supported roles and identify billing, access, recovery and production authority. Shared credentials don’t pass this check.

2. Deployed-version walkthrough

The receiving reviewer starts with the running environment and traces it to the exact release record and source revision. Then they identify the environment’s data and external-action boundaries.

3. Clean build and check run

A receiving developer follows the written setup in a clean, safe workspace, produces the expected build and runs the documented automated and manual checks. Known failures stay visible rather than being explained away.

4. Safe release and recovery walkthrough

The receiving team follows the normal release path in an approved non-production environment, identifies the production approval point and explains rollback or forward-repair decisions. Recovery is supported by an approved restore record or safe demonstration.

5. Monitoring and response walkthrough

The incident lead locates the signals for important user tasks, confirms the receiving alert route and explains who responds, escalates and communicates. Use only an approved test mechanism.

6. Independent closing walkthrough

The receiving team repeats the agreed access, build, release and operating steps without the outgoing team taking over. Every blocked or conditional result returns to the decision owner with a risk owner and next action.

The example below is fictional. Harbourlane Services is a made-up field-service business bringing a booking web app and staff dashboard from an external build partner into a small internal product team. It represents no Rigoris client, vendor, account, release, price or result.

The repository, build instructions and restore record all arrived. The transition is still blocked because the receiving team can’t yet demonstrate two operating responsibilities. That is what the received-versus-tested distinction is supposed to reveal.

Ask these questions after the receiving team attempts the demonstrations:

1. Starting from a clean safe workspace, what did you need that wasn’t in the written setup?

2. What exact source revision is running now, and how did you prove it?

3. Show the normal release path without changing production. Where does approval happen?

4. If a release fails, what can be rolled back and what needs a forward repair?

5. Who notices when the product’s important user task fails, and who responds first?

6. Which account or recovery path still depends on the outgoing team or a personal identity?

7. Which known limitation would you refuse to own without more evidence?

8. If the outgoing team became unavailable now, what task could you not complete?

For every answer, ask for the evidence location and put the gap back on the acceptance sheet. The interview is a way to find missing proof, not a confidence test.

Close the handover only when the decision owner can see what was received, what the receiving team tested, what remains conditional and who owns every open action. Acceptance doesn’t mean the software is perfect. It means the incoming team understands the product it is agreeing to run and can demonstrate the responsibilities in scope.

If the evidence is contradictory, an independent software build second opinion should tell you what can be operated now, which demonstrations are blocked and whether the next move is a normal transition, a bounded stabilization or a different delivery decision. The review should produce evidence another team can use, not a sales pitch for a rewrite.

The cleanest handover sentence is also the hardest one to fake: the receiving team did it, the reviewer saw it, the evidence is here, and the next action has an owner.