##  [Three questions to ask a software vendor before you need to use them](/insights/three-questions-ask-software-vendor-you-need-use-them) 

#  Three questions to ask a software vendor before you need to use them 

 

 

 

 ![The Pipedrive logo](/sites/default/files/styles/large/public/2026-07/Pipedrive_Monogram_Green.png.avif?itok=ngMd8tgU)

 

 

 

 

 

 

Nobody evaluates software by asking how it ends. Demos are about the honeymoon. But we spent this spring moving a publisher off a CRM they'd outgrown, and everything difficult about that project was decided years ago, on the day they signed up with the original CRM vendor.

Here are the three questions that would have changed it.

## 1. "Show me the leaver's export"

When our client decided to move, we discovered the old system had no standard way to take your data with you. A complete export was a paid extra, on the vendor's timeline. We ended up extracting everything ourselves through their APIs, table by table.

So ask the vendor directly: if we leave in five years, how do we get everything out, what format does it arrive in, and what does it cost? Watch how they answer. A confident vendor has a clean answer because they keep customers with quality, not with exit friction.

This is, incidentally, the quiet argument for open platforms and to a certain extent open source. Openness shows up on the way out as well as on the way in.

## 2. "What does 'last updated' actually mean?"

During the migration we synced changes from the old system incrementally, trusting its "last modified" dates. Then ten recently edited records silently failed to come across, because the old system didn't update its modification dates in certain situations.

This sounds like a technical detail. It isn't. Some of the biggest platforms in the world have the same defect, in both directions: changes that don't update the date, and dates that update with no change. If you ever need to sync, migrate, or audit your data, the reliability of that one field decides whether the job is routine or forensic. Whatever system you are integrating with as a business a very easy thing to do is to seek guarantees on these dates and updates being concrete. Yes you should be focussed on features but adding in some technical questions here and there will push you deeper into their sales stack and technical support to help you look under the covers without having to have the knowledge on real technical issues.

## 3. "Can my own team build things in it?"

The system our client left was closed. No marketplace, no self-service automation, everything through the vendor. The system they moved to has a marketplace and lets their own staff build automations, test a workflow by emailing themselves, and connect the tools they already use.

Within weeks of the cutover, their team was building things nobody had scoped. They had hooked up Claude, Zapier etc. That's the difference between a system you operate and a system you own. It also costs them less per month than the one it replaced.

## How we made the actual move boring

One design decision made this migration safe: every rehearsal run wiped the new system and rebuilt it from the old one, with automated checks comparing record counts, quantities, and prices each time. By cutover weekend we had run the whole thing dozens of times. The client's red line, being able to see exactly what was booked versus still to book, was verified line by line against the old system before we switched. The system in this case is the wonderful Pipedrive which we found better suited to publishing than the specific publishing CRMs! Bonkers.

Migrations go wrong when they're a one-shot event. They go fine when they're a rehearsed, repeatable process with reconciliation built in.

If you're stuck on a platform that's hard to leave, the second-best time to plan the exit is now. The best was at the demo, but nobody asks these questions at the demo. Talk to us before you give notice to the vendor, not after.



 

 

 

[2 min read](/taxonomy/term/6)