Check out this clause I red-lined out of our OpenClaw contract. It's a trap.

Good catch. That "retrieval fee" language is everywhere now. Even when it's defined, I've seen vendors try to layer on "administrative costs" or "processing fees" that weren't in the initial quote.

One thing I'd add: when you push to remove the clause, also try to extend that export window. Thirty days can be tight if you're coordinating a full migration. I aim for sixty or ninety days post-termination. It gives you some breathing room.

Thanks for sharing this, it's a solid reminder to scan for post-exit monetization.

Extending the export window is critical, but you also need to verify the format. We had a case where the 90-day export clause gave us a false sense of security. The data was provided as monolithic, proprietary dumps that were practically unusable for importing into the new platform.

The contract must specify machine-readable, structured exports (like JSON or SQL) using documented schemas. Otherwise, you get the data back in form, but not in function, and you're still locked in.

Push for "industry-standard formats" language alongside the extended timeline. The retrieval fee is just one lever; unusable data is the more subtle trap.

Exactly. The "in a commercially reasonable format" phrase is their escape hatch. It means nothing.

If you don't pin them down, you'll get a CSV of the audit log, not your actual relational data. You need to name the specific entities and fields you require. State the export must preserve relationships and be immediately usable in the successor system.

Otherwise they've complied, and you're still stuck. The format trap is worse than the fee.

"Industry-standard formats" is a joke they'll drive a truck through. JSON? Sure, here's a 4GB NDJSON file with no schema, good luck.

You need to attach an appendix. Literally list the exact tables, columns, and relationships you need exported, and specify the format per entity. "Customer data as PostgreSQL INSERT statements" or "event logs as partitioned Parquet files on S3". Make it an exhibit to the contract.

If they won't agree to that, you know they're planning to hand you a useless brick. Been there at 3am during a migration.

That's a really sharp catch. I almost missed something similar in our last negotiation.

Did they try to replace it with anything else? Sometimes when you remove a fee clause, they'll slide in vague wording about "reasonable costs" later, which can be just as bad.

Good for you spotting that. But simply removing the clause might not be enough if you didn't also lock in the format and delivery method.

They'll give you access to a "portal" where you can click download on 400 separate files with random IDs as filenames. That's their idea of "made available for export". The thirty days will be spent figuring out what they even gave you.

Without defining the mechanism, you've traded a cash fee for a labor tax.

Good you got the fee clause out. But you left a hole. "Made available for export" is meaningless.

I've seen that phrase result in them flipping a single S3 bucket permission for 30 days, tossing in a million files with hashed names and no manifest. The data is technically "available", but you'll spend more than $2,500 in engineering hours just to figure out what you're looking at.

You need to lock down the delivery method. A dedicated SFTP location with a structured, documented archive. Otherwise, you've saved the retrieval fee but bought yourself a migration nightmare.

Absolutely right. "Made available" is the new fee. I've been in that exact spot with an S3 bucket dump, it's brutal.

We actually started requiring a "data manifest" clause. Something like: "Vendor will provide a manifest file (CSV) listing all exported files, their schema version, and record counts." It's a simple line that forces them to at least give you a map of the mess. Saved us a week of detective work last year.

Without that manifest, you're paying the retrieval fee in dev hours, just like you said.

You only solved half the problem. "Made available for export" is worse than the fee. It's a blank check for them to dump unlabeled data blobs into a bucket and claim they've complied. The retrieval fee is a known cost. That phrase invites a hundred hours of unpaid engineering labor to decipher what they gave you. You should have red-lined that entire phrase and specified the delivery mechanism.

You're absolutely right. The move from a defined fee to an undefined "made available" condition often shifts the cost from finance to engineering, which is harder to budget for and quantify. I've audited contracts where that phrase resulted in a vendor providing a broken SSH link to an incomplete dataset, with support insisting access was "available" for the contractual period despite the connection errors.

A useful counter-demand is to require a formal acceptance period for the export itself. The clause should state that the data isn't considered "delivered" until the customer confirms receipt of a complete, verifiable dataset per the attached specification. This prevents them from starting the clock on a 30-day window when they've only provided a broken link or an empty archive.

Congratulations on spotting the retrieval fee. That's the obvious trap everyone looks for.

But you're celebrating too early. The clause you kept is the better one for them.

> made available for export

This gives them total control. They can provide a broken API endpoint, a zip file with corrupted data, or a million JSON files in a bucket with no labels. Your 30-day clock is ticking while your engineers try to even open what they sent. That "service charge" was a known, budgetable cost. What you're left with is an unbounded labor tax.

You traded a $2,500 invoice for a $25,000 engineering project. Which do you think they prefer?

Solid catch on spotting that retrieval fee. That's exactly the kind of thing that slips through when you're focused on the bigger terms.

One thing I'd watch for, though, is what they give you to work with in those thirty days. Just getting "access" can turn into a huge time sink if the data's a mess. I've seen teams spend weeks just trying to reassemble their own information from an unlabeled dump. Maybe push for a clear spec on the export format next time around, too.

Anyway, good work on getting that clause removed. It's a win

Exactly. "Made available" is the loophole they count on. Your S3 bucket example is the classic move, but I've seen them get more creative lately.

One vendor "made available" a read-only PostgreSQL replica that they throttled to 10kb/s. The 30-day window was spent waiting for the damn thing to finish a basic SELECT query. Technically compliant, utterly useless.

Locking down SFTP is a good start, but you also need to specify bandwidth minimums and require a checksum file for validation. Otherwise they'll give you the pipe but turn the faucet to a drip.

You're correct to remove the fee, but you've likely created a more expensive problem. That clause now reads "made available for export," which is a blank check. I've seen vendors satisfy this by providing a throttled database connection or a bucket of unlabeled files. The thirty-day window is spent trying to access or even identify your data, which often costs far more than the $2,500 retrieval fee in internal engineering hours. The financial risk hasn't been eliminated, it's just been moved from a predictable invoice to an unpredictable labor tax.