Risk 1: losing the rules nobody wrote down
Every old system does things nobody asked for and the business came to depend on: the specific rounding on the invoice, the exception for one customer type, the job that runs on the last day of the month and corrects a balance. None of it is in a document. It is in the code, and sometimes only in the behaviour. The article on AI in legacy systems shows this is exactly where language models go wrong when "translating" a system: they reproduce what is written, not what the business expects.
Mitigation: before touching anything, extract the rules from the code into a readable list, with AI support and human review, and validate that list with the people who operate the system. The old system is the living specification of the new one. Skip this step and you discover the rules one at a time, in production, over the phone with a customer.
Risk 2: data and functional equivalence
Character encodings, dates stored as text, decimals in cents in one table and in currency units in another, orphan records, a column repurposed ten years ago for something else. The new module reads the same data and computes a different total — and both sides are certain they are right.
Mitigation: functional equivalence before every cutover. The same inputs go through the old module and the new one, and the results are compared automatically, not by eye. The data migration is rehearsed on a copy as many times as it takes, and finance receives a reconciliation report before anything is switched off. If the totals do not match, the cutover does not happen.
Risk 3: integrations nobody documented
Electronic invoicing, the bank remittance file, the payment gateway, the marketplace feed, that overnight file exchange with a supplier over FTP. The integration that breaks is always the one missing from the inventory. In the Legate case the billing could not stop for a single day, and the communication layer with the national NFS-e was rebuilt with detailed logging and error handling precisely because the previous integration had neither.
Mitigation: inventory inbound and outbound connections from logs, firewall rules and scheduled jobs, not from someone's memory. And treat the regulatory calendar as a hard deadline: NT 2025.002, IBS and CBS on the invoice, the national NFS-e all have dates, and a modernization that ignores that calendar creates an emergency in the middle of the project.
Risk 4: stopping operations with no way back
The big-bang weekend cutover with no rollback path. The Friday deployment. The digital certificate that expires in the middle of the change window. These are the most visible risks and, oddly, the easiest to avoid — because they depend on method, not luck.
Mitigation: phases, module-by-module coexistence and a rollback path ready before every cutover, as described in the article on maintaining or modernizing. The migration of a dedicated Java server to the cloud followed that script: test environment, validated equivalence and a controlled switch, no rewrite. The old system is only turned off after a full cycle — a month-end close, a tax period — has run on the new one.
Risk 5: dependence on one person or one vendor, and scope creep
There is a quiet risk: swapping one single point of failure for another. The old system depended on the developer who left; the new one comes to depend on the vendor who built it on a proprietary framework and delivered no documentation. And there is classic scope creep: "while we're at it", the project to modernize one module becomes a rewrite of the whole system, with a rewrite's timeline and cost.
Mitigation: a written assessment and roadmap owned by the client; code and access with the company from day one; modules contracted with fixed scope; and JBKR's golden rule, published on the service page: the report is yours even if the next stage is done by another team. A vendor who resists that is selling dependence.
The other column: the risks of not modernizing
On 21 October 2026 the PHP2Shell flaw left every system on PHP 8.1 or older without an official fix, and CISA, the US government's cybersecurity agency, advised taking those systems offline until patched. That is the risk of waiting, made concrete in one afternoon: the decision to modernize was no longer the company's. The article on the flaw covers the episode; here it serves as proof that the "leave it alone" column has risks too, just not schedulable ones.
The others are familiar: the host forcing the upgrade at the worst possible time, the integration that ends (the municipal NFS-e gave way to the national one), the only person who knows the system leaving, the backup that was never restored failing on the day it is needed. Both columns carry risk. The difference is that only one of them can be planned, phased and tested.
Shrinking the risk to a manageable size, and the next step
The rule is to make the smallest move that resolves the current risk, and to make it with method. That almost always means starting with the assessment, not the migration: two weeks that produce an inventory, risks by urgency, documentation and a roadmap with options. The article on what modernization is defines the five paths; the article on cloud migration strategies covers the cloud-specific choices; the article on maintaining or modernizing gives the cost ranges.
At JBKR the initial 30-minute assessment is free, and the two-week report is itself the main mitigation for every risk in this article: what is written down and tested does not surprise you.
