Every month we talk to a company in the same position: a working ERP or CRM, an internal app the whole business runs on, and a mandate from somewhere upstairs to "add AI." The first proposal on the table is almost always a rebuild. The system is old, it was never designed for AI, so let's do it properly this time. We have scoped enough of these projects to say it plainly: the rewrite instinct is usually wrong, and it is wrong in an expensive way.
This is the playbook we actually use for AI integration on existing software. Four retrofit patterns, ordered roughly by blast radius. How to de-risk whichever one you pick. And the short, honest list of situations where a rewrite really is the answer.
Your boring system is the asset, not the obstacle
A ten-year-old ERP that everyone complains about has three things a greenfield rebuild throws away on day one:
- Data with history. Years of orders, invoices, tickets, and customer records in a schema your team understands. Every useful AI feature we have shipped runs on data like this. A new system starts from zero.
- Workflows that survived contact with reality. The approval chain in your CRM is ugly because the business is ugly. A rewrite rediscovers those edge cases one production incident at a time.
- Trained users. People who know where everything lives and trust what the screen tells them. Adoption is the hardest part of any AI project, and you have already paid for it.
Rewrites also have a habit of eating the AI budget. The typical mid-market replatform we get asked to rescue is twelve to twenty-four months in, and the AI features that justified the project are still on the backlog because the team is busy rebuilding what already worked.
Models are commodities you can swap out in an afternoon. Ten years of your own transactions, tickets, and documents are not. The boring system holds the part that is hard to replace.
Pattern 1: the sidecar service
Our default pattern. Build the AI capability as a separate small service (ours are usually FastAPI plus a job queue) that talks to the existing application through its API, its webhooks, or a read replica of its database. The core system does not know the sidecar exists.
Things we have shipped this way: lead scoring that reads CRM activity and writes a score back through the API, invoice-anomaly checks that flag purchase invoices before the payment run, a summarizer that drafts case notes from call transcripts. Why it works:
- Blast radius control. If the sidecar falls over, the ERP keeps invoicing. You can be aggressive with prompts and model swaps because failure means a missing suggestion, not a missed shipment.
- Independent release cadence. The core system stays on its careful quarterly cycle while the AI service ships weekly.
- A clean exit. If the feature does not earn its keep, you switch it off and the core is untouched.
One rule we do not bend: the sidecar writes back through the same API and permission model as a human user would. The moment it gets direct write access to production tables, you have created an integration nobody can reason about and no upgrade can survive.
Pattern 2: the workflow automation layer
Sometimes the win is not inside one system but between systems. Order emails someone re-types into the ERP. Support tickets manually triaged into the CRM. Spreadsheets exported from one tool and imported into another every Monday. That glue work is where an automation layer with AI steps pays off fastest.
We build these on self-hosted n8n: a webhook in, one or two LLM nodes in the middle, API calls out. A typical flow: a supplier email arrives, an extraction step pulls line items and quantities into structured JSON, a validation step checks them against the item master, and a draft purchase order lands in the ERP for a human to review and submit. We wrote separately about running n8n in production; the short version is that self-hosting keeps your business data off third-party automation clouds and removes per-task pricing anxiety.
This pattern suits teams that want automation they can see. Every run is logged, every step is inspectable, and a non-developer can read the flow. It is also the cheapest pattern to pilot: most first workflows we build land in the one-to-three week range.
Pattern 3: the in-platform extension
If your platform is extensible, put the AI output where people already work. In ERPNext that means custom fields and server scripts packaged in a custom app: an AI risk note on the Sales Order, populated asynchronously after save, visible in the same form the sales team already opens forty times a day. Most serious CRM platforms offer an equivalent through custom fields plus hooks or plugins.
This is the adoption pattern. An AI insight in a separate dashboard gets visited for two weeks and then dies. The same insight sitting inside the document a user has to open anyway gets read every single time. In our ERP work, this is where retrofit projects usually end up once a sidecar has proven the model output is worth trusting.
Two cautions. Keep the model call asynchronous so a slow or failing LLM never blocks saving a document. And keep every customization in version control as a proper app or plugin rather than click-configured in the production UI, for the same reasons we never break that rule on ERP implementations generally.
Pattern 4: RAG over what you already have
The fourth pattern does not touch your workflows at all. Retrieval-augmented generation takes the documents, tickets, wiki pages, and database records you already have, indexes them, and puts an assistant on top that answers questions from your data, with citations back to the source. No migration, no schema changes, read-only access.
The questions it answers are the ones your senior people are tired of: what did we quote this customer last year, which contract clause covers late delivery, how did we fix this error the last three times it showed up in the helpdesk. The knowledge exists; it is just spread across four systems nobody wants to search.
Because it is read-only, RAG is the lowest-risk entry point of the four. Plan for its two real failure modes. Access control: the assistant must respect the same permissions as the person asking, or you have built a very polite data-leak machine. And garbage sources: indexing an outdated policy wiki produces confidently outdated answers. Curate the corpus before you index it, not after the first embarrassing answer.
De-risking: shadow mode, kill switches, one measured workflow
Whichever pattern you pick, the rollout discipline matters more than the model choice.
- Shadow mode first. For the first few weeks the AI suggests and a human decides. Log every suggestion and what the human actually did. On low-stakes workflows we want agreement above roughly 90% before anything acts on its own; for anything touching money, a human stays in the loop indefinitely.
- An explicit kill switch. Every AI feature ships behind a flag that turns it off without a deploy. If disabling the AI requires touching the core system, the integration is designed wrong.
- Measure one workflow, before and after. Pick the metric before you build: minutes per order entered, first-response time on tickets, error rate on invoice coding. Baseline it for two weeks, then compare. This number decides whether the pilot expands, and it is remarkable how few AI projects have one.
When a rewrite is the honest answer
We sell integration work, so read this section as us arguing against our own invoice. Sometimes the retrofit is not viable:
- No surface to integrate with. A compiled desktop app with no API, no webhooks, and an encrypted or vendor-locked database gives a sidecar nothing to attach to. Screen-scraping and RPA are duct tape, not architecture.
- An end-of-life platform. If the OS, runtime, or framework is out of support, every new integration deepens your investment in something with a security countdown attached.
- License traps. Some vendors charge per API call, cap integrations by contract tier, or prohibit third-party access outright. Model the license cost of the integration before writing code; occasionally it exceeds the cost of replacing the system.
- The core already fails at its day job. If the data is wrong and the workflows are ignored, AI produces wrong answers faster. Fix the system of record first.
Even then, a rewrite should usually mean a phased replacement with integration seams designed in from day one, not a big-bang cutover. That is a different project with a different playbook.
Where to start
- Pick one painful workflow, not an AI strategy. The best candidates are high-volume, low-stakes, and currently manual: document intake, ticket triage, data entry between systems.
- Choose the lightest pattern that fits. Knowledge questions: RAG. Glue between systems: the automation layer. A feature inside one product: sidecar first, in-platform extension once the output is trusted.
- Run a four-to-six week pilot in shadow mode, with the baseline metric captured before the first model call is made.
- Decide on the number. If the measured workflow did not improve, kill the pilot cheaply. Being able to walk away for the cost of six weeks is the entire point of the retrofit approach.
The projects that go well start embarrassingly small and grow on evidence. The ones that go badly start with a slide deck about replatforming. Keep the boring system; give it a brain one workflow at a time.