Software implementation partners: what partner agreements say about your work

Who owns the work an implementation partner does?#

Ownership of implementation work is split across three layers, and each layer controls different assets. The software vendor controls its platform and the terms of its partner program and APIs. The client controls its data and, usually, the deliverables it paid for. The firm controls what it brought to the project and the internal records it created while running the work.

Founders often assume partner status or a services agreement settles the question in one place. In practice a Salesforce, NetSuite or HubSpot consultancy needs to read all three layers together, because an asset the client contract lets the firm keep may still be restricted by vendor terms, and the reverse.

The three-layer rights table#

Use this table to sort any asset by the layer that governs it. Where two layers apply, the narrower one usually controls.

What vendor terms usually touch#

Vendor terms rarely claim a partner's own know-how, but they often limit what partners can do with data and environments the vendor provides. Partner program agreements commonly address trademarks, confidential roadmap material, demo and sandbox environments and conduct with joint customers. Developer and API terms govern data accessed through the platform.

API terms are tightening around AI. HubSpot's developer changelog says its updated Developer Terms restrict using data accessed through HubSpot APIs to train, fine-tune or improve AI or machine learning models, with a carve-out for legitimate single-customer use cases, and state that customer data belongs to the customer. A Hunton Andrews Kurth client alert reported that Salesforce changed the Slack API Terms of Service, effective May 29, 2025, to prohibit bulk exporting of data accessible through Slack's APIs and its use in large language models.

Platform terms also define what counts as the customer's material. In Oracle's NetSuite Terms of Service, Customer Data means content the customer provides that is stored in, or run on or through, the Cloud Service. Scripts and saved searches built inside a client's account sit close to that definition, which is one reason to treat them as client-side assets unless the contract says otherwise.

What client SOWs say about configurations and code#

Client contracts decide who owns deliverables, and most implementation SOWs give the client ownership of, or a broad license to, what was built for it. Read these clauses in every MSA and SOW before treating any asset as reusable.

Copyright law adds a wrinkle for contractor work. The Copyright Office explains that a work made for hire arises when an employee creates it as part of regular duties, or when a work in certain statutory categories is specially commissioned under an express written agreement. Software written by an independent contractor often falls outside those categories, so the firm generally needs a written assignment from the contractor, not just a work-for-hire label.

Evidence matters as much as wording. A pre-existing IP clause helps only if the firm can show an accelerator existed before the engagement, which is why dated commits in the firm's own repository are worth more than a folder of undated templates.

• 1Deliverables ownership: what the client owns on payment, and whether it includes code, documentation and configuration.
• 2Pre-existing IP carve-out: which firm tools and materials stay with the firm.
• 3License-back: the client's right to keep using firm tools embedded in its deliverables.
• 4Residuals: whether general know-how retained in staff memory stays usable.
• 5Confidentiality: how client confidential information is defined and how long the obligation runs.
• 6Return or destruction: what must be handed back or deleted when the project ends.

Reusing implementation assets: a decision table#

The table sorts common assets by whether a firm can usually reuse them with the next client and whether they could be considered for licensing to an AI developer. Treat it as a starting point for counsel, not a conclusion.

How to protect accelerators on future projects#

Accelerators are protected by habits before contracts. The firm that can show where an asset came from, who wrote it and which clients it touched will win most ownership questions without a dispute.

• 1Keep accelerators in a firm-owned repository with dated commit history, separate from client work.
• 2List named accelerators as pre-existing IP in each SOW, with a license-back to the client.
• 3Require written assignment of rights in every employee and contractor agreement.
• 4Rewrite client-specific solutions into generic form inside the firm's repository, never by copying a client export.
• 5Log which accelerators were used on which projects, so an audit can trace them.

Illustrative: a CRM implementation partner audits its assets#

Illustrative: a fictional CRM consultancy holds partner status with HubSpot and Salesforce and implements both for B2B software and professional services clients. Its assets include data migration playbooks, workflow and pipeline templates, Apex classes written inside client orgs, recorded discovery workshops and an internal assistant prototype that drafts configuration notes.

The founder asks counsel to sort everything by the three layers. Playbooks and templates kept in the firm's own repository, with history predating its client work, are confirmed as firm-owned. Apex classes written in client orgs stay with those clients. Several templates came from a former contractor with no assignment clause, so the firm obtains a written assignment before relying on them.

The assistant prototype raises the vendor layer: it had been tested on records pulled from client portals through APIs. The firm stops that use until the current developer terms are reviewed and rebuilds its test set from internal tickets and estimates with client details removed.

How SourceX approaches partner-firm records#

For implementation firms, the Rights step of the SourceX five-step transaction (Supply, Rights, Preparation, Approval, Delivery) applies the same three layers, separating firm-owned records such as internal tickets, estimates and methodology from client deliverables and anything accessed through vendor APIs, which is generally carved out.

Each package that proceeds gets a SourceX Evidence Packet, one record of provenance, licensing rights, permitted use, the privacy record and release authorization that the firm and the licensee both hold. The firm keeps ownership and approves every step.