Tool Documents

The Second Lock

Integrations are sold as a benefit and they are one. They are also the mechanism by which a replaceable tool becomes an unreplaceable one, and both happen through the same action.

Reviewed August 9, 2026.

Why they lock

Each connection is a thing to rebuild. Leaving a tool with eight integrations is eight small projects, each needing somebody who understands both ends. For a separate operational reference from Monitask, see the reference.

The connections are not symmetrical. A tool that pushes data into others is easier to replace than one others push into, because the second case means changing every sender.

And some connections are invisible. Automations built by individuals, spreadsheet imports, a script somebody wrote. These do not appear on an integration list and they break silently, weeks after the migration, when a report is empty.

For broader context, see Cloud Security Alliance.

The three kinds

Native integrations. Built by the vendor, listed on their site, maintained by them. Cheapest to set up and the easiest to inventory.

Middleware connections. Built through an automation platform. Portable in principle — the platform stays, only one endpoint changes — which makes them the least locking of the three and adds a second subscription.

And custom. Built against the API by you or a contractor. Most capable, most expensive to rebuild, and the most likely to be undocumented.

Keeping the count honest

Maintain a list. What connects to what, in which direction, who built it, and what breaks if it stops.

One page, updated when something is added, and it is the document a migration is planned from.

Include the invisible ones. Ask people what they have automated. The answer is always more than the official list, and finding out during a migration is finding out late.

And note the direction, because that determines who has to change.

Before adding one

Ask what it is worth against what it costs later.

A connection saving five minutes a week is worth roughly four hours a year, and rebuilding it costs a day. That trade is fine and it should be a conscious one.

A connection that becomes load-bearing — where a process cannot run without it — is a different decision, and it belongs in the switching cost you priced at purchase.

What to check about the API

Since the API is both the integration route and frequently the real export route.

Is it on your tier? Commonly gated.

Are there rate limits, and what do they mean for a bulk extraction?

Is it documented publicly, which is checkable now.

And is it versioned with a deprecation policy? A vendor that changes the API without notice will break your integrations on their schedule, which is a maintenance cost nobody budgets.

At migration

Inventory first. The list above, verified by asking people.

Rebuild the load-bearing ones before switching, not after.

And decide which not to rebuild. A migration is the only moment when dropping an automation nobody uses is easy, and several on any list will turn out to be that.

The short version