Skip to content
Timesheet Systems

All notes  /  07 · Commercial

Where the Lock-In Actually Is

Not the data, which is exportable. The cost of leaving lives in configuration, integrations and habit, and it compounds quietly.

Analysis

Vendor lock-in in this category is rarely about data being trapped. It is about the cost of reproducing everything built around the data.

Where it accumulates

Rule configuration. Two years of accumulated exceptions, each individually reasonable, none written down outside the product.

Integrations, built against this vendor's API shapes.

Reports, built in the product's own reporting tool and not reproducible elsewhere.

Habit. Several hundred people who know how to use this and would need retraining.

Undocumented knowledge: what the administrator knows about why a setting is as it is.

The data is the easy part. These five are the expensive part and none appears in a contract.

What reduces it, cheaply

Document the rules outside the product. A plain list of your pay rules, maintained as the authority, with the product as an implementation of it. This is the single most effective measure and costs an afternoon a year.

Keep integrations on your side of the boundary, with a thin adapter to the vendor's API rather than logic built into their platform.

Export reporting data rather than living inside the product's report builder, where the analysis then belongs to them.

Record configuration changes with reasons, so the knowledge survives the administrator.

Test the export annually, so you know what you would actually have.

The trap of platform features

Products in this category increasingly offer scheduling, absence, expenses, performance modules.

Each adopted module deepens the dependency and is priced accordingly at renewal.

Adopt them when they are genuinely better than the alternative, not because they are adjacent and convenient.

Ask at each adoption: what would it take to replace this alone? If the answer is that it cannot be separated, that is the lock-in being purchased.

Reading it in a renewal

A large increase at renewal is a measurement of your switching cost, made by someone who has estimated it.

Reduce the estimate before the conversation: having a tested export, documented rules and portable integrations changes the position materially.

Get a benchmark quote, even if you intend to stay. It costs a fortnight and it is the only leverage that exists.

The honest position

Some lock-in is worth accepting. A product that fits well, with an owner who knows it, is worth more than portability for its own sake.

What is not worth accepting is unmeasured lock-in — not knowing what leaving would cost, which means not knowing whether the renewal price is reasonable.

Measure it once a year. It is an afternoon and it turns a renewal from an announcement into a negotiation.

Document the rules outside the product

The single most effective measure, and it costs an afternoon a year.

A plain list of your pay rules, maintained as the authority.

The product is an implementation of that list, not the place the list lives.

Updated when a rule changes, with the reason.

Which makes a migration a configuration exercise rather than an archaeology project, and changes what a renewal negotiation looks like.

It is also what an auditor asks for and what a new administrator needs.

Measure it once a year

An afternoon that changes what a renewal conversation is.

What would leaving actually cost: rule reconfiguration, integration rebuild, report recreation, retraining, the export gaps.

In days, then in money.

Compare against the renewal increase.

A large increase at renewal is a measurement of your switching cost, made by someone who has estimated it.

Having your own estimate, a tested export and documented rules changes the position materially — and it is the only leverage that exists.

Small connectors create dependencies

A commercial tool can become embedded through customer and billing flows. This example page is a reminder to inventory every dependency before renewal.