I lost a deal once to a worse product. Better-funded competitor, uglier UI, fewer features, and they won because they showed up to the demo with the prospect’s actual data already loaded into their system. We had a slicker product and an empty database. The prospect could see themselves in their system and not in mine. That is the whole game, and it took me losing to learn it.
The pretty UI gets you in the room. The painless migration closes the deal. Everyone obsesses over the first and underinvests in the second, which is exactly backwards.
Why switching is so rare
ERP has the lowest switching rate of any software category I know, and it is not because the incumbents are good. It is because the cost of moving is terrifying and the cost is almost entirely about data.
A mid-market company’s data does not live in a clean export. It lives in a QuickBooks file with twelve years of cruft, a spreadsheet one long-tenured employee maintains, a legacy system whose vendor went out of business, and the heads of three people who have been there forever. To switch ERP, all of that has to land in the new system, reconcile to the penny, and keep the business running while it happens. Get it wrong and you cannot tell who owes you money during your busy season.
So they don’t switch. They stay on software they hate because the devil they know cannot lose their receivables. The incumbent’s moat is not quality. It is the migration terror, and the only way to win the customer is to dissolve that terror.
Customers do not buy your features. They buy the disappearance of the fear that moving will break their business. Make that fear go away and the features barely matter.
Why it is brutally hard to make painless
If migration were easy, everyone would do it well and it would not be a moat. It is hard because every legacy system is a haunted house, and the ghosts are all edge cases.
The data is dirty. Customers with two slightly different names that are the same customer. Invoices in three different status conventions because the policy changed in 2019. Amounts that are sometimes tax-inclusive and sometimes not, with no flag telling you which. Dates in four formats. A “notes” field that someone used to store the real payment terms because the system had no field for them.
The mappings are ambiguous. Their “account type” does not map cleanly to yours. Their custom fields encode business logic you have to reverse-engineer. Their idea of a “closed” order and yours differ in ways that change the numbers.
And the reconciliation is unforgiving. It is not enough to import the rows. The totals have to match. If their books say accounts receivable is a certain figure and your import produces a different one, you have not migrated their data — you have corrupted it, and you have done it in the one domain where confident wrong numbers are worse than no numbers.
What painless actually requires
Making migration feel effortless to the customer means absorbing all of that difficulty inside the tool. Here is the shape of what I build.
Read the mess as it is. The importer has to accept the ugly export without demanding the customer clean it first. “Clean your data before importing” is the sentence that kills the deal, because if they could clean it they would not need to switch. The tool meets the data where it lives.
Infer the mapping, then show your work. This is where AI earns its place honestly. A model that can read a messy export, propose how each column maps to the canonical schema, and flag what it is unsure about does in an afternoon what used to be a month of consultant time. But it proposes; it does not silently decide. The customer confirms the mappings, especially the ambiguous ones, because a wrong mapping applied at scale is a disaster.
Reconcile and prove it. The non-negotiable step. After import, the tool computes the figures that must match — AR balance, total invoiced, cash position — and shows them next to the source system’s numbers. If they agree, the customer trusts the migration. If they disagree, the tool says so, loudly, and points at the discrepancy rather than burying it. This is the same principle that governs every report I ship: a confident number you cannot defend is worse than no number.
Migration is not done when rows are imported.
It is done when:
source.AR_balance == imported.AR_balance
source.total_invoiced == imported.total_invoiced
source.open_count == imported.open_count
and every mismatch is surfaced, not hidden.Run dry, then run for real. A dry run imports into a sandbox and reconciles without touching anything live, so the customer sees the result before they commit. Nobody bets their busy season on a migration they have not watched succeed first.
The economics that changed
Migration used to be a project — a statement of work, a team, a timeline measured in months, a price tag that made switching uneconomical for anyone below the enterprise line. That project tax is most of what kept the mid-market stuck on tooling they hated.
What collapsed the tax is not that the data got cleaner. It is that the expensive human labor — reading the mess, inferring the mappings, chasing the reconciliation discrepancies — is now largely automatable, with a human confirming rather than performing. The model handles the tedious 80%. The human handles the judgment calls and signs off on the reconciliation. A migration that was a six-figure, multi-month engagement becomes a guided afternoon for a large class of customers.
I am careful here because migration is exactly the place where a demo lies. It is easy to show a clean import of clean data and call it solved. The real test is whether the tool survives the haunted house — the duplicate customers, the inconsistent statuses, the tax-inclusive ambiguity — and still reconciles to the penny. I build and test against the mess, not the brochure data, because the mess is what every real customer actually has. In Vontra, the import-and-reconcile pipeline is treated as a first-class part of the product, not an onboarding afterthought.
The reframe
When I plan a roadmap, migration is not an onboarding feature sitting in a corner of the product. It is the product, because it is the thing standing between a customer and ever using anything else I built. The best invoicing module in the world is worthless to someone who cannot get their invoices into it.
The competitor who beat me understood something I had to lose a deal to learn: the moment a prospect sees their own real data, reconciled and correct, inside your system, you have already won. Everything after that is them confirming a decision they have emotionally made. The work to get there is unglamorous, edge-case-ridden, reconciliation-obsessed, and it is where the deal is actually decided. Build for the haunted house. That is where the customers are.