What leaves with you when you cancel Salesforce DevOps tools

The conclusion first, held more loosely than the method would allow: when an AI drafts your Salesforce metadata changes, the exit cost of Salesforce DevOps tools depends on where each change record lives on the day you cancel, a factor the subscription price does not show. Records that land as pull requests in a repository you own leave with you by default. Records that live in a vendor workspace, pipeline or state file leave with you only if someone checked in advance that they export in a readable form.

The question, stated narrowly

Switching cost of Salesforce DevOps tools can be framed as migration effort. The smaller question here: on the last day of a contract, which artefacts of past changes can the team still open, and which need the vendor to be present? An artefact is any record an engineer or auditor would later ask for: the diff, the approval, the test result, the deploy record. The window is the full contract term. The exclusion: data backup, a separate category with its own exit story.

Where the record lives in three Salesforce DevOps tools

Public pages read on 1 Oct 2026; stated facts only.

• Salto: according to the vendor's page, read 1 Oct 2026, "a Workspace is a folder containing Salto configuration files, including the State and NaCl files", and that workspace is described on the Salto technology page as usually connected to a Git repository. Verify "usually" in your own setup.
• Salto also says, according to the vendor's page, read 1 Oct 2026, that agents "don't touch the business apps themselves, but only the Salto workspace", so the workspace is where AI changes land first.
• Hutte: according to the vendor's page, read 1 Oct 2026, Hutte sits between the Salesforce org and the Git host and "mainly" stores authentication tokens. The Hutte MCP documentation notes that a personal access token "carries the full access of the user who created it".
• Gearset: according to the vendor's page, read 1 Oct 2026, its agent Cam submits validated changes to the customer's governed pipeline, "keeping a full audit trail for compliance". The quoted line does not say where that trail is stored.

None of this is a weakness claim. It is a list of places to look before signing; each of these Salesforce DevOps tools may have a clean export the public page simply does not describe.

A worked inventory, constructed

The numbers below are constructed for illustration, not measured. Take a team of three admins running an AI drafting assistant for 18 months, averaging 12 metadata changes a month. That is 12 x 18 = 216 changes. If each change produces four artefacts (diff, approval, sandbox test result, deploy record), the inventory is 216 x 4 = 864 artefacts.

Classify by location under two setups. In setup A, every change lands as a pull request in the team's own GitHub repository, so diff and approval live there: 216 x 2 = 432 artefacts sit in the customer's repo. Test results and deploy records depend on where those logs are written; assume they live with the tool, so 432 remain to check. In setup B, the change, its approval and its logs all live inside a vendor workspace or pipeline: all 864 need an export path verified before the last day.

Re-check: 432 + 432 = 864, and 432 / 864 = 50%. Under setup A, half the inventory survives cancellation with no export step.

The same inventory under a stricter definition

Count only two artefacts, the diff and the approval. Under that definition setup A holds 432 of 432 in the customer's repo, which is 100%, while setup B still holds 0 of 432 without an export. The gap widens as the definition narrows, so the result is driven by where the diff and approval are recorded, not by change volume.

This is where FlowSprite AI fits the setup A pattern for the diff; where its approval and audit records live after cancellation is worth checking, as for any other tool. The team's own AI drafts the metadata change; it lands as a GitHub pull request in the customer's private repository, each change is sandbox-tested first, and a human approves before anything deploys. Production is never auto-touched, and every tool call the customer's AI executes is audited. Public, flat pricing: EUR 99 a month for Professional (10 users, 6 Salesforce connections) and EUR 199 a month for Enterprise, which adds approval workflows with separation of duties and audit log export as CSV or JSON. Its trial runs 14 days, no card, while the Gearset pricing page and Hutte's pricing page, both read 1 Oct 2026, offer 30 days. According to the vendor's page, read 1 Oct 2026, Salto covers Salesforce alongside NetSuite, Zendesk, Jira and Okta, which matters if one team governs several business applications. Hutte's pricing page, read 1 Oct 2026, lists scratch org pooling; teams relying on pooled scratch orgs should check that need against every tool here.

What the inventory supports, and what it does not

It supports a narrow claim: among Salesforce DevOps tools, a pull request in a repository you own makes the diff and the approval portable without a vendor's cooperation. It does not support a claim that any named vendor traps your data. According to Hutte's pricing page, read 1 Oct 2026, after a trial ends "none of your projects or data will be lost". Nor does it measure migration or retraining effort.

The limit, and the next study

The instrumentation here is public pages, read on one day. Pages cannot show export formats, retention after cancellation, or whether a workspace's State file is readable without the vendor's software. Those unobserved variables could reverse the result for any of these Salesforce DevOps tools.

The next study this enables is simple to run: pick five past changes, then try to reconstruct each one's diff and approval using only systems your company would still pay for after cancelling its Salesforce DevOps tools. Count successes over five. Record the date, and repeat the count after any contract renewal.