Most IT outsourcing problems aren't discovered during onboarding — they're discovered eighteen months in, when something the contract was vague about finally matters. Reading carefully before signing is the cheapest risk management available.
What to look for
Uptime or response commitments without defined measurement
A contract promising "high availability" or "prompt response" without a specific percentage, a defined measurement window, or a stated remedy if it's missed isn't really a commitment — it's a sentiment. Push for specific numbers and specific consequences.
Unclear who owns code, configurations, and documentation
If the contract doesn't explicitly state that work product, custom code, and infrastructure documentation transfer to the client at delivery or contract end, ownership can become a dispute at exactly the worst time — when the relationship is ending.
Infrastructure built on tools only the vendor can operate
If a provider's entire stack depends on proprietary platforms with no standard documentation, switching providers later means rebuilding from scratch rather than handing off. Ask directly what happens to the infrastructure if the relationship ends.
No defined process for what happens when something goes seriously wrong
A contract should specify who gets contacted, how fast, and what authority they have when an issue exceeds normal support — not leave incident response to be figured out in the moment.
Billing structures that don't define what's in scope
Contracts that bill broadly for "additional services as needed" without defining what counts as additional create room for disputes over every invoice. Scope should be specific enough that both parties can agree, without argument, whether something falls inside or outside it.