ANSWER

What is a legacy system?

Reviewed · Reviewed by Paulo Pierrondi, founder.

A legacy system, in Legacy Exit, is the application or process that still runs the live operation. It takes an input, applies a rule and produces an output the business depends on. It is the current system that stays in command until a replacement has been approved. It can be an internal portal, a macro spreadsheet, an email approval flow or a whole application. It can also be the system of record for critical state, such as an ERP, a banking core or a medical record. In that case the core is not the first target: the work around it — checking, reconciliation, routing and reporting — is the slice that comes first. The risk of shutting this system down is not the new technology. It is discovering too late that the old application did something nobody documented. The manual describes one part. The code, the parameters, the logs and the team's practice describe the rest. A rule that was never written does not enter the equivalence contract, and what stays outside the contract becomes a surprise at cutover. You can retire a legacy system with no documentation, as long as the behavior is reconstructed from real inputs and outputs before the cut. Keeping the system also has a cost, and that cost is not a single budget line. The operating account adds license or support contract, team hours spent on maintenance, knowledge concentrated in a few people, security exposure from code that cannot be updated, and the opportunity cost of what the team stops delivering. The number that decides belongs to the operation itself. A generic market percentage does not replace observed budget, hours and risk. The way out is not a big-bang rewrite. Legacy Exit retires one process at a time, on proof, not on faith. The first slice is a recurring process, with stable rules and comparable inputs and outputs. A whole application comes in only when the critical processes can already be compared and reversed. Before anything is measured, the Equivalence Contract is closed. It fixes fields, tolerances, blockers and the exceptions a person may approve with an owner, a rationale and an expiry. It is not a generic accuracy percentage. A small difference can be material. A large formatting difference may be irrelevant. During dual-run both sides receive the same inputs, produce comparable outputs and the replacement has no production effect. Writes stay off. The legacy system stays in command, as the live operation, and the candidate runs beside it, in shadow. Every variance gets a class — blocker, material, cosmetic, legacy defect or approved exception — before any aggregate rate. An exception without an owner stays a blocker. An approved exception enters the Evidence Pack with an owner, a rationale and an expiry. The Evidence Pack is the dossier that supports the decision to shut the process down. It gathers what was compared, where a variance appeared, who accepted an exception, how rollback was rehearsed and why the final decision holds. It includes approvals with a name, a role and a date, including the final authorization of the cut. The pack is born from the Trail. Aggregate numbers without a period, an unclassified variance and an approval without a name are not evidence. Cutover is the later moment when operation leaves the legacy system and moves to the governed agent. It is not the dual-run and it is not a rewrite. Authorization is human. The agent does not shut the legacy system down by itself. Production, privileged access, money, deletion and the cut wait for a person. Rollback comes before the cut. The plan is ready when the return was rehearsed, access works and the decision has an owner. Brake and rollback are not the same exit. Brake stops the new execution. Rollback restores the previous operation and reconciles state. If equivalence is not proven, the valid outcome is not to cut over. Learning that before shutdown is control, not failure. Without reliable access, equivalence, approval or rollback, the size drops or the case is declined. The agent does not pretend to replace a system of record for critical state. Shutdown also does not erase the obligations on the data. Before the cut, historical data needs a retention answer, a read destination that does not depend on the old application, and a recorded disposal of what has lost its purpose. Moving everything into the new system is rarely the answer. The contract template and the Evidence Pack template are on the site. The sandbox pack is a fixture and not a customer case. None of that replaces human approval of the cut.

Step by step

  • Classify the system: it executes a rule over data that lives elsewhere, or it stores critical state as the system of record.
  • Watch what it actually does — inputs, outputs and hidden rules — not only the manual.
  • Close the Equivalence Contract before dual-run: fields, tolerances, blockers and owned exceptions.
  • Run the replacement in parallel, in shadow, with no production effect, and classify every variance.
  • Cut over only with human approval, a rehearsed rollback and an Evidence Pack; if equivalence is not proven, do not cut over.

How an agent does this

At AgenticosCore, the legacy system stays in command while Parallel compares the governed agent. Trail records each comparison. House Rules stop progress outside the contract, and Brake stops the new execution. Cutover stays blocked until the rollback rehearsal and the evidence are in the Trail.

Frequently asked questions

Is a legacy system the whole application?

Not necessarily. It can be one recurring process inside or around the application, an internal portal, a macro spreadsheet or an approval flow. The whole application comes in only when the critical processes can already be compared and reversed.

Does dual-run shut the legacy system down?

No. During dual-run the legacy system keeps operating and the replacement has no production effect. Shutdown is the cutover, with human approval, a rehearsed rollback and an Evidence Pack.

Primary sources