Deployment
Don't replace your ERP. Build on it.
A company that spent two years migrating doesn't want another migration. Why building on existing systems is the only viable route, and how we do it.
There’s a sentence that kills any AI proposal:
To do this, you’d first have to replace that system.
If somebody at the company spent two years and a large budget rolling out an ERP, that sentence isn’t a technical suggestion. It’s an announcement that their work was wasted.
Why migration-first proposals don’t land
Because somebody owns it. That system was someone’s project. Replacing it is their performance review.
Because the cost isn’t the licence. The real cost is data migration, retraining, parallel running and six months of reduced throughput. Everyone who has lived through one knows this.
Because the risks multiply. An AI deployment is new and uncertain on its own. Tie it to a migration and you get the product of two uncertain projects.
What we do instead
The existing system stays the source of truth. Around it goes a layer that
- reads what it needs (via API, or whatever the system offers),
- does the work that is done by hand today,
- and writes back the result to the same place a person would.
From the user’s point of view, NetSuite stays NetSuite and SAP stays SAP. Some of the fields are just already filled in when they get there.
That’s the strongest argument for adoption. No new interface to learn, no permissions to redesign, no retraining from scratch.
The integration reality
In practice there are four levels of access, in descending order of preference.
1. A documented API. Best case. Versioned, supported, testable.
2. An undocumented but real API. Most modern systems have an internal API their own front end uses. Usable, but check with the vendor that it doesn’t breach your contract.
3. Database-level reads. Often the quickest route for reading. Rarely a good idea for writing: it bypasses the application’s business logic.
4. UI automation. Last resort. It works, but it’s brittle: every interface update can break it. If we’re forced here, we state the maintenance cost explicitly during discovery so it doesn’t surface later.
At most mid-sized companies the picture is mixed: the ERP has an API, the document store doesn’t, and the spreadsheets have nothing at all.
How to keep it from becoming a mess
We hold to two rules.
Business logic doesn’t live in the integration. The adapter only translates: read from here, write to there. What the system does lives separately. So if you do eventually replace the ERP, you rewrite an adapter, not the system.
Every write is logged and reversible. For anything the system wrote, you must be able to tell that it wrote it, when, and on what basis. If something goes wrong you have to be able to pull it back out — without manually reviewing three thousand records.
What to tell your sponsor
If you’re selling this internally, this framing works:
We’re not touching the system you rolled out. We’re adding a layer that does the work people currently do by retyping data from one screen into another. If it doesn’t work out, we switch it off and everything stays as it was.
That last clause is the important one. Reversibility is what sells it.
Related: why most AI pilots fail.
Questions on this topic
What if the system genuinely has no API?
There are still routes: database-level reads, scheduled export/import, or as a last resort supervised UI automation. That last one is brittle, so we flag its risk and maintenance cost explicitly during discovery.
Doesn't this create technical debt around an old system?
The layer we build is deliberately detachable. The business logic lives with us, not in the integration — if you do eventually replace the ERP, you rewrite the adapter, not the system.
What does this look like at your company?
If this problem sounds familiar, let's start with one process. Tell us which department burns the most manual hours — we'll come back with a concrete proposal.