The problem nobody wants to say out loud
Your ERP was built in 2008. It runs your entire business — inventory, procurement, finance, production. It is slow, hard to change, and your developers hate it. But it works. And replacing it will cost millions, take two years, and there is a non-trivial chance it breaks everything.
So you do what most businesses do. You leave it. And meanwhile, you bolt on a CRM here, an eCommerce platform there, a reporting tool in a spreadsheet, a separate system for HR. Each one lives in its own silo. Data does not move between them automatically. Your team re-enters the same information three times a day. Reporting takes a week because someone has to pull exports and paste them together.
This is not a technology failure. It is an integration failure. And it is entirely fixable — without touching your core ERP.
That is what API-first modernisation is. Not replacing the system. Connecting it.
What API-first modernisation actually means
The term gets used loosely, so let us be precise.
API-first modernisation is the approach of wrapping an existing legacy system — one that was never designed to integrate with modern platforms — in an API layer that exposes its data and functions to the outside world. Instead of replacing the system, you give it a modern interface.
The legacy ERP continues to run exactly as it always has. Your team uses it the same way. The data still lives there. The business logic still executes there.
But now, through the API layer, other systems can read from it, write to it, and respond to events it generates — in real time, automatically, without anyone copying a spreadsheet.
Why this is the right approach for most South African businesses
South African businesses face a specific version of this problem that is different from what a UK or US counterpart experiences.
The ERP replacement option — ripping out a 15-year-old system and replacing it with SAP, Microsoft Dynamics, or Odoo — requires several things: budget (often R2 million to R10 million+ depending on scale), internal technical capacity to manage the project, a period of operational disruption during migration, and staff retraining. In a context where load shedding is already creating operational pressure, ICT skills are scarce, and executive appetite for large capital IT projects is low, this option is often not viable.
API-first modernisation is a phased, lower-risk alternative. The investment is in the integration layer, not in replacing the core system. The disruption is contained. The business keeps running. And the results — automated data flows, connected systems, real-time reporting — are often achieved in weeks rather than years.
The technical reality: what you are actually dealing with
Before choosing an approach, you need to understand what kind of legacy ERP you are working with. Not all legacy systems are the same.
1. Type 1
The ERP with an existing but underdocumented API. Many ERPs built in the 2000s and early 2010s have some form of API capability — often SOAP-based web services, database-level access, or vendor-specific integration modules. These are frequently unused or unknown to the current IT team. A proper legacy system assessment often reveals that the integration capability already exists and just needs to be mapped and exposed.
2. Type 2
The ERP with database-level access but no API. The system has no native API, but the underlying database (SQL Server, Oracle, MySQL) can be queried directly. In this case, you can build a custom API layer that reads from and writes to the database directly. This requires care — you need to understand the data model and avoid bypassing business logic the application enforces — but it is entirely achievable.
3. Type 3
The ERP with no database access and no API. Older bespoke systems sometimes only expose data through the UI or flat file exports (CSV, XML). This is the hardest category. Options include UI automation (RPA), scheduled file-based integrations, or screen-scraping middleware. These are not elegant, but they work and they buy time for a more structured modernisation later.
Knowing which type you are dealing with determines the entire integration architecture. This is why a legacy system assessment must come before any integration work begins.
The four-layer API-first architecture
A robust API-first modernisation follows a layered architecture. Each layer serves a specific function.
Layer 1: The data extraction layer. This is how data gets out of the legacy ERP. Depending on the system type (above), this is either a native API call, a direct database query, a scheduled file export, or an RPA-triggered action. The goal of this layer is simple: get the data out reliably and consistently.
Layer 2: The transformation layer. Legacy ERP data is often messy — inconsistent field names, legacy codes, duplicate records, NULL values in fields that should not be NULL. The transformation layer cleans, maps, and structures the data so it is usable by modern systems. This is where most of the hidden complexity sits. Do not underestimate it.
Layer 3: The API gateway. This is the REST API (or GraphQL API, depending on requirements) that exposes the cleaned, transformed data to consuming systems. It handles authentication, rate limiting, versioning, and error handling. Modern tools like Azure API Management, AWS API Gateway, or Kong make this layer faster to build and easier to manage than building it from scratch.
Layer 4: The consuming systems. These are the modern platforms — CRM, eCommerce, BI dashboards, HR systems, customer portals — that now receive real-time data from the legacy ERP without anyone manually moving it.
A practical example: ERP to eCommerce integration
A South African retail business runs its inventory and pricing on a legacy ERP built in 2007. They have a WooCommerce store built in 2022. Every time a product price changes or stock runs out, someone has to log into the ERP, find the change, and manually update the WooCommerce catalogue. When this gets missed — and it does — customers order out-of-stock items or pay incorrect prices.
The API-first solution:
Build a read API on top of the ERP's SQL Server database that exposes current stock levels and pricing for each SKU.
Build a transformation layer that maps the ERP's internal product codes to WooCommerce product IDs.
Set up a webhook trigger — every 15 minutes, or on-demand when a stock change event fires — that calls the ERP API, pulls updated data, and pushes it to WooCommerce via the WooCommerce REST API.
Set up error monitoring and alerting so the team knows immediately if the sync fails.
The result: stock levels and prices stay synchronised automatically. No manual intervention. The ERP was not touched. The WooCommerce site was not rebuilt. The integration layer was built and deployed in three weeks.
This is API-first modernisation in practice.
The middleware question: build vs buy
Once you have decided on an API-first approach, you face a second decision: do you build the integration layer yourself, or use a middleware platform?
Build it yourself (custom REST API + transformation scripts + scheduled jobs) gives you full control and no ongoing vendor licence cost. It is the right choice when the integration is complex, business-logic-heavy, or needs to be deeply embedded in your infrastructure. The tradeoff is build time and maintenance overhead.
Use a middleware platform — MuleSoft, Azure Logic Apps, Boomi, or n8n for simpler use cases — gives you pre-built connectors, visual workflow editors, and faster time to first integration. Many ERP vendors have pre-built connectors available. The tradeoff is licence cost and vendor dependency.
The honest answer for most South African businesses: for straightforward point-to-point integrations (ERP to CRM, ERP to eCommerce), a lightweight middleware tool or a custom-built integration is the right choice. MuleSoft and Boomi are priced for enterprise scale — the licence cost is not justified unless you are managing 20+ integrations. For smaller integration estates, Azure Logic Apps or a well-built custom API layer is more practical.
The five mistakes that kill API-first projects
Starting without a data map. Before writing a single line of integration code, you need a complete map of every field in the source system, what it means, what format it uses, and where it needs to go in the target system. Skipping this step produces integrations that break silently — data flowing through, but wrong.
Bypassing the ERP's business logic. When you write directly to a legacy ERP database, you bypass the validation and calculation logic the application applies. This can corrupt data in ways that are hard to reverse. Always understand what the application does when a record is created or changed — and replicate that logic in your transformation layer.
Ignoring error handling. Integrations fail. The ERP goes down for maintenance. The network drops. A field format changes after an ERP update. Without proper error handling, monitoring, and alerting, you will have silent failures — data that stopped flowing two weeks ago and nobody noticed until someone found a customer order for a product that has been out of stock for a month.
Building for today's volume only. Design your API layer for 10x the current transaction volume from the start. An integration that works at 500 transactions a day will not necessarily work at 5,000. Build in pagination, rate limiting, and async processing from the beginning — retrofitting these later is expensive.
No documentation. The developer who built the integration will leave. Document the data map, the transformation logic, the API endpoints, the error codes, and the monitoring setup. Treat the integration as a product with a spec — not a script someone wrote and emailed to the team.
POPIA considerations for API integrations in South Africa
Any API integration that moves personal data — customer records, employee data, patient information — must be designed with POPIA compliance in mind from the start.
Key requirements for POPIA-compliant integrations:
Data in transit must be encrypted — TLS 1.2 minimum on all API calls. Data at rest in the transformation layer must also be encrypted if it contains personal information. Access to the API must be authenticated and role-based — not every system should be able to read every field. A log must be maintained of what data was accessed, when, and by which system — this is your audit trail for compliance purposes. Personal data should not sit in transformation buffers or message queues longer than necessary — design for minimal retention.
If you are integrating healthcare systems, financial data, or any customer-facing platform, have your POPIA obligations reviewed before the integration goes live. The Information Regulator's enforcement posture has hardened significantly since 2022.
When API-first is not the right answer
API-first modernisation solves the integration problem. It does not solve everything.
If your legacy ERP is causing problems beyond integration — if the system itself is unstable, vendor support has ended, it cannot scale to current transaction volume, or the business logic it encodes is wrong — then an API layer is a holding measure, not a solution. In that case, a full ERP modernisation is the right path, and the API work you do now can serve as a migration bridge while the new system is being built.
The right diagnostic question is: is the ERP still doing its job correctly, just not talking to anything? If yes, API-first modernisation is the right approach. If no — if the ERP itself is the problem — then modernising the integration layer only delays the harder conversation.
Where to start
If you have a legacy ERP that is not integrated with your other systems, the starting point is always a legacy system assessment — not a build.
Map what you have. Understand the system type (API-capable, database-accessible, or file-only). Document the data flows that matter most to the business. Identify the three integrations that would deliver the most immediate operational value if they were automated.
Then build those three first. Prove the approach. Demonstrate the ROI. Then expand.
API-first modernisation done this way is a series of contained, measurable projects — not a single large risky initiative.