IT, online stores and brand protection · Czechia and Slovakia
Implementation agreement
Deploying an existing system for a client is legally different from bespoke development. Scope depends on analysis, the schedule on the client's cooperation, and success on acceptance tests. We prepare an implementation agreement connecting these three elements, so the supplier knows what to deliver, the customer knows what to expect, and both parties know when the work is complete.
- Lawyer registered with both the Czech and Slovak Bar Associations
- For suppliers and customers
- Fees agreed in advance
What we'll do for you
The most common implementation dispute is “that was outside the scope” versus “that is what we ordered”. A good agreement addresses this in advance, through analysis that establishes the scope and acceptance that closes it.
Select an item to see the details.
-
Analysis and solution design
We establish the initial phase contractually — its output is an approved design defining the implementation scope. This also covers a separate analysis agreement where phases are procured separately.
-
Scope and schedule
Milestones, stages and exactly what the fee includes — with rules for scope changes (change requests) and their effect on price and deadlines.
-
Client cooperation
Who supplies data, access and people, and by when — and what happens to deadlines and price if cooperation is delayed. This is the most frequent stumbling block in implementations.
-
Acceptance
Test scenarios, defect categories, deadlines for objections and deemed acceptance — making “complete” a legal status rather than a feeling.
-
Licences and the solution's future
Licence terms for the deployed solution, bespoke modifications, documentation and transition to maintenance (SLA).
Deliverablean implementation agreement with clear scope, milestones, an acceptance process and cooperation rules
How it works
Does this process fit your matter? Describe it to the attorney →
- Consultationday 0
We review the project, pricing model and risk areas, and recommend an agreement structure.
- Draft agreement
We prepare the agreement, including schedules (scope, timetable and acceptance scenarios), and refine it with you.
- Negotiation with the other party
We support you in responding to the other party's comments — we know which concessions are safe.
- Signing and the project
The agreement is signed and the project proceeds under it; we remain available for changes in scope.
No-obligation enquiry
Ready to start?
Send us an enquiry. We usually reply within 24 hours with a price confirmation and next steps. The first 30-minute consultation is free and commits you to nothing.
- 1Send your enquiry via this form
- 2Usually within 24 h you get a price confirmation and plan
- 3We start work only after your approval
Not keen on calls or email? Message us on WhatsApp →
Prefer to book a time right away? Book a consultation →
Or email us about this matter.
What clients ask
Didn’t find your question? Ask us directly →
How does an implementation agreement differ from a software development agreement?
The first question is whether implementation requires a separate agreement at all. If you commission bespoke software, deployment is usually a phase of the development agreement and no separate document is needed — what matters is that the development agreement actually covers acceptance and deployment, which we ensure when drafting it. A separate implementation agreement makes sense where no new work is created: an existing product is deployed, a supplier other than the software's author performs the implementation, or the phases are procured separately. Their substantive focus differs — development centres on specifications and rights to the result; implementation on scope established by analysis, client cooperation, integrations and acceptance. We cover mixed projects (deployment + bespoke modifications) in one combined agreement.
Why have a separate analysis and solution design phase?
Analysis turns expectations into an approved document — which becomes the measure of scope. Without it, disputes revolve around emails and presentations from the sales stage. Analysis may also be procured under a separate agreement before deciding on the entire implementation; we prepare both.
The client is not cooperating and the project has stalled. What can we do?
The agreement addresses precisely this scenario by defining the cooperation the client must provide, its timing and quality — and providing that delay extends deadlines and entitles the supplier to charge for waiting time or terminate the project. Even without an express clause, failure to provide necessary cooperation may trigger the statutory consequences of creditor delay, for example by affecting whether the supplier is in delay or the recovery of damages. This does not automatically create a right to charge for waiting time. The agreement specifies the deadlines, costs and termination conditions.
How should acceptance be structured so the project can be closed?
We recommend agreed test scenarios, defect categories (blocking versus other defects), a deadline for objections and deemed acceptance if that deadline passes without action or the system enters production use. For customers, we ensure deemed acceptance does not become a trap — the balance can be tailored to your needs.
How much does an implementation agreement cost?
It depends on the complexity of the project and schedules. We confirm the fee in advance after the initial consultation — and the agreed fee stands.
Legal Q&A
Common questions on this topic
-
Our system implementation is late. May we withdraw only from the part the supplier has not delivered?
Yes; in commercial relations the law expressly provides for it: where the delay concerns only part of the obligation, withdrawal is available only in respect of that part. You may withdraw from the entire implementation contract where the parts already delivered evidently have no economic significance for you without the remainder, or where the failure to perform as a whole amounts to a material breach. Before withdrawing, check whether the supplier is in delay because of your own failure to cooperate, and define the scope of the withdrawal precisely in the notice.
Read the answer -
The new system does not work with our older software. Is the implementation supplier liable for this?
It depends on what the contract defined as the result and on who warned whom. If the supplier could, exercising professional care, have identified that your materials or instructions for the integration were unsuitable and failed to warn you, it is liable for defects caused by their use. If it warned you and you insisted in writing on the original solution, it is not liable for those defects. If the integration depends on cooperation which, under the contract, you were to procure, even through another supplier, the implementation supplier is not in delay in so far as it cannot perform for want of that cooperation.
Read the answer -
The supplier of our new system will be migrating our customer data. Do we need a GDPR contract with it?
Yes, where the supplier handles personal data of customers or employees on your behalf during migration, testing or support. It is then a processor, and the processing must be governed by a contract with the content prescribed by Article 28 GDPR, in writing, including in electronic form. Among other things, the contract must provide that the supplier processes the data only on your documented instructions and that it returns or deletes the data once the services end. The duty to select a supplier offering sufficient guarantees rests with you as controller.
Read the answer
Further reading
eFaktúra from 2027. How businesses should prepare
From 1 January 2027, VAT payers will issue structured electronic invoices for domestic business transactions and generally send them through a certified provider. Businesses that are not registered for VAT will also need to be able to receive them. Alongside accounting arrangements, businesses should prepare their provider contract and internal rules for archiving and approving invoices.
Read more → Agile software development: a contract designed for sprints
Sprints do not fit a conventional contract for work: scope is flexible, software is delivered incrementally and acceptance is ongoing. A framework agreement with orders, budget caps, a definition of done and rules for the backlog and repository handover provides a solution.
Read more →
NIS2 does not end at registration: cybersecurity belongs in supplier contracts
The Cybersecurity Act requires essential service operators to conclude a specific agreement with any supplier whose activity directly relates to the security of their networks and information systems (unless a statutory exception applies), covering security policies, audits and incident reporting. What the agreement needs, what to ask IT suppliers for and what to watch when you are the supplier.
Read more →