How to Choose an IT Vendor: 15 Questions Before Signing the Contract

Implementing a new ERP or CRM system is not a standard business case. The contract goes through an approval loop, in-house lawyers check it, and yet blind spots remain. Not because anyone did poor work, but because IT implementation projects are a specific discipline. Your in-house lawyer is an expert on employment contracts, leases, or routine agreements. Data migration, protection against vendor lock-in, or an SLA for a mission-critical system are things they have not dealt with before. That is a different world.

From our practice, we see that the biggest problems do not arise because of bad technology, but because of contracts that no one on the team knew how to read as an IT lawyer. In this article, we give you 15 specific questions you should ask yourself before signing anything.

Implementation: the biggest hidden cost of the entire project

An annual license for a million crowns looks like the biggest item in the budget. It is not. Before you even start using the system, you face deployment, customization, data migration, and user training. The upfront costs of implementation commonly exceed the price of the license itself several times over, and this is precisely where contracts most often fail.

A typical implementation contract says roughly the following: the vendor performs the work, the customer has a period for acceptance, then an acceptance protocol is signed. What the contract no longer addresses: what happens if the implementation drags on by six months? Who pays the additional costs that arise because, during the project, you discover that some processes work differently in the new system than before? And is it even a fixed-price project, or just a qualified estimate that may increase?

The risk is not only in the price. It is also in the fact that a poorly done analysis at the beginning reveals problems only halfway through the project, when changing anything is expensive and too late.

That is why we do not check only the contract. We also look at the business model of the entire project. Do you really want implementation on a time-and-materials basis with a non-binding budget? Or does it make more sense to agree on a fixed price with clear deadlines and a defined scope? The answer depends on the specific project, but it is a question you should ask yourself before signing anything.

Integrator vs. manufacturer: who is responsible for what?

A common scenario: you buy a software license directly from the manufacturer. But someone else does the implementation - a local partner or a specialized integrator. Two entities, one project, and when something goes wrong, the game of hot potato begins.

The manufacturer says the problem lies in poor implementation. The integrator points to the product and claims that the system simply works this way. You stand in the middle with a non-functional system and no clear answer as to who will fix it and who will pay for it.

Yet a solution exists, and it must be anchored in the contract before signing. The key questions that need to be clarified:

• Who is your single point of contact for a complaint or an incident?
• How is responsibility divided between the manufacturer and the integrator, and what does that mean in practice?
• What happens when the error lies at the interface, that is, neither purely in the product nor purely in the implementation?
• Do you have it contractually secured that the integrator coordinates the resolution with the manufacturer on your behalf?

The ideal situation is when the integrator takes responsibility for the entire project toward you, including communication with the manufacturer. If not, the contract must precisely define where the responsibility of one ends and the responsibility of the other begins. Without this, you risk waiting months for a resolution while two vendors toss the ball back and forth.

Vendor lock-in: the biggest hidden risk

Vendor lock-in means that you are so dependent on a single vendor that switching to another is practically impossible or extremely expensive. It happens more often than you would expect. And you usually notice it only when it is too late.

How vendor lock-in arises:

• Your data is in a proprietary format that another system cannot read
• The source code is owned by the vendor and you have no access to it
• The contract contains no exit clause or transition conditions
• The integration with other systems is designed so that it does not work without the vendor

How to defend yourself?

The contract must clearly define what happens when you terminate the cooperation. And under what conditions you can even terminate the contract. The key is not technical guarantees such as source code escrow. In practice, the customer almost never receives it, and even if they did, without a development team and detailed knowledge it is useless to them. What you really need:

• A notice period that is realistically long enough for you to find a replacement solution
• Export of data in a usable format that another system can read
• The vendor’s cooperation during the transition, that is, active help, not just handing over files
• A clear price for the transition, ideally agreed in advance, not only at the moment when you are in a hurry and without a negotiating position
• Regularly tendering new offers and not letting yourself be locked into the prices of a single vendor

The Data Act additionally brings new rules: the right to terminate the contract and free export of data. What this means for your business is explained in our article Data Act: how to minimize risks for your SaaS business.

SLA: what it must contain and what is usually missing

A Service Level Agreement (SLA) defines what exactly the vendor guarantees in terms of availability, performance, and response to incidents. The problem? Most SLAs we see in practice are either too general (99.9% uptime without a definition of what that means) or lack penalties for non-compliance.

A good SLA must contain:

• Definition of availability: what exactly does 99.9% mean? How is it calculated? What is included and what is not (scheduled maintenance)?
• Response times: how long until the vendor starts resolving an incident? And how long until it must be resolved?
• Categorization of incidents: not every problem is critical. The SLA must distinguish between a system outage and a cosmetic error.
• Penalties and compensation: credits for an outage, the right to withdraw in the event of repeated breaches, contractual penalties.
• Reporting and measurement: how is availability measured and who does it? Independent monitoring vs. data from the vendor.

Liability for defects and limitation of liability

Every IT contract addresses what happens when the software does not work as it should. The key is to clearly define what constitutes a defect, what your claims are (repair, discount, withdrawal), and how they are limited. Most vendors propose limiting liability to the amount of the annual fee. This may be reasonable, but you must know what it means in practice: if a system outage causes you damage of 10 million and the annual fee is 500 thousand, you can claim a maximum of half a million.

What to watch out for: some contracts contain clauses that exclude liability for indirect damage (lost profit, data loss, reputational damage). This is usually a risk you will have to accept, but you should know what such a clause means for your specific case.

15 questions before signing a contract with an IT vendor

Pull out this checklist before every signing. If you do not know the answer to any of these questions, it is a signal that the contract needs further work.

Implementation

1. Is the implementation price fixed, or is it an hourly rate with a non-binding budget?
2. What happens if the implementation drags on? Who bears the additional costs?
3. How is the scope of work defined and how are changes during the project handled?
4. Was a thorough analysis of processes and requirements carried out before signing?
5. How does acceptance proceed and what exactly must it meet for the work to be accepted?

The vendor-integrator relationship

1. Who is your single point of contact for a complaint or an incident?
2. How is responsibility contractually divided between the manufacturer and the integrator?
3. What happens when the problem lies at the interface of the product and the implementation?
4. Does the integrator have a contractual obligation to coordinate the resolution with the manufacturer on your behalf?
5. What is the limitation of liability of each vendor and what does it cover?

Exit

1. What is the notice period and is it realistically long enough to find a replacement solution?
2. In what format will you get your data back and who bears the export costs?
3. Is the vendor’s cooperation during the transition to another system contractually anchored?
4. Are the conditions and price of the transition defined in advance, or only at the moment when you are under pressure?
5. How does the vendor process personal data and where is the data physically stored?

💡 Tip: You can download this checklist as a PDF and use it before every negotiation with a vendor. Checklist of 15 questions for free.

When it pays off to have the contract reviewed

Not every IT contract needs a legal review. If you are buying a standard tool for a few thousand a month, it is enough to read the terms and conditions. But if it concerns a system essential to your business (ERP, CRM, cloud infrastructure, custom development), a contract for tens to hundreds of thousands a month deserves a review. The cost of a legal check is a fraction of what a poorly set-up contract can cost you.

IT law is our strongest discipline. Our clients include large software companies, telecommunications companies, and small developers. We understand technology and your language, and you will understand our contracts.

Do you need to have a contract with an IT vendor reviewed?

If you are facing the signing of a contract for implementation, a license, or custom development, we will be glad to go through it before something catches you off guard. Get in touch.