A one-paragraph definition
Legacy system modernization is the set of changes that keeps an old system useful, secure and maintainable without losing the business rules it carries: updating the platform, moving it to a current environment, reorganising the code or replacing modules, in the smallest dose that resolves the risk. "Legacy" is not an insult. It is the system the company depends on and nobody wants to touch.
The part of the definition that matters most is the last one: the smallest dose that resolves the risk. Modernizing is a decision about risk and cost, not about technology fashion. The goal is continuity — invoices going out, stock reconciling, tax documents being accepted — not the newest architecture.
What "legacy" means in a Brazilian company
The typical inventory of a Brazilian SMB: an ERP or intranet on PHP 5 or 7, a classic ASP or Visual Basic 6 system that only runs on one specific Windows machine, a counter billing system in Delphi, an old Java application on a dedicated server, a .NET Framework system tied to a Windows Server version and, in banks and insurers, COBOL routines. All of them work. That is exactly why nobody touched them.
What makes a system legacy is not age; it is support status and knowledge. PHP 8.2 reaches end of life on 31 December 2026, after which it receives no security fixes, and the same calendar exists for every Java and .NET version. A system whose documentation lives in one person's head becomes legacy the day that person goes on holiday. The Legate case shows both sides: a Delphi billing system that worked well, which the move to the national NFS-e standard forced open — and which was migrated with zero days of issuance stopped.
The five paths, one line each
Maintain in place: update versions, fix, document, secure backups and monitoring, without changing platform. Rehost: move the system as it is to the cloud, gaining automated backups and freedom from hardware risk. Replatform: swap the application server, the database or the runtime with targeted code changes. Refactor in parts: new modules coexist with the legacy system until they replace it, in the pattern Martin Fowler named the Strangler Fig. Rewrite in phases: only when the platform makes continuity impossible, and even then module by module.
The order is by cost and risk, and most SMB cases land in the first two. The article on maintaining or modernizing gives cost ranges for each path and the five signs it is time to act; the article on cloud migration strategies goes deep on rehost and replatform. Here the point is simply that the choice is not binary between "leave it" and "rewrite it".
What modernization is not
It is not swapping the system for an off-the-shelf ERP. That is a replacement project, with data migration, training and process change, and the old system's implicit rules do not come along. It may be the right decision, but it is a different decision. It is not "rewriting with one click": automatic code translation produces programs that compile and behave differently, and the difference shows up at month-end close. The article on AI in legacy systems explains what AI does well on this ground — documenting, extracting rules, generating tests — and what it still does not.
It is not redesigning the screens. A new interface on an unsupported PHP 5 back end is cosmetic: the risk stays the same, now better looking. And it is not necessarily a cloud project. Rehosting is one of the paths, not the definition; a dedicated server with tested backups and a current version is not a problem to solve.
How to tell whether yours needs it
The five classic signs are in the article on maintaining or modernizing: unsupported version, dependence on one person, a backup nobody ever restored, an integration starting to break, and server costs out of line. Two signs deserve their own mention. The first is a vendor or host announcing a date: the provider about to drop PHP 7, the Windows Server leaving support. The second is a legal change the system cannot absorb: the national NFS-e, the tax reform putting IBS and CBS on every invoice.
And there is the sign that arrives without notice. On 21 October 2026 the PHP2Shell flaw left every system on PHP 8.1 or older without an official fix. Those with an upgrade already scheduled brought it forward; those without discovered, in one afternoon, that the decision to modernize had been made for them. The article on the flaw covers what happened and what to do.
How JBKR does it: understand before touching
The first deliverable is always the two-week assessment: inventory of code, database and environment; risks ranked by urgency; essential documentation generated with AI support and reviewed by someone who understands the system; and a written roadmap with options and estimates. The report belongs to the client, even if the next stage is done by another team.
After that, every change follows the same discipline: a test environment that mirrors production, functional equivalence validated before each cutover, and a rollback path kept ready. Operations do not stop — in the Legate case, zero days of billing stopped. At JBKR the initial 30-minute assessment is free, and the first question is not "which technology" but "which risk do you want off the table this year".
