The short version. Legacy modernization is one of the few projects that gets harder every year you wait. The biggest hidden risk is losing design intent that was never written down. The biggest unforced error is treating modernization as a one-time project rather than as a chance to build for the next thirty years. There are four valid strategies, and gradual model-based migration fits most organizations best. Done well, it is the last modernization that has to be approached as a re-engineering project.
Why legacy control systems become a problem
Legacy control systems do not fail catastrophically, which is part of why they are so hard to address. They run reliably for years past the point where they should have been renewed. They simply become harder to operate, harder to change, and harder to defend in audit. The symptoms are familiar:
- Documentation that no longer reflects the code, because changes were made under operational pressure and never documented.
- Spare-parts availability that has narrowed to the point where the next failure is a procurement project.
- Original engineers who built the system have retired or moved on, and the institutional knowledge moved with them.
- Behavior that nobody can confidently change, so operators and maintainers work around it rather than fix it.
- Cybersecurity exposure from operating systems and protocols that predate modern threat models.
- Regulatory pressure to demonstrate traceability that the existing system cannot produce.
Each symptom alone is manageable. Together, they describe a system that is operating on borrowed time. Modernization stops being optional and becomes a question of how, when, and at what risk.
Flexibility as the forgotten requirement
The deepest reason legacy control systems become hard to modernize is that they were never designed to be modernized. Industrial control software is specified on functional requirements (what the system must do) and almost never on evolutionary requirements (how the system must accommodate change over its lifetime). Reliability, determinism, throughput, safety, and uptime are written into every specification. Flexibility almost never is.
This is the requirement that gets forgotten because it does not show up in commissioning. A system that is impossible to change still passes its acceptance tests. The cost of inflexibility is invisible until the first significant change is needed, which is often years after the engineers who could have designed for it have moved on.
The result is the standard pattern: a system that was built to work, never built to change, and now cannot be safely changed. The unspoken assumption is that the system will not need to change. That assumption is wrong in essentially every case. Operational requirements shift, regulations tighten, integrations get added, and hardware ages out. A water treatment plant built in 1998 to meet the regulations of its era is asked, twenty years later, to add nitrogen removal and integrate with a utility-wide SCADA system, neither of which existed when the system was specified. The control software has no architectural place to accept those changes, so each one is bolted on, raising the cost and risk of every subsequent change. Change is the one requirement that is certain to arrive, and the one requirement that almost no specification accounts for.
Modernization is, in part, the price of having forgotten that flexibility was a requirement. The platforms that prevent the next modernization from being equally painful are the ones that treat changeability as a first-class architectural property, not as something that emerges accidentally from good intentions.
The cost curve of waiting
Legacy modernization is one of the few projects where the cost of waiting is monotonically increasing. Every year of delay makes the migration harder, more expensive, and riskier. The reasons are structural.
Code degrades. Each operational change adds another patch to a codebase that nobody is refactoring. The result is the well-known onion: layers added over decades, each one masking the layer beneath. When the time comes to peel them back, every layer that comes off is a small revelation about a workaround, a forgotten incident, or a quietly accepted defect.
People leave. Each year, more of the engineers who actually understand the system retire, change roles, or move on. The window in which the original design intent can still be reconstructed from human memory closes, slowly, in only one direction.
Documentation drifts further. The gap between what the documents say and what the system does grows monotonically, because the system changes and the documents do not.
Hardware narrows. The set of compatible spare parts shrinks every year. At some point, the migration becomes mandatory, but it is also forced under time pressure rather than chosen on a controlled schedule.
The honest framing is that you know modernization will eventually be needed, on every long-lived control system. The only real question is whether the project happens on a schedule of your choosing, with the people who built the system still available to consult, and with documentation that still bears some relationship to reality, or whether it happens later, on a schedule forced by circumstance, with none of those advantages. Waiting is not a neutral choice. It is a choice to make the same project more expensive.
The hidden risk: losing design intent during modernization
The single biggest cause of modernization project failure is not technical. It is the loss of design intent. Long-lived control systems carry behavior that was added under operational pressure, never written down, and now matters because it works. A bridge has a deviation in its open-close sequence to handle a specific drainage condition. A water plant has an interlock added after a 2009 incident that nobody remembers in detail. A process line has a startup delay that everyone treats as routine but nobody can explain.
That kind of intent does not survive a clean rewrite. A team given the original spec and told to "build the new one" will reproduce the spec, not the system. The first six months of operation under the new system will then be a slow rediscovery of the special cases the legacy system had quietly encoded.
Capturing design intent before modernization (not during, not after) is the discipline that separates successful projects from painful ones. Whether the source is the running code, the operators' tacit knowledge, or the maintenance log, the intent has to land in a form that the new system can preserve.
The four modernization strategies
The choices fall into four patterns. They differ in cost, risk, scope, and what they leave behind.
Rip-and-replace. Build a new control system in parallel, in a new platform, and cut over. This is the cleanest path conceptually and the most expensive in practice. Behavior has to be re-specified from scratch, the new system has to be re-validated, and the cutover carries operational risk. The hidden cost is design intent: in a long-lived legacy system, much of the behavior is not in the original spec but in field-discovered exceptions, retrofits, and operator workarounds. Rip-and-replace tends to lose those, then rediscover them painfully during commissioning.
Lift-and-shift. Port the existing code to a newer controller of the same vendor family. Lower cost, lower behavioral risk, lower benefit. The system runs on supported hardware, but the underlying code-centric architecture is unchanged. Documentation drift, knowledge loss, and lock-in all persist into the next 15-year cycle.
Model-based migration of the whole system. Capture the existing system behavior in a vendor-agnostic model, validate the model against the running system, and regenerate code for the chosen target. The model becomes the new maintained artifact; the old code becomes a reference for verification. Cost is higher than lift-and-shift and lower than rip-and-replace. The benefit is structural: design intent is preserved, knowledge is captured in a form that outlasts individuals, and future modernizations are smaller because the model is portable.
Gradual model-based migration. Many asset owners cannot replace the entire system at once. Operations cannot be paused, capital is not available, or the risk of a full cutover is unacceptable. The fourth option is to model and replace the most critical parts first, and connect the new model-based components to the remaining legacy through standard interfaces. The legacy system continues to run the parts that work; the model-based components take over the parts that needed renewal. Migration happens incrementally, asset by asset, subsystem by subsystem, on the maintenance budget rather than a single transformation budget. This is the strategy that fits most real organizations, because it matches how industrial assets actually evolve.
The role of digital twins and AI in legacy modernization
Two technologies are starting to change the economics of legacy modernization, and both are easier to oversell than to deliver.
Digital twins, used carefully, make verification easier. A model of the legacy system can be simulated and compared against the live system, which sharply reduces the risk of behavioral surprises during cutover. The discipline that matters is whether the twin shares the same model that will produce the new deployable code, or whether it is a separate artifact that will drift. Twins built as part of a model-centric migration are a real accelerator. Twins built separately, as a parallel visualization, mostly add cost.
AI helps recover code-level intent. Modern language models can read legacy code and produce useful summaries, identify likely state machines, and surface comments and patterns that would otherwise take an engineer weeks to extract. This narrows the discovery phase meaningfully. What AI cannot do is reconstruct the design intent that was never in the code: the field-added exceptions, the operator-discovered workarounds, the unwritten rules. Those still require human interviews. AI accelerates the parts of the work that are textual. The parts that are organizational still require talking to people.
The honest framing is that digital twins and AI together can compress a legacy modernization timeline by 20 to 40 percent. They do not eliminate the project. They make the project more achievable on a schedule that organizations can actually run.
How model-centric platforms help capture and preserve behavior
Model-centric platforms are well suited to legacy modernization because the model is the natural place to consolidate design intent. Engineers extract behavior from the running code, interview operators and maintainers, examine maintenance logs, and gradually build a model that captures both the documented and the field-discovered behavior. The model can be simulated and validated against the existing system before any new code is generated.
Cordis SUITE has been used for legacy modernization across national infrastructure, water management, and high-tech manufacturing for over two decades. The pattern is consistent: capture the existing behavior in a model, validate the model against the running system, regenerate code for the chosen target, and deploy. The platform supports both whole-system migration and gradual replacement, with standard interfaces (gRPC, OPC UA, vendor-specific protocols) connecting model-based components to whatever legacy systems remain in place.
The strategic value is not just that the modernization works. It is that the modernization is the last one that has to be approached as a re-engineering project. Once the system lives in a model, future hardware renewals regenerate code for the new target without re-specifying the system. Future regulatory changes update the model and propagate. Future operational changes are model edits, not code archaeology. Cordis SUITE is built to be the platform that makes the next modernization unnecessary.
The benefit compounds across an asset portfolio. An operator with twenty similar bridges or fifty similar pumping stations can build a model family in which shared behavior is captured once and variation is expressed cleanly. Modernization across the portfolio becomes a series of controlled migrations rather than twenty separate engineering projects. Each subsequent asset is faster than the last, because the model already knows most of what the new asset needs.
A practical sequence for modernization projects
A well-run model-based modernization typically follows roughly this sequence:
- Discovery. Inventory the system, the controllers, the I/O, the documentation, the operators' tacit knowledge, and the maintenance log of changes that were never documented.
- Behavior capture. Build a model that represents the existing system behavior, extracting from code where possible and from interviews where not.
- Validation. Simulate the model and compare its behavior against the running system. Resolve every discrepancy explicitly: either the running system has a quirk that should be preserved, or it has a defect that should be fixed in the model.
- Generation. Generate code from the model for the chosen target hardware. The code is read-only; the model remains the maintained artifact.
- Cutover. Deploy the regenerated code, with operational fallback to the legacy system during the validation window. Monitor runtime traces against the model.
- Operation. The model is now the source of truth. Future changes happen in the model. Future hardware renewals regenerate code for the new target without touching the model.
The sequence is not glamorous, but it is the path that preserves behavior, knowledge, and operational continuity at the same time.