From accumulated code to declared configuration.

Partly, and it's worth understanding which part, because it's the most serious reason to modernise and the least discussed in commercial proposals.

Concentration risk has two components. The first is technical knowledge of the system — how it's built, where to touch it — and that transfers, laboriously, to anyone with the skills. The second is domain knowledge: why that control exists, which real case produced that exception, what happens on 31 December. That's the irreplaceable part, and it's the part that leaves with the person.

The declarative model performs no magic, but it moves the second kind of knowledge from code into a document a domain person can read. When the rule "an order paid in advance cannot ship without confirmed receipt" is written as a readable condition instead of inside a function, anyone who knows the trade can verify, challenge and correct it, without knowing how to program.

The extraction work remains — the hardest phase of the project, and one nobody can do for you: someone has to sit with that person and write down what they know. The value of that work, however, doesn't depend on the project continuing.

Rarely stuck, often slowed. In practice there are three routes, in order of preference.

• Application interfaces, where they exist: the best route, because legacy keeps control of its own logic and operations are synchronous and verifiable.
• Structured file exchange, the most common reality in systems of a certain age: periodic inbound extracts and return files. It works well, provided you carefully design frequency, discrepancy handling and what happens when two worlds diverge.
• Direct database reads, read-only and agreed with whoever maintains the system: workable when the other two don't exist, as long as it stays read-only.

What we don't do is write directly into a legacy database bypassing its application logic. It looks like the shortcut that solves everything and is the cause of the worst damage, which surfaces months later in forms hard to trace back to the cause.

The right question isn't how long modernisation takes, because put that way the honest answer is "years" and it helps nobody decide. The useful question is: how long before the first domain is in service and producing value on its own.

For a narrow, well-defined scope the order of magnitude is a few weeks from the initial session, plus the time for legacy integration — the most uncertain variable, depending entirely on what that system exposes and how available its maintainers are. That's why the feasibility check is the second step of the path and not the last.

From there the pace depends on how many domains you want to bring across and with what resources. The difference from a rewrite is that there's no date beyond which the project either succeeds or was pointless: every completed domain is value banked, regardless of what happens afterwards.

It becomes a far simpler decision than it is today, for a specific reason: by then the legacy perimeter has narrowed and its rules have been written down.

The reason you can't switch it off today isn't that it's technically impossible: it's that nobody knows exactly what it does. After three or four domains have been moved out and formalised, what remains inside is a smaller, better understood set. Replacement, at that point, is a project of known size instead of a leap in the dark.

It should be said frankly, though, that in many cases it still isn't worth it. If legacy has shrunk to doing posting and calculations that have worked for twenty years without trouble, replacing it is spend without return. Successful modernisation isn't the kind that eliminates the old system: it's the kind that stops being its prisoner.