Implementation vs development vs licence — three contracts, three risk profiles
A major rollout involves at least two contracts — the vendor’s licence and the implementer’s services agreement — and they allocate risk very differently. Conflating them is how customers end up with a system nobody warrants.
| Contract | What you are buying | Where the risk sits |
|---|---|---|
| Software licence | The right to use the vendor's software within defined licence parameters — users, modules, environments. | Licence scope, fees and lock-in. The vendor warrants the software as licensed — not your configured deployment of it. |
| Implementation agreement | Professional services to configure, integrate, migrate data into and deploy software you license from a third party. | The gap between the implementer's promises and the vendor's licence — failed cutovers, migration defects, blame-shifting between vendor and implementer. |
| Development agreement | A bespoke software product built from scratch for you. | IP ownership (a written s 22(3) assignment), specification clarity, and acceptance of an entirely new work. |
The nine clauses that matter
Scope + solution design as the contractual baseline
The discovery phase must produce a solution-design document that is incorporated into the agreement as the baseline against which everything — acceptance, changes, delay — is measured. An implementation with no contractual baseline is an implementation with no objective measure of done.
The vendor-triangle problem
You hold a licence from the software vendor and a services contract with the implementer — and by default neither warrants the combined, configured system. The agreement must make the implementer's obligations back-to-back with the vendor's licence and state expressly who warrants fitness of the configured solution for your documented requirements.
Project governance + phase gates
A steering committee with defined authority, named roles on both sides (including the customer's own staffing and decision obligations), phase gates with go/no-go criteria, reporting cadence and an escalation ladder. Most implementation failures are governance failures before they are technical ones.
Data migration
Agreed accuracy thresholds, a reconciliation procedure with sampled sign-off, and an express allocation of who owns source-data cleanup (usually the customer) versus transformation defects (the implementer). Where the implementer touches personal information during migration, POPIA section 21 operator terms are mandatory; section 72 applies if offshore delivery resources access SA data.
Acceptance testing per phase + business-cutover criteria
Objective acceptance criteria for each phase, plus a distinct set of business-cutover criteria for go-live: end-to-end process tests on migrated data, integration tests, performance under realistic load, and defined defect-severity exit criteria. Deemed acceptance should be defined narrowly — productive use under protest is not acceptance.
Delay, delay damages and at-risk fees
Who bears schedule slip, and with what consequence: liquidated delay damages, or a holdback / at-risk fee earned only on milestone achievement. Balanced drafting pairs this with customer-dependency relief — the implementer gets schedule and cost relief where the customer fails its own obligations.
Change control
A written change-order procedure priced against a contractual rate card, with changes measured against the solution-design baseline. Without it, every scope conversation becomes a renegotiation and every renegotiation becomes a delay.
IP in configurations + integrations
The new IP in an implementation is modest but real — integration code, custom reports, migration scripts. The control test in section 1(1) of the Copyright Act applies to any code written (Haupt v Brewers Marketing Intelligence), so the agreement should expressly assign the work product under section 22(3) or grant a broad perpetual licence, with a licence-back for the implementer's pre-existing toolkits.
Exit + half-built-system rights
Termination assistance, delivery of all configurations, integration code, migration scripts, documentation and data extracts in usable form, rights to use the work product delivered to date, and cooperation with a replacement implementer. Without these, abandoning a failed project leaves you holding a half-built system you cannot lawfully use or hand over.
Common SA implementation disasters — and the clauses that prevent them
Go-live without acceptance
The disaster: Under deadline pressure the system is cut over before testing completes. Defects surface in month two, and the implementer argues that productive use amounts to deemed acceptance — leaving the customer paying full fees for a broken system.
The clause that prevents it: Go-live requires written sign-off against defined cutover criteria; production use under protest does not constitute acceptance; a fee holdback is released only on acceptance.
The unbounded T&M discovery phase
The disaster: An open-ended time-and-materials "discovery" stretches from six weeks to six months, burning budget before any configuration work begins — with nothing contractually deliverable to show for it.
The clause that prevents it: A capped or fixed-price discovery phase with a defined deliverable (the solution design), and a customer right to walk away at the end of discovery taking the design with it.
The migration data-quality dispute
The disaster: Migrated records do not reconcile to the legacy system. The implementer blames dirty source data; the customer blames the transformation logic. Neither party agreed who owned what, so the dispute is unresolvable on the contract.
The clause that prevents it: A pre-migration data-quality assessment, agreed accuracy thresholds, a reconciliation procedure with sampled sign-off, and express allocation of source-data cleanup to the customer and transformation defects to the implementer.
Key-person churn
The disaster: The A-team that ran the sales cycle and discovery rotates off after signature, replaced by juniors learning the platform on your budget. Velocity collapses; institutional knowledge of your design walks out the door.
The clause that prevents it: Named key personnel, customer approval rights over replacements, minimum-continuity commitments, knowledge-transfer obligations, and rate relief where substitutions degrade delivery.
Frequently asked
What is the difference between a software implementation agreement and a software development agreement?
A development agreement governs the building of bespoke software from scratch — the central legal issues are specification, IP assignment and acceptance of a new work. An implementation agreement governs professional services performed on software you license from a third-party vendor: configuration, integration, data migration and deployment of an ERP, CRM or core system. Little new software is written, so the central risks shift from IP ownership to the vendor triangle, migration accuracy, phase-gated acceptance and exit rights over a half-built system.
Who is liable when the implemented system fails?
By default, possibly nobody useful. The vendor warrants the software only within its licence terms; the implementer warrants its services and workmanship; neither automatically warrants that the combined, configured system will run your business. The classic result is the implementer blaming the software and the vendor blaming the configuration. The fix is contractual: the implementer warrants that the configured solution will meet the documented requirements in the solution design, with its obligations drafted back-to-back against the vendor's licence so there is no gap between the two.
Should an implementation be fixed-price or time and materials?
Neither, purely. Pure T&M removes the implementer's delivery incentive and produces unbounded discovery phases; pure fixed price forces the implementer to price unknowns before discovery, which inflates the quote and breeds change-order friction. Best practice is a phased hybrid: a capped or fixed discovery phase producing the solution design, then fixed or capped pricing per subsequent phase against that baseline, with an at-risk fee or holdback earned on milestone and cutover acceptance.
What should acceptance testing cover at business cutover?
Cutover acceptance is distinct from phase acceptance. It should cover end-to-end business processes running on migrated production data, all integrations to surrounding systems, performance under realistic load, and reconciliation of migrated records and balances against the legacy system. Exit criteria should be defined by defect severity — typically no open severity-1 or severity-2 defects and an agreed cap on lower severities — with go-live requiring written sign-off and deemed acceptance defined narrowly so that emergency productive use does not waive your rights.
Who owns the configurations and integration code the implementer builds?
Computer programs are a separate category of work under section 2(1)(i) of the Copyright Act 98 of 1978, and the author of a computer program is the person who exercised control over its making — section 1(1), as applied in Haupt v Brewers Marketing Intelligence 2006 (4) SA 458 (SCA). In an arms-length implementation the implementer usually controls the making, so it owns the integration code and scripts by default; pure configuration settings may not qualify as a "computer program" at all, leaving ownership murkier still. That is why an express assignment (which section 22(3) requires to be in writing and signed) or a broad perpetual licence — with a licence-back for the implementer's pre-existing tools — matters even where the new IP looks modest.
How do I stop the vendor and the implementer blaming each other?
Three structural tools. First, back-to-back drafting: the implementer's service obligations are aligned clause-by-clause with the vendor's licence and support terms so no responsibility falls in the gap. Second, single point of responsibility: the implementer takes contractual ownership of the solution outcome and manages the vendor relationship, including escalation into vendor support (most credible where the implementer is an accredited partner of the vendor). Third, for high-value rollouts, a tripartite agreement or direct vendor commitments that align defect classifications and escalation paths across all three parties.
What happens if we abandon the implementation halfway?
Without exit drafting, you hold a half-built system you cannot lawfully use: the configurations and integration code belong to the implementer, the documentation is incomplete, and a replacement implementer starts from scratch. The agreement should give you termination for convenience on payment for work done, delivery of all configurations, integration code, migration scripts, documentation and data extracts in usable form, an assignment or licence of the work product effective on payment, and transition assistance at agreed rates — so a failed project ends as a salvage operation, not a write-off.
What does a software implementation agreement cost to draft in South Africa?
From R15,000 for a single-phase implementation or systems-integration agreement. Enterprise rollouts — multi-phase ERP or core-system implementations with migration schedules, back-to-back vendor alignment and tripartite elements — typically run R25,000 to R40,000. Where the implementer will process personal information during migration or support, POPIA section 21 operator terms (and section 72 cross-border terms for offshore delivery centres) are drafted into the same agreement.