The right question is not "rewrite or not"
When a system starts causing trouble, the first proposal that shows up is to rewrite everything. It is the most expensive, the slowest and the one that fails most often: the old system carries years of undocumented business rules, and the new one "forgets" cases the old one handled. The right question is: what is the smallest move that resolves the current risk?
There are four possible answers, in order of cost: maintain and protect (update version, backups, monitoring), modernize in place (refactor the critical points without changing platform), modernize in parts (new modules coexisting with the legacy) and rewrite in phases. JBKR presents the menu with pros and cons in every assessment, and in most cases the answer lies in the first two options.
Five signs it is time to act
Unsupported version: PHP below 8.1, .NET Framework 4.x with no plan, Java 8 in production without security updates; the hosting provider will force the change, usually at the worst time. Single-person dependency: only one developer (or none) can touch it. No tested backup: a backup exists, but nobody has ever restored it. Breaking integrations: e-invoicing with a new layout, discontinued payment API, expired certificate. Server cost: an expensive dedicated machine for an application that would fit a small cloud environment.
One sign calls for maintenance. Three or more call for an assessment and a roadmap.
What each path costs in 2026
Ranges practised by JBKR and by the small and mid-size market in Brazil. Two-week assessment: BRL 5k to 15k (fits the On-Demand plan at BRL 250/hour). Maintain and protect: version and environment update, backups and monitoring, BRL 8k to 30k per system, plus monthly support of BRL 1,125 to 2,050 on JBKR's plans. Modernize in place or in parts: BRL 30k to 150k depending on the number of critical modules. Rewrite: from BRL 150k, in phases, with the old system as a living specification.
A common mistake is comparing the cost of rewriting with zero. The cost of doing nothing exists: hours of manual rework, downtime risk and the emergency price when the host switches off the old version.
PHP, Java and .NET: what changes in each
PHP: the most common path is upgrading from 5.x or 7.x to 8.x while fixing incompatibilities, and migrating old frameworks (CodeIgniter 2, Laravel 4) module by module. It can almost always be done without a rewrite. Java: the problem is usually the environment (old application server and Java) and the answer is support, dependency updates and a cloud migration without touching the logic, as in the dedicated-server-to-Jelastic migration JBKR delivered. .NET: .NET Framework systems tied to a specific Windows box migrate gradually to .NET 8 or later, module by module, keeping the SQL Server database.
Classic ASP and VB are the most urgent case: the platform is discontinued and there are no developers on the market. There, modernization in parts is mandatory, but still in phases, preserving the business rules.
The method that avoids breaking what works
First, recover technical control: credentials, full backup, system map. Second, a test environment that replicates production; no change goes live without passing through it. Third, small, logged changes. Fourth, functional equivalence: before every cutover, the new module produces the same results as the old one on the same data. Fifth, a rollback path ready.
With AI, the mapping and documentation stage became much faster; the article on AI on legacy systems explains how. Without method, AI only speeds up the mistake.
The decision on one page
If the system works and the risk is version or backup: maintain and protect, with monthly support. If it works but two or three modules block evolution: modernize in parts. If the platform is discontinued and no longer runs on current servers: rewrite in phases, starting with the most critical module. In every case: assessment first, written report, and the code and credentials stay with you.
JBKR offers the initial 30-minute assessment at no cost. The system you are most afraid to touch is usually the one that most needs a technical owner, and the one that least needs a rewrite.
