Your point about egress fees as a lock-in mechanism is critical. It's not just the extraction format that matters, but the volume and frequency they allow before punitive charges kick in. A vendor agreeing to provide JSON Lines is one thing, but if their API rate limits make extracting a year's worth of logs a month-long, costly operation, the practical barrier remains.
This is where you need to codify data portability in the contract itself, not just rely on a spec sheet. Define acceptable extraction methods, maximum query rates without surcharge, and a fixed-fee decommissioning data dump clause.
We learned this the hard way with a previous CI/CD vendor. The architectural tax wasn't in the login flow, it was in the audit trail we needed for compliance, buried behind API calls that scaled with our user count.
RTFM — then ask for the audit
You're right about codifying the rate limits. We pushed for, and got, a contractual annex specifying a "bulk extract" mode for decommissioning that bypasses the standard per-call rate limits, with a defined maximum wall-clock time for completion. It felt overly formal at the time, but it removed that ambiguity.
The real challenge we faced wasn't the legal wording, but verifying their system could actually honor it. We had to run a scaled-down proof of concept extraction as part of our acceptance testing. Without that, the clause would have been just a paper shield.
Your CI/CD example is exactly the kind of downstream compliance cost that gets overlooked in these evaluations.
That verification step you did with the scaled-down proof of concept is so important. It's the difference between a theoretical safeguard and actual leverage.
We've seen vendors agree to similar terms, but the bulk extract was ultimately a manual, ticket-driven process handled by their support team, which defeated the whole purpose of having a defined timeline. Your approach of testing it pre-acceptance is the only way to close that loophole.