A legacy ERP system is rarely just software. Over years or decades, business rules accumulate inside source code, database schemas, configuration tables, interfaces, batch jobs, reports, file formats and operational routines. Some of those rules are documented. Some are only visible in the behavior of the system. Some are historical accidents that no longer matter, while others encode essential commercial, accounting or regulatory meaning. Replacing such a system therefore should not begin with a rewrite. It should begin with reconstruction: understanding what enters the system, what leaves it, which algorithms and transformations connect the two, and which parts of that behavior must survive.
9Work gives the Operator a way to investigate that system together with an external AI while keeping the investigation grounded in the Machine. Inputs and outputs can be treated as observable contracts. Source code, configuration, schemas, reports and interface definitions can be inspected as Evidence. Historical transactions can be traced through the system. The AI can help identify conditions, transformations, state changes, lookup rules, rounding behavior, exceptions and dependencies. But the objective is not simply to understand how the old software was written. It is to reconstruct the semantic contract the software implements: what an order means, when stock changes, how an invoice is derived, which accounting event is created, what a particular status represents and which distinctions the surrounding business depends on.
That distinction matters because a legacy implementation contains both business meaning and historical baggage. A strange branch in the code may represent an important legal or commercial rule. Another may exist only because a database from twenty years ago could not do something more directly. A duplicated field may preserve a real distinction, or it may be an obsolete workaround. The Operator, AI and relevant domain specialists have to separate these categories rather than carrying everything forward indiscriminately. Source code is therefore one witness among several. Actual business behavior, observed inputs and outputs, data, interfaces, documentation, configuration and operational practice all contribute to the reconstruction.
The recovered understanding can then be persisted as programmatic Ground in a 9Work Workspace. Instead of leaving the reconstruction inside an AI conversation, the Operator can preserve entities, terminology, states, invariants, input contracts, output contracts, transformation rules, examples, unresolved questions and Machine Evidence. The legacy ERP can gradually be decomposed into bounded semantic territories such as master data, order processing, inventory movement, pricing, invoicing, accounting, reporting and external interfaces. Each territory can become a clearly defined Objective. What begins as an opaque monolith becomes an explicit intellectual program of what the replacement system must preserve.
Only then does software engineering begin. The goal is not to translate one legacy codebase into another language line by line. It is to positively reconstruct the accepted functionality in a new architecture. Historical transactions can form a reference corpus: known inputs are preserved together with the outputs produced by the legacy system. A reconstructed subsystem can then be Rehearsed against those cases. Differences become useful Evidence. A discrepancy may reveal a defect in the new implementation, an undocumented legacy rule, a data-quality problem, obsolete behavior or an intentional improvement. Rehearsal turns those differences into questions before the reconstructed system receives authority.
For a system as consequential as an ERP, that process can continue beyond isolated tests. New functionality can run in parallel with the legacy system, receiving equivalent inputs while its outputs are compared without yet becoming authoritative. Migration can proceed through bounded transitions rather than a single big-bang replacement. Data conversion, reconciliation, interface switching and business cutover can each be Rehearsed and verified. The result is not merely a new ERP that resembles the old one. It is a system whose meaning has been recovered, made explicit and deliberately reconstructed. The business system survives. The historical implementation does not necessarily have to. What remains is durable Ground, reconstructed functionality and Evidence of how the transition was made.
—