- Maintenance
Opening a legacy application through an API rather than rewriting it
When the real need is integrating the application with the rest of the estate, exposing a thin API costs a fraction of a rebuild and leaves the business core intact.
· 4 min read · AzerOps
The request rarely arrives as "let us rewrite this application". It arrives as "sales want to view files on their phones", or "the new BI tool needs access to this data", or "the customer portal must show the balance in real time".
The need is an integration need. A rewrite is a disproportionate answer.
What opening through an API allows
A thin service layer placed in front of the existing application exposes the data and operations other systems need, without touching the application core. The modern portal, mobile app or BI tool consumes that interface.
Three concrete advantages. Cost is measured in weeks rather than years. Risk is low: the existing application's behaviour is unchanged. And you get, along the way, the building block that will make a future migration far simpler if it becomes necessary.
The three ways to build that layer
On top of the application code, if the sources are available and the language allows services to be exposed. It is the cleanest option: existing business rules are reused as they are.
At the database level, with views and procedures encapsulating access logic. Faster, but it bypasses application-level business rules, which is acceptable read-only and dangerous for writes.
Through an intermediate service reading a replica of the database and exposing a clean interface. This is the option chosen when writes must stay exclusively in the original application, which is often the case.
The rules to follow
Read first. Opening reads covers most integration needs and carries limited risk. Writes are opened only once validation rules are properly reproduced or delegated back to the original application.
A versioned interface contract. The API must have its own definition, independent of the internal structure. If your API exposes the database schema directly, every internal change breaks consumers, and you have ruled out any evolution.
Rate limiting. An old application sized for fifty internal users will not withstand a thousand requests a minute from a public portal. The API layer must protect the underlying system, not merely expose it.
Characterisation tests. Before exposing anything, write tests describing the current behaviour. They will serve as the reference if the logic ever moves elsewhere.
What it sets up
Once the API is in place, progressive migration becomes possible: consumers talk to the interface, not the application. You can replace a module behind the API without anyone downstream noticing.
It is the only modernisation strategy that lets you stop halfway without having lost anything. A rewrite interrupted at 60% produces no value; an API opening interrupted after the first domain has already met a real need.
Typical cost
For a medium-sized business application, exposing a first functional domain is measured in weeks. That is an order of magnitude that lets you address the need inside the running operating budget, without going through an investment committee — often the decisive argument.