After the System Is Delivered, Who Owns the Code and the Data?

We've met plenty of companies whose real pain, when they come to us about a new system, isn't features. It's this sentence: "Our previous vendor won't give us the source code, and we can't get our data out." Want to change a feature? You have to go back to the original vendor and pay whatever they quote. Want to switch vendors? You discover the whole system is like a rented apartment — you've lived there five years, but all the furniture belongs to the landlord. This "held hostage" situation is extremely common in Taiwan's outsourced development market — and almost all of it can be avoided with a few clauses in writing before you sign.

In this piece we lay out, honestly and from the vendor's side of the table, the handover terms you should settle before commissioning development. Yes, many of these clauses are "unfavorable" to vendors — but our own delivery standard is full handover of code and data to the client, because we believe long-term relationships should be built on quality of service, not on clients being unable to leave.

First, understand: what you paid for may not be what you think by default

Many business owners assume "I paid for the development, so of course it's mine." Legally, not necessarily. Absent a specific agreement, copyright may vest in the party that actually did the development; and even if ownership is agreed, if the contract doesn't say "source code will be delivered," you may end up with a system that runs but not the code that lets you modify it, move it, or continue it. Ownership of rights and physical delivery are two different things — both need to be in the contract.

Also distinguish two models: custom development (built for you; full handover should be expected) versus subscribing to an off-the-shelf SaaS (you're buying a right to use; you were never going to get the source code, but you must have the right to export your data). Both models are legitimate. What's not legitimate is paying custom-development prices for SaaS-level rights. We covered how to choose in our build-vs-buy decision framework; this article focuses on what the contract should look like once you've chosen custom development.

Seven things the contract must state in writing

1. Full source code delivery: not "available on request," not "a CD at project close" — continuous delivery. Ideally a repository the client owns (such as the company's own GitHub organization), where the vendor develops and the client sees every update in real time. The era of a zip file at handover should be over.
2. Ownership of copyright, or a perpetual license: state that rights in the custom-built portions belong to the client, or at minimum secure an irrevocable, modifiable, perpetual license that can be transferred to the next vendor.
3. Complete database data and schema: data is the lifeblood of your operations. The contract should guarantee you can obtain a full database backup at any time, including documentation of the data structure — a pile of raw data with no field descriptions is nearly useless when you need to move.
4. Deployment documentation and environment handover: where the system runs, how it's deployed, which third-party services it uses, and whose name the accounts are in. Pay special attention here: domains, cloud hosting, and payment-gateway accounts must all be registered in the client's name, with the vendor holding only delegated access. We've seen too many cases where the domain was registered under the previous vendor, and after a falling-out the client couldn't even get their own website back.
5. A third-party component inventory: which open-source packages and paid services the system uses, and under what license terms. This prevents discovering, mid-takeover, that a core component's license is tied to the previous vendor.
6. A duty to assist with transition: on termination, the vendor is obligated to help the new team transition within a reasonable period, with the fee structure spelled out. Without this clause, "help" during a breakup is priced at whatever they feel like.
7. Tests and documentation: whether automated tests and basic technical documentation are deliverables. Code with tests is code the next team dares to change; code without tests makes every change a gamble. This is also why we treat automated testing and CI/CD as standard deliverables, not add-ons.

Good handover terms mean the client stays because they want to, not because they can't leave. A vendor willing to write the contract this way is usually a vendor confident in their own service.

How to test a vendor before signing

Beyond the clauses, here's a simple litmus test: ask them directly, "If in three years we want to move this system to an in-house team or another vendor, what's the process?" A healthy answer is concrete — how the repository transfers, what documentation exists, how transition support is billed. Dodging, vagueness, or flipping it around to "stick with us and you won't need to worry about that" — you already have your answer. Also ask for past examples of what they've actually delivered; you can browse our portfolio to get a feel for what full handover looks like.

A system will be used for five or ten years; the vendor relationship may not last that long. Settling handover terms clearly isn't distrust — it makes the partnership easier for both sides. It's how we run our own practice. If you're about to commission development, or you're stuck in a "can't get the code, can't move the data" situation and looking for a way out, talk to us, or start with how we describe our delivery approach in our custom systems and SaaS services.