Skip to content
Rohit Behera
← All work
Kind
Professional · a global bank
Year
2023–2026
Role
Backend engineer
Stack
JavaSpring BootPostgreSQLRESTSOAPElasticsearchAzure DevOps
Source
Private · walkthrough on request

Legacy service modernization

Moving a bank's account-servicing endpoints off SOAP onto a standard REST architecture, one endpoint at a time, without changing what any of them did.

The hard partBehaviour had to be provably identical before and after, including the parts nobody had documented, because the thing on the other end of the endpoint is somebody's account.

  • 17+ endpoints migrated, ≈35% of the programme
  • Test coverage raised to 80% by writing the test first
  • Legacy maintenance overhead down ≈25%

The problem

A core banking platform accumulates a particular kind of debt. The services work, they have worked for years, and nobody wants to touch them, which is exactly why the cost of changing anything keeps rising. The brief was to move account-servicing endpoints onto a standard REST architecture while the old ones stayed live and correct.

The constraint that shapes everything: a regulated environment, where there is no "move fast" version.

Approach

Endpoint-by-endpoint migrationFor each endpoint: first write tests that pin what the legacy SOAP endpoint actually does, including undocumented behaviour. Then rebuild it through the full REST stack: resource, mapper, translator, repository. Ship it on its own with its own rollback, compare old and new behaviour through searchable logs, and move to the next endpoint.PER ENDPOINT17+ timesLegacy SOAPlive, undocumentededge casesPin behaviourtests written firstagainst the old contractRebuild through the stackresource → mapper→ translator → repositoryno SOAP façadeShip aloneown rollbackdiffs queryable in Kibananext endpoint
Repeated per endpoint, never as one cutover. Each step can be rolled back on its own.

Rebuild the layers, do not wrap the old service. Each endpoint was rebuilt through the full stack — resource classes, mappers, translators, repositories. A REST façade over SOAP would have been faster, and would have kept the original shape of the problem, which was the thing being removed. Wrapping relocates the maintenance burden; rebuilding reduces it.

Write the test before replacing anything. In a migration, test-first is less about design and more about evidence. Writing the test forces you to state what the legacy endpoint actually does, including the undocumented parts, before you are allowed to replace it. Coverage went from legacy levels to 80%. That number is a by-product of the method, not a target that was chased.

Migrate endpoint by endpoint, never as a cutover. Each one shipped and could be rolled back on its own. In a bank, the rollback plan matters as much as the feature.

Make differences searchable. Logs went to Elasticsearch and Kibana, so a discrepancy between old and new behaviour could be found by a query rather than by reading.

Outcome

17+ endpoints migrated, roughly 35% of the modernization goal for the targeted system. Maintenance overhead on the legacy surface fell about 25%, and standardising on one REST architecture cut the team's debugging and testing time by around 40%, most of it time previously spent working out what the old contract was.

Outcome

17+ endpoints migrated, around 35% of the programme's scope for the targeted system, with coverage raised to 80% and maintenance overhead on the legacy surface down about 25%.

loading index…Full retrieval trace →