What You Should Get Back When an Outsourced Project Closes: A Source-Code, Accounts, and IP-Ownership Handover Checklist

Opening: signed off, final payment made — but no source code

A retail owner spent NT$180,000 on a website. Six months later, wanting to switch vendors, they discovered the source lived in the vendor's personal GitHub, the domain was registered under the vendor's account, and payments were tied to the vendor's company. The question: is this site even mine? The answer usually lives in the contract and the handover checklist — and most people never check this stage at close. Here's a framework for what to get back so handover isn't the start of a lock-in.

Myths to break

Myth: I paid, so the code is mine. Reality: in Taiwan, copyright for commissioned work depends on the contract; without clear terms it may not go the way you assume (see the Copyright Act, Articles 11–12). Always specify assignment of economic rights in the contract.
Myth: handover just means admin credentials. Reality: those are the tip of the iceberg — source, domain, DNS, payments, third-party API keys, database, and deploy access all matter.
Myth: switching vendors is easy, just zip the files. Reality: a code bundle with no docs, no deploy guide, and no env-var list can cost the next team weeks to pick up.

Core framework: the handover quadrants

Sort what you must reclaim into four groups; a missing quadrant means you don't truly own it:

Code assets: Git repository (with full history), env-var list, database schema and export.
Accounts & domain: registrar, DNS, hosting/cloud, payments, third-party services — all transferred to your name.
Rights documents: assignment of economic rights, license scope, third-party package license list.
Knowledge docs: deploy guide, ops handbook, known issues and to-dos.

Three scenario comparisons

Micro (a small site built by a freelancer): focus on transferring the GitHub repo to your account and moving the domain; docs can be minimal.
Mid (a system with payments and members): payment-account ownership and database/PII handover are paramount; full env vars and deploy docs required.
Large (multi-system integration): needs full transfer of CI/CD access, cloud IAM, monitoring and alerting, plus a parallel-run handover window.

Hidden cost list

Domain-ransom cost: if the domain is under the vendor, transfer can stall days to weeks — costly when urgent.
No-docs rediscovery cost: the next engineer typically spends 20–40 extra hours reverse-engineering an undocumented project.
Payment re-binding gap: if the payment account isn't transferred, you may be unable to collect during the switch.
Hidden third-party renewals: paid APIs/fonts/plugins bound to the vendor's account surface only after handover, needing repurchase.

Vendor KPI scorecard

☐ Does the contract specify assignment of economic rights?
☐ Is source in your version-control account?
☐ Are domain and DNS registered under your name?
☐ Is the payment account your company entity?
☐ Are env vars and secrets provided?
☐ Are deploy and ops docs provided?
☐ Are third-party licenses listed and transferable?
☐ Is a full database export provided?
☐ Is there a parallel-run window and Q&A channel?
☐ Is the vendor's residual access removed after exit?

ScriptWalker's approach + when we don't fit

Our close-out is "all four quadrants delivered + 30-day Q&A window": code in your GitHub, all accounts transferred to you, with rights assignment and complete docs. Engagement can be single project, monthly retainer, or an advisory handover audit.

When we're not a fit (honestly):

You just want the cheapest one-off with no docs — our delivery standard shows in the quote.
You won't put rights ownership in writing — we insist on it in black and white.
You expect a lock-in-style dependency — we do the opposite; the cleaner the handover, the better.

Transition / handover playbook

Week 1: inventory the four quadrants; list accounts to transfer and docs to fill.
Weeks 2–3: transfer repo, domain, payments, and cloud access; sign the rights assignment.
Week 4: deliver docs, run parallel ops and training, remove old vendor's residual access.
Day-90 review: confirm the new team can deploy independently with no residual dependency.

Decision checklist

☐ I know whose account holds the source today
☐ My domain is registered under my name
☐ My payment account is my company entity
☐ I have the env-var and secrets list
☐ I have deploy and ops docs
☐ The contract has a rights-assignment clause
☐ I know which third-party paid licenses exist
☐ I have a full database export
☐ Old vendor access is removed after handover
☐ I've confirmed the new team can deploy independently

FAQ

I paid — is the copyright automatically mine?

Not necessarily. In Taiwan, rights for commissioned work follow the contract; without clear terms, economic rights don't automatically vest in the funder. Always state "economic rights assigned to the client" in the contract — this is the single most important clause.

What's the minimum I should reclaim at handover?

All four quadrants: code (Git history, env vars, database), accounts and domain (all transferred to you), rights documents (copyright assignment), and knowledge docs (deploy and ops guides). Admin credentials alone are far from enough.

The source is in the vendor's personal GitHub — how do I get it back?

Ask them to use GitHub's repository transfer to move it directly to your account or org, preserving full commit history, rather than handing you a zip. After transfer, confirm their collaborator access is removed.

What's the risk if the domain is registered under the vendor?

High: renewals, transfers, and DNS changes are all at their mercy — a stalled transfer can take down your site and email when urgent or when the relationship sours. Move the domain to your own registrar account and lock it.

Call to action

Not sure your project truly belongs to you? ScriptWalker offers a free 30-minute handover health check, using the four-quadrant list to inventory the assets and rights you should reclaim.