Answers
Who can add AI to the software my business already runs, without a migration?
Three kinds of people can: your existing vendor, a specialist integrator, or a small product studio that builds on top of what you have. Which of them is available to you is decided by one property of your system of record — whether its API lets an outside program write records back in, or only read them. So the first move is not a vendor search. It is an email to your current vendor asking for their API documentation and their written position on third-party access. If writes are documented and permitted, a layer can be built, your staff keep the screens they know, and nothing migrates. If they are not, no honest builder can help you, and your real options narrow to waiting for your vendor's own AI features or changing systems.
§The three shapes this decision takes
A business running on an entrenched system of record — a DMS, a practice management suite, an ERP, a PMS — has three ways to get AI into its day, and no fourth.
Replace the system. Rarely worth it, and almost never for AI alone. The expensive part of a migration is not the data export. It is retraining everyone who knows the old screens, the history that arrives in a slightly wrong shape, the connections nobody remembered existed until they broke — the payment processor, the parts catalogue, the file your accountant pulls each quarter — and the months where the whole business works slower. Replace the system when the system is failing you for reasons that have nothing to do with AI. Then AI is a tiebreaker between candidates, not the reason to move.
Wait for the vendor. The cheapest route and often the right one. A vendor has advantages no third party can match: full access to the internal data model, no integration to break, no second invoice, no argument about who owns the record. The costs are that the feature is built for their whole customer base rather than for you, it arrives when their roadmap says, and you have no say in what it does.
Build a layer on top. The system of record stays where it is. The layer reads from it, does the work people find tedious, and writes the result back as a draft a human approves. Nobody learns a new system. The price is integration risk: you now depend on someone else's API staying stable and on your vendor being relaxed about outsiders in their data.
§What makes a system layerable
Layering means a second product sits on top of your system of record and puts its work back into it. Four properties decide whether that is possible, in order of how much they matter. A write API — read access alone produces something that can advise but not act, so a human still retypes everything and you have bought a dashboard. Stable record identity — durable IDs for customers, jobs and line items, so the layer attaches its output to the right record instead of matching on names. Events or webhooks — without them the layer has to poll, which is slower and noisier but workable. A full export — even where the API is thin, a scheduled export gives the layer context and gives you a way out later.
The strongest signal is API documentation published openly, readable without signing anything. A vendor who publishes has already decided that integrations make their product harder to leave. In auto repair that shape is what makes Otto possible: a mechanic speaks a voice note, Otto writes a structured repair order, and it arrives in TekMetric as a draft estimate for the service writer to approve, without the shop's system of record moving. The test generalises to any industry. If an outside developer can create a real record in your system from published documentation alone, the remaining question is what to build.
§What makes a system hostile
Some systems genuinely cannot have anything built on top of them, and it is much better to learn that in a week than six months in. The warning signs are consistent: no write API at all; an API gated behind a partner agreement the vendor grants selectively; API access sold only on a tier that costs more than the work would; per-call pricing that makes ordinary use expensive; contract language restricting third-party access to your own data; an on-premises server with no route in from outside; or a support desk that treats integration questions as a competitive threat.
When none of that can be resolved, what remains is screen automation — software that drives the interface the way a person would, clicking and typing. It works, it is useful in narrow cases, and it breaks whenever the vendor moves a button. Treat it as a stopgap with an expiry date rather than an architecture, and be wary of anyone who proposes it as the permanent plan without saying that out loud.
§When the honest answer is to wait, or to buy something ordinary
If the vendor of your existing system has the capability you want on its release notes, use theirs. A native feature beats a good third-party layer on reliability, because there is no integration between them to fail, and it does not add a bill. Shop management software is a live example — TekMetric, AutoLeap, Shopmonkey and Mitchell 1 all compete on features, and what is built in changes; check what your own account offers today rather than what a comparison table said last year.
It is also worth asking whether this needs software at all. A great deal of what businesses want AI for is one repetitive document — a summary, a report, an intake form — and that is frequently solved by a dictation app, a decent template and a rule about who checks the output. An afternoon and a subscription. Custom work earns its cost only when the result has to land inside your system automatically, at volume, in a shape the next person downstream can rely on.
§What to ask whoever you hire
Ask to see the thing writing into your system, with your data, before signing anything; a demonstration on sample data proves nothing about your vendor's API. Ask what happens when the AI is wrong — the right answer describes an approval step and a way to undo, not an accuracy figure. Ask who fixes the integration when the vendor changes their API, and get that maintenance commitment in writing. Ask whether your vendor permits this in the contract, not in spirit. And ask the quiet one: does the new software keep your existing system as the record of truth, or does it slowly become the record itself? Software that starts holding data which never flows back has migrated you without asking.
Any price quoted before someone has read your vendor's API documentation is a guess. Work here is quoted per engagement — get in touch if you want that assessment done first, since it decides whether the rest is possible.
Last updated 25 July 2026.