Five Free Tools We Use to Check if a Vendor Will Let Our Data Go
Before we adopt anything new at 137Foundry, we run a quick portability check using tools that are free or already sitting in most stacks. Here's the actual toolkit.
Photo by Anthony Sebbo on Unsplash
We hit the vendor's own export API directly with Postman rather than trusting the UI export button. Raw API responses tend to preserve relational structure that a CSV export flattens away, so this is usually the fastest way to see what a "full export" actually contains.
Once we've got a JSON export, jq lets us quickly check whether relationships and metadata survived the trip, or whether we're just looking at surface-level fields dressed up as a complete export.
For vendors that offer a database-style export, we load it into DB Browser for SQLite and manually try to reconstruct one real record's full history. If that's painful with the vendor's full support access available, it'll be brutal during an actual forced migration.
4. OpenAPI / Swagger validators
If a vendor claims an "open API," we run their documentation through the OpenAPI spec tooling to confirm it's actually a documented, standard contract rather than a marketing claim. A real OpenAPI spec means another engineer, ours or the next vendor's, can build against it without reverse-engineering behavior from trial and error.
The least technical tool on this list does the most work: a shared internal doc where every integration built against a vendor gets logged the day it's built. Vendor, trigger, what breaks if it goes away. Nothing fancy, but it turns "we probably have a few things connected to this" into an actual number when it's time to evaluate exit risk.
We keep ours as a plain table, updated whenever anyone connects something new to a vendor, and it's saved us more than once from underestimating how tangled a particular integration had actually become before we noticed.
How we actually run the check
In practice, this isn't a formal five-step ceremony every time. For a low-stakes tool, we might just eyeball the export with Postman and call it done. For anything a client's business is going to depend on long-term, we run all five, write the findings into a short internal note, and only then move to a pricing conversation. Sequencing matters here, since it's much harder to be objective about export quality after you've already fallen in love with the feature set during a sales demo.
Why we're sharing the actual toolkit instead of just the idea
Plenty of posts will tell you "check your vendor's data portability" without saying how. We'd rather hand over the specific five tools we reach for, because the idea alone doesn't save anyone the afternoon it takes to actually run the check. If you've got a sixth tool you use for this that we're missing, we'd genuinely like to hear about it.
A worked example, without naming names
We ran this exact toolkit against a marketing automation platform we were evaluating a while back. Postman against the export API showed contact records came through fine, but campaign performance history was missing entirely, a gap the sales team hadn't mentioned and possibly didn't even know about. jq confirmed the JSON structure was genuinely flat, no nested campaign data at all. That single finding changed our evaluation more than the entire feature comparison had, because campaign history was exactly the data our client cared most about preserving long-term.
We didn't walk away from that vendor. The feature set was strong enough to justify the tradeoff for that particular use case. But we walked in with eyes open instead of discovering the gap eighteen months later during an actual migration, which is really the entire point of running this kind of check before signing anything.
One habit worth stealing even if you skip everything else
If you only take one thing from this list, take the plain shared doc. Every other tool on here is situational, useful when you're actively evaluating a specific vendor. The shared doc runs continuously in the background, and it's the one that actually prevents the slow-motion surprise of realizing, years later, how many things quietly depend on a single vendor nobody's been tracking.
A note on timing these checks correctly
The order you run these tools in actually matters. Pull the export with Postman first, before you've emotionally committed to a vendor during a sales cycle, because it's much harder to be objective about a mediocre export once you've already fallen for the feature set. We've caught ourselves nearly skipping this step on tools we were genuinely excited about, which is exactly the situation where a structured check matters most, since enthusiasm is precisely what makes people skip due diligence.
What we do when a vendor fails the check
Failing the portability check doesn't automatically mean walking away. It means the decision gets made with real information instead of an assumption. Sometimes we proceed anyway because the feature fit is strong enough to justify the risk, and we document that tradeoff explicitly so it's a conscious choice rather than something we simply didn't think to check. Other times the gap is severe enough, combined with how deeply the client's business would eventually depend on the tool, that we recommend a different vendor entirely, even one with a slightly weaker feature set, because the long-term portability story matters more than a handful of extra features that look impressive in a demo.
Tools we've considered adding to the list
We've experimented with a couple of dedicated data portability auditing tools beyond this core five, but honestly, the simple combination above covers the vast majority of what actually matters for most SaaS evaluations. Specialized tooling starts to earn its keep once you're managing dozens of vendor relationships simultaneously, which is a different scale problem than most teams reading this are dealing with day to day.
How long this actually takes in practice
People sometimes assume a portability check like this adds days to an evaluation timeline. In our experience it's closer to an hour, most of it spent waiting on the vendor's export API to finish generating a sample rather than anything we're actively doing. The Postman pull and jq inspection together usually take fifteen minutes once you've done it a few times and know what you're looking for. The DB Browser reconstruction exercise is the slowest part, since manually verifying a record's full history takes actual attention, but even that rarely runs past half an hour for a single representative record.
What we'd say to a team that's never done this before
Start with just Postman and jq on the next vendor you're seriously evaluating, even if you skip the rest of the list initially. Those two tools alone will tell you more about a vendor's real data portability than reading their entire terms of service page, and they take less time than most sales demos do. Once that becomes routine, adding the reconstruction exercise and the shared tracking doc is a natural next step rather than a big lift.
A final thought on why we keep this list updated
Tooling changes, and we update this list whenever something better comes along or a tool we relied on stops being maintained well. If you're reading this months after we originally wrote it, it's worth checking whether newer, more purpose-built options have emerged for this exact use case, since data portability auditing is a small but genuinely useful niche that's grown a bit more attention in recent years as more teams get burned by lock-in they didn't see coming.
We use all five together as a lightweight version of the four-dimension framework we lay out in our guide to evaluating vendor lock-in risk before committing to a SaaS platform. None of it requires a procurement department, just fifteen minutes and the right free tools.
More on how we think about vendor risk generally over at 137foundry.com.