Changing IT provider is one of those moments where small procedural mistakes cost real money. Not because the old vendor is malicious — sometimes they are, more often they're simply busy with other work and have no reason to hand your systems over in pristine condition. That's why a handoff has to be a planned project, not an email saying "please send documentation by tomorrow".
This post isn't about how to fire your vendor. It's about what you need in hand before they actually disappear — because after the last day of the contract the phone stops being answered, and passwords you forgot to ask for later cost you a few thousand each.
Why handoffs go wrong
In contracts between SMEs and IT vendors, the handover clause practically doesn't exist, or it consists of a single sentence: "the vendor shall provide documentation". In practice that means when the parting comes, each side interprets "handover" differently.
The old vendor believes they delivered a working system and it's your job to understand it. You believe that since you paid for three years, the whole documentation should be handed over on a plate. The new vendor looks at you and asks whether there's an integration diagram for the bank, because without one, quoting new changes is shooting in the dark.
The result: for three to six months the new vendor "learns the environment", the old one no longer picks up, and you pay twice — the new firm for knowledge reconstruction and, indirectly, the old one, because without that knowledge you have to postpone some changes.
What you actually have to take over
At a 25-person manufacturing company in western Poland, which we took over after the previous IT firm (four-year relationship, roughly 6,000 PLN/month), we did a full inventory before the split. It came out to 47 active credentials, accounts and resources that had to physically change owner or password. Before the audit the client estimated "maybe twenty". That gap is not an exception — it's the rule.
The categories you cannot skip:
- Administrative access — Global Admin in Microsoft 365, owner account in Google Workspace, root on the Linux environment,
sain SQL Server, admin account in Comarch Optima / enova365 / Subiekt, firewall panels, NAS, UPS, network printers. Each of these has to be reclaimed, its password changed, and the owner reassigned to you or your new provider. - Domain and DNS — account at the domain registrar (nazwa.pl, home.pl, OVH), DNS panel access, SPF/DKIM/DMARC configuration, SSL certificates and their private keys. If the domain is registered to the vendor rather than to you, you have a problem — changing the registrant takes time and requires the vendor's consent.
- Source code and repositories — access to the Git repository (GitHub, GitLab, Azure DevOps, Bitbucket) together with commit history, CI/CD pipelines, build artifacts, deployment keys. Code without history is half the code — without it you don't know why things are the way they are.
- API keys, tokens, secrets — integrations with the bank, courier, e-commerce, payments, government systems (KSeF in Poland, VAT platforms, HMRC-equivalents). Kept in a file, in Vault, in application config or — worst — in one developer's head.
- Databases and backups — access to the production database, to the backup server, to cloud storage (Azure, AWS, S3-compatible at OVH or Backblaze). And: backup encryption keys. A backup you can't decrypt is worthless.
- Contracts with sub-suppliers — hosting, monitoring, antivirus, plugin and module licenses, SMS gateway, certificate provider. Check whose name the invoices are on. If they're on the vendor, you have to transfer the contract before they terminate it.
The documentation nobody wrote
At most SMEs, technical documentation either doesn't exist or is completely outdated. That's normal. It becomes a problem the moment you have to hand the system to someone who has never seen it from the inside. That's when you discover the only "documentation" is notes in the Notes app on the laptop of a developer who's moving to a competitor.
The reasonable minimum worth fighting for in a handover clause:
- Architecture diagram — one-page: what talks to what, over which protocol, in which direction. It doesn't have to be beautiful, it has to be true.
- Integration list — bank, courier, e-commerce, KSeF, Comarch, each with a description: what it does, where the keys are, at what cadence it runs, what happens on failure.
- Operational procedures — how to deploy a new version, how to restart, how to restore the database from backup, how to add a new user.
- Change log for the past 12 months — even as a list of commits or emails. Without it, the new vendor has no way to understand what happened and why.
Push item by item. "Technical documentation" as a general requirement will be delivered as a PDF with screenshots of a console.
The handover clause in the contract
If you're negotiating a new contract with an IT vendor or amending an old one, add a few sentences about exit. Without them you're relying on goodwill.
- Transition period — minimum 4 weeks after notice, including at least 2 workshops with the new vendor.
- Scope of handover — itemized, not "documentation". Spell out: access, code, keys, docs, change log, integration list.
- Intellectual property — code written on your commission is yours, without restriction. Without this clause, in Poland, code often remains the contractor's property (Article 74 of the Copyright Act — commissioned works and employee works have different regimes, worth spelling out clearly).
- Contractual penalty for non-cooperation — doesn't need to be large. Even 5,000–10,000 PLN is disciplining.
- Rate for post-contract work — if a month later you need to ask about one thing, the vendor can charge for it — but the rate is known in advance, not negotiated under pressure.
A realistic timeline
At the 25-person manufacturer mentioned earlier, the whole process took 8 weeks. We split it like this:
- Weeks 1–2: inventory. The new vendor lists all systems, accounts, integrations, contracts. The old vendor gets the list and fills in the gaps. The client receives a single table covering everything.
- Weeks 3–4: access handover. Point by point: each account changes owner or password, each one is logged. Nothing is "sorted verbally".
- Weeks 5–6: knowledge transfer. Workshops (twice, 3 hours each) with the old and new vendor together. All questions from the new vendor go into a document and must be answered at the workshop or within 5 business days.
- Week 7: solo trial. The new vendor tries to run routine operations without the old one's help. Gaps appear — we go back to step 3.
- Week 8: formal close. Signed handover protocol listing what was transferred. Without the signature, the final invoice doesn't get paid.
The client saved an estimated 4–5 months of "environment learning" by the new firm — which in IT service costs is 25,000–30,000 PLN not spent on knowledge reconstruction, but on actual changes.
What next
If you're considering changing your IT provider, or you've already decided, start with one thing: list every system, account and integration in the company. Even an incomplete list will show you the scale and let you talk to both sides — old and new — in specifics rather than promises.
If you want an outside view on what you actually have to take over and how to write it into the contract so the handover happens without hostages — we help SMEs run these audits and manage the takeover itself. The first conversation is free and takes half an hour.
An IT vendor who leaves on good terms hands over the keys. One who leaves on bad terms hands over excuses.