Implementation Services Agreements in New Zealand: What to Check Before Signing

Signing an implementation services agreement can lock your business into a project that is expensive, slow and hard to unwind if the scope is vague. A lot of New Zealand businesses get caught by the same problems: they accept the provider's standard terms without checking what is actually included, they rely on verbal promises about timing or functionality, or they assume the software contract and the implementation contract say the same thing when they do not. The result is often budget blowouts, finger-pointing and a system that goes live late or not as expected.

The good news is that most of these issues can be reduced before you sign. The key is to treat the implementation agreement as its own commercial contract, not just an attachment to a software deal. This guide explains what an implementation services agreement usually covers, the main legal points New Zealand businesses should check, and the mistakes founders and operations teams often make when they are under pressure to get a new system up and running.

Overview

An implementation services agreement sets the rules for how a vendor, consultant or technology partner will configure, install, migrate, integrate and deploy a software or IT solution for your business. It should spell out what work is included, when it will be delivered, what you must provide, what happens if the project changes, and who carries the risk if something goes wrong.

• Define the scope of services in detail, including deliverables, exclusions and assumptions.
• Match milestones, acceptance testing and payment triggers so you do not pay too much too early.
• Check change request rules for scope creep, delays and extra fees.
• Confirm who owns project outputs, customisations, data and intellectual property.
• Review liability caps, warranties, service levels and any broad exclusions of responsibility.
• Make sure privacy, data security and confidentiality clauses reflect the data being handled.
• Set clear customer responsibilities, including access, decision-making and internal resourcing.
• Include practical exit rights, termination consequences and handover obligations.

What Implementation Services Agreement Means For New Zealand Businesses

An implementation services agreement is the working contract for the project itself. It usually sits alongside a software licence, SaaS subscription or master services agreement, but it deals with the hands-on delivery work needed to make the system usable in your business.

For a New Zealand SME, this often covers ERP rollouts, CRM deployment, e-commerce platform setup, accounting system migration, integrations between apps, point of sale installation, or custom configuration for industry workflows. In practice, the business is not just buying technology. It is buying a process, a timeline and a set of commitments from both sides.

What the agreement usually covers

The document often includes a statement of work or project schedule. That is where the real detail should sit.

• Project scope and deliverables
• Timelines, milestones and go-live dates
• Data migration activities and assumptions
• Integration work with third-party tools
• Testing, acceptance and defect handling
• Training, documentation and post-go-live support
• Fees, expenses and payment timing
• Project governance, escalation and reporting

This is where founders often get caught. The sales discussions may suggest a full end-to-end setup, but the contract may only include limited configuration hours, generic onboarding or support during business hours. If the written terms and scope are narrow, that is usually what you are buying.

Why the New Zealand legal context matters

New Zealand contract law generally gives significant weight to the signed terms, especially in business-to-business deals. If something matters to your decision, it should be written into the agreement or attached schedules before you sign.

Depending on the parties and the way the services are supplied, other legal frameworks can matter too. If the provider is making claims about capability, timing or results, those statements can raise issues under fair trading rules if they are misleading. If personal information is being migrated, stored or accessed during the project, the Privacy Act 2020 may shape what the parties need to do around collection, use, security and notification. If implementation work is being supplied to a business in circumstances where consumer-style protections have not been effectively contracted out, service quality obligations may also need attention.

That does not mean every project needs a heavily negotiated contract. It does mean the agreement should reflect the real business risk. A small setup for low-value software will look different from a core system implementation affecting customer data, finance processes or fulfilment operations.

Why this contract is often different from the software contract

The software terms usually deal with access to the platform, user limits, subscription fees and licence rights. The implementation services agreement deals with project delivery. If you only review the software terms, you can miss major issues such as incomplete scoping, open-ended time and materials billing, or no meaningful remedy for late delivery.

Before you accept the provider's standard terms, compare the whole document pack and consider a contract review. Make sure the order of precedence is clear if two documents conflict. Otherwise, a broad disclaimer in one agreement can undermine a promise in another.

Legal Issues To Check Before You Sign

The main legal question is simple: does the agreement clearly allocate work, timing, cost and risk in a way that matches the project you think you are buying? If the answer is no, sort that out before you sign a contract or spend money on setup.

1. Scope of work and assumptions

The scope should be specific enough that an outsider could tell what the provider must deliver. Generic wording like "implementation support" or "configuration assistance" creates room for dispute.

Look for detailed schedules that set out:

• Exact modules, systems or business units included
• Specific deliverables, such as configured workflows, reports, integrations or migration scripts
• Items expressly excluded
• Technical assumptions, dependencies and third-party requirements
• Any limits on hours, support requests or revisions

Assumptions matter because they often become the reason for extra fees. A vendor may price the project on the basis that your data is clean, your staff are available for workshops, or your existing systems can support a standard integration. If those assumptions are wrong, the project can expand quickly.

2. Milestones, timing and delays

Dates should be tied to real obligations, not just described as estimates unless that is genuinely acceptable to you. If timing matters because of seasonality, investor reporting, warehouse changes or a planned site move, say so in the contract.

Check:

• Whether milestone dates are fixed, estimated or dependent on your actions
• What counts as a delay caused by the customer
• Whether the supplier can extend time unilaterally
• Whether there are consequences for missing key dates
• Whether the go-live date depends on formal acceptance

Many agreements give the supplier broad relief for delay but very little accountability for their own slippage. A more balanced contract will document a project plan, include cooperation obligations on both sides, and require prompt notice if a date is at risk.

3. Acceptance testing and sign-off

You need a clear process for deciding whether the work has been completed properly. Without this, you may be pushed to sign off early or treated as having accepted the deliverables by silence.

A useful acceptance clause usually addresses:

• How long you have to test each deliverable
• The criteria for passing or failing testing
• How defects are classified, for example critical, major or minor
• The supplier's obligation to fix defects and resubmit
• Whether deemed acceptance applies if you start using the system

Before you rely on a verbal promise that "we'll sort bugs after go-live", check what the contract actually says. Some agreements limit post-delivery fixes to defects that prevent substantial use, leaving the customer to pay for anything else.

4. Fees, expenses and change requests

The payment model should match the level of certainty in the project. Fixed-fee arrangements can still blow out if the change control process is loose. Time and materials arrangements can become expensive if the scope is not tightly managed.

Review:

• Whether fees are fixed, capped, estimated or variable
• What expenses can be charged on top
• When invoices are issued and when payment falls due
• Whether milestone payments are linked to acceptance
• How changes are approved, priced and documented

A proper change request process protects both sides. It should require written approval for changes affecting price, timing or scope. That is especially important where internal teams informally ask the provider for additional work during workshops or testing.

5. Customer responsibilities

Your own obligations can be extensive, and missing them can give the provider a defence for delays or failures. Implementation projects often require strong internal project management from the customer side.

Check whether you must provide:

• Named project leads and decision-makers
• Access to systems, premises or cloud environments
• Test data, business rules and process maps
• Staff time for workshops, training and user acceptance testing
• Prompt approvals within set timeframes

If those obligations are realistic, fine. If not, negotiate them. A contract should not assume internal capacity that your team simply does not have.

6. Intellectual property and ownership

Ownership often becomes contentious when the project includes customisations, templates, reports, scripts or integration components. The contract should make clear what you own, what the supplier retains, and what rights each party has to use the outputs.

Common positions include:

• The supplier retains ownership of pre-existing tools, code and methodology
• You own your underlying business data and content
• Custom deliverables are either assigned to you, licensed to you, or shared in some limited way
• The supplier can reuse general know-how but not your confidential information

If the custom work is central to your operations, do not assume ownership transfers automatically just because you paid for it.

7. Data privacy, security and confidentiality

If the implementation involves customer records, employee details or commercially sensitive data, privacy and security terms are not optional extras. They are core risk points.

The agreement should address:

• What personal information the supplier will access or process
• Security measures and access controls
• Subcontracting and offshore access to data
• Incident reporting and response obligations
• Data return, deletion or retention at the end of the project

New Zealand businesses should consider whether the provider's processes line up with the Privacy Act 2020, particularly where data may be accessed from overseas. Confidentiality clauses should also be practical, covering project information, source data, pricing and business processes. In some cases, a separate privacy notice or data processing agreement may also be relevant.

8. Warranties, liability and remedies

This clause tells you what happens when the project goes wrong. A supplier will usually try to limit its liability heavily, but that does not mean every cap or exclusion is reasonable.

Pay close attention to:

• Any warranty that services will be performed with reasonable care and skill
• Any warranty that deliverables will materially conform to specifications for a set period
• Liability caps, and whether they are tied to the implementation fees only or all amounts paid
• Exclusions for indirect loss, loss of profits, data loss or business interruption
• Whether some liabilities are carved out, such as confidentiality breaches, IP infringement or wilful misconduct

The main risk is a contract that leaves you with little practical remedy even if the implementation fails badly. Liability wording should be weighed against the value of the project and the operational damage a failed rollout could cause.

9. Termination, exit and handover

You should know how to exit the project if it stops making commercial sense. Some implementation agreements are difficult to terminate without paying most of the remaining contract value.

Look for:

• Termination rights for material breach, insolvency or prolonged delay
• Termination for convenience, and what fees apply
• Obligations to hand over work in progress, documentation and data
• Reasonable assistance to transition to another provider or internal team
• Clear treatment of prepaid fees and outstanding invoices

If the provider controls system knowledge, documentation and access credentials, a poor exit clause can leave your business stuck.

Common Mistakes With Implementation Services Agreement

Most implementation disputes come from unclear expectations, not dramatic bad faith. The mistakes below are common because teams are busy, optimistic and focused on getting the project moving.

Treating the proposal as if it were the contract

A proposal or sales deck may describe an ideal outcome, but only the signed documents reliably set the legal position. If important promises sit in emails, demos or meeting notes, pull them into the agreement or a schedule.

Signing vague statements of work

Founders often assume a short scope can stay flexible. In reality, vagueness usually favours the party drafting the contract. If the scope is not detailed, extra work can be charged as a variation.

Paying too much upfront

Large upfront payments reduce your leverage if the project slips. A better structure usually links part of the fees to concrete deliverables and acceptance milestones.

Ignoring internal resourcing

Some projects fail because the supplier underdelivers. Others fail because the customer cannot provide data, approvals or subject matter experts on time. If your operations manager is also covering payroll, fulfilment and customer support, the contract should not assume instant turnaround on every workshop or sign-off.

Accepting broad deemed acceptance clauses

Some agreements say you accept the work if you do not reject it within a short period, or if you use any part of the system. That can be harsh when the system must be used for business continuity before testing is complete.

Overlooking data migration risk

Data migration is often where hidden complexity sits. The contract should say who is responsible for mapping, cleansing, validating and backing up data, and what happens if imported data is incomplete or corrupted.

Assuming all custom work belongs to you

Payment alone does not always transfer ownership. If custom reports, code or connectors are business-critical, confirm the intellectual property position before you sign.

Not checking subcontracting and offshore delivery

The consultant you meet in the sales process may not be the whole delivery team. If work will be subcontracted or handled offshore, ask how that affects quality control, confidentiality, time zones and access to personal information.

Missing conflicts between documents

A master agreement, order form, statement of work and software terms can pull in different directions. Make sure the contract says which document wins if terms conflict.

Relying on goodwill instead of process

When the relationship is positive, founders often skip formal change requests and project records. Problems usually appear later, when people remember conversations differently. Written approvals, meeting notes and issue logs are not overkill on a meaningful project.

FAQs

Is an implementation services agreement different from a software licence?

Yes. A software licence or SaaS agreement usually gives you rights to use the software, while the implementation services agreement covers the project work to configure, install, migrate, integrate or deploy it.

Should small businesses negotiate the provider's standard terms?

Often, yes. Even if the supplier will not rewrite everything, many will negotiate scope detail, payment milestones, acceptance testing, liability positions and data handling clauses for a meaningful project.

Who owns customisations created during implementation?

That depends on the contract. Some suppliers retain ownership and give you a licence, while others assign custom deliverables to the customer. The agreement should say this clearly.

What if the project scope changes halfway through?

The contract should contain a written change request process covering extra fees, revised timelines and approval steps. If it does not, scope changes can quickly turn into billing disputes.

Do privacy rules matter if the provider can see customer or staff data?

Yes. If personal information is accessed, migrated or tested during the project, privacy and security obligations should be addressed in the agreement, especially where offshore access or subcontractors are involved.

Key Takeaways

• An implementation services agreement should clearly define scope, deliverables, assumptions and exclusions.
• Payment terms should be aligned with milestones and acceptance, not just project commencement.
• Acceptance testing, defect correction and deemed acceptance clauses deserve close review before you sign.
• Change control, customer responsibilities and internal resourcing can decide whether the project stays on time and on budget.
• Data privacy, confidentiality, IP ownership and subcontracting need careful attention where business-critical systems or personal information are involved.
• Liability caps, warranties, termination rights and handover obligations shape your real remedy if the implementation fails.

If you want help with scope wording, acceptance testing terms, liability caps, privacy and data clauses, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.