Legacy system modernization and system integration
The hardest part of legacy system modernization is usually not the new code but keeping the business running while the old code is replaced. The approach I use is gradual: the running system keeps serving its users while its parts are replaced one at a time, each change is small enough to verify, and the contracts with the systems around it hold on every day of the migration. This page is for organizations whose software still works but holds them back — an old framework, a monolith that every change has to pass through, integrations held together by hand — and for teams that need a new system connected to the ones already in place.
Proven results
A monolith migrated without a feature freeze. On the SNAP fraud case management system I led the migration of a legacy Spring and Hibernate monolith to Spring Boot and Spring Data JPA module by module — staff, counties, households, merchants, transactions, tips — without freezing feature work, and introduced versioned database migrations with Liquibase.
Platform-wide standardization. On Iotatech Claims, I designed a reusable timezone-aware date/time module and a universal Angular UI component, replacing inconsistent implementations across 5 backend services and 3 web portals.
New partners by configuration, not code. On AMS, a merchant onboarding platform connected to around twenty downstream systems, I evolved the public registration contract and the global configuration so that new products and partners could be onboarded through configuration rather than code changes.
Five financial APIs behind one platform. On Root Studio I connected external financial APIs — Integrated financial and CRM platforms, including Plaid, Coinbase, Currencycloud, Wealthica, and HubSpot, through Spring Boot services, with unified REST and GraphQL interfaces.
A legacy application rebuilt in one shot. Bolimond, an artist's portfolio and CMS, is a one-shot rebuild of a legacy application on Java 21, Spring Boot and Vue 3.
Have a system that works but cannot move? Discuss your project: what it runs on, what it talks to and what keeps breaking. See the projects for the migrations and integrations above in full.
What I build
Module-by-module migrations. A monolith moved to a current framework one module at a time, while feature work continues on the rest.
Two implementations behind one switch. A layer with one interface and two backends, such as search that runs the same pages on Solr or on direct SQL by one config flag, so the backend can change without touching the pages.
A database history you can trust. Versioned migrations with Liquibase instead of hand-applied scripts, so every environment reaches the same schema the same way.
Cross-platform standardization. Shared backend modules and reusable UI components that eliminate duplicated logic and ensure consistent behavior across services and applications.
Contract-first integrations. A written contract (an XSD or an API schema), an adapter per external system, graceful handling of empty and missing responses, no secrets in payloads, and an integration test suite that stays green through contract changes.
Integration platforms. Gateway, configuration and worker services with per-tenant database provisioning and webhook-driven flows, as a single place where external providers plug in.
Bridges into software you already run. A one-file PHP bridge that lets a new pipeline publish into Bitrix; links to 1C accounting, a bank API and a POS from a booking backend.
When the old system's limits are load and scale rather than age, the work continues under distributed systems architecture; rule engines and multi-tenant platforms are covered under custom business software development.
How I work
Before anything is replaced, I read the system as it is: what it does, which parts change often, which parts nobody dares to touch, and what talks to it from outside. The external contracts are pinned down first — an API schema, a file exchange, a partner callback — because they have to keep working throughout. Then the order of work: the parts that block the business or slow every change go first, each replaced behind its existing interface with tests around it, while the rest keeps running. A full rebuild is the right call only when the application is small and its behavior well understood, as it was with Bolimond.
As a solution architect I define the target structure and the route to it. On the SNAP system I carried the migration myself as lead backend developer; on Iotatech and AMS I made such changes as an engineer on larger teams.
Projects in this domain
MDHS Program Integrity — SNAP Fraud Case Management System — Lead Software Engineer, 2016–2018. The fraud investigation system of the Mississippi Department of Human Services, built by NSPARC (Mississippi State University). Besides the migration, I designed the Strategy-based search layer that runs on Solr or direct SQL, implemented the audit trail on Hibernate Envers and introduced email notifications through a queued SendGrid and SES sender.
Iotatech Claims (CLM) — Software Engineer, 2016–2018. Designed and implemented a reusable date/time management module across 5 backend services and a universal Angular UI component shared by 3 portals, replacing fragmented implementations with consistent timezone-aware behavior.
AMS — Automated Merchant Setup (Wirecard) — Software Engineer, 2018–2020. A payment provider's onboarding platform with an integration module per external system. Besides the contract work, I built and hardened adapters to partner systems (NOVA, WEP, WDP, Klarna), with query support, graceful handling of empty and 404 responses and secrets removed from node payloads, and kept the Citrus integration suite green through contract changes.
Root Studio — Lead Software Engineer, 2020–2021. A low-code studio and integration backend for a fintech lending CRM, connecting banking, crypto, FX and CRM providers, with per-tenant database provisioning and webhook-driven flow execution.
Bolimond — Author, 2026. The artist's current portfolio and CMS, rebuilt in one shot on the latest stack; the same artist's earlier site, Bolimond Portfolio (old), was a JSP application from 2013.
Blog Writer — Solution Architect, 2026. An AI content pipeline that publishes into the client's Bitrix site through a one-file PHP bridge: publish, update, deactivate, image cleanup and sitemap refresh.
Beauty Studio "Krasa" App — Software Engineer, 2018. A booking system integrated with 1C, a bank API, card payments, a POS and Firebase, where I worked as an engineer on the team.
Frequently asked questions about legacy system modernization
Rewrite or migrate?
Migrate, in most cases: a module-by-module migration keeps the business running and features shipping, as on the SNAP system. A one-shot rewrite suits a smaller application whose behavior is well understood, as with Bolimond. The deciding questions are the size of the system, how well its behavior is documented or tested, and how much change the business can absorb at once.
Can you work on a system you did not build?
Modernizing established systems starts with understanding their architecture and constraints. Both AMS, a complex payment platform, and SNAP, a legacy monolith, required careful analysis of existing code, dependencies, and integration contracts before introducing architectural improvements while maintaining operational stability.
How do you keep integrations working during a migration?
By treating every external interface as a contract: written down, covered by integration tests, and changed only on purpose. On AMS the registration contract evolved so that new partners needed configuration rather than code, while the integration suite stayed green.
How long does a modernization take?
It is planned in stages rather than as one date: each stage ends with the system running and something measurably better. The number of modules, external integrations and data to migrate decides how many stages there are.
Need an engineer with experience in legacy system modernization? Write to me — a few lines about the task are enough — or look through my CV.