A one-for-one migration moves a plant’s control system to a new platform. It also moves every inactive point, obsolete function, and undocumented workaround that built up over 30 years. A structured review before conversion catches those defects while they are still cheap to fix.
Why like-for-like migration falls short
Most legacy distributed control system (DCS) migrations are scoped as technology replacements: same points, same logic, new hardware. That framing is understandable. It keeps the scope predictable and the operators comfortable. But it treats the legacy configuration as correct simply because it is running.
In practice, a control system that has operated for decades carries history. Instruments are removed from service, but their points stay configured. Logic written for a process condition that no longer exists keeps executing. Alarm settings drift away from the current alarm philosophy. Custom code nobody fully understands is left alone because touching it feels risky.
Convert all of that line by line and the new system inherits it. The platform is modern; the engineering inside it is not. The plant pays for the defects twice: once in migration hours spent converting a configuration it did not need and again in testing, troubleshooting, and maintenance afterward.
The framework described here treats modernization as an engineering problem rather than a translation exercise. It separates two questions that a like-for-like migration merges into one: what the new platform can support and what configuration should actually be implemented after the current process and system have been validated.
The framework at a glance
The structured legacy DCS modernization framework has six phases. Each phase ends at a quality gate, so an unresolved question cannot quietly move into the next phase. Phase 2 is the analytical core, and Phase 6 feeds what was learned back into the method for the next project.
Phase 1: Legacy system assessment
The first phase builds a baseline the team agrees on before anyone decides what to migrate. That means mapping the architecture at a useful level; inventorying control modules, input/output (I/O), graphics, alarms, and interfaces; and comparing the documentation against the actual configuration exports.
The key discipline is to record uncertainty instead of resolving it silently. Every point that looks inactive, duplicated, or unexplained goes into an open-questions log. The baseline is not an endorsement of the legacy configuration. It is the reference every later decision is traced back to.
Gate: The baseline is approved by controls, process control, and operations.
Phase 2: Discrepancy and bottleneck analysis
This is the analytical core. Each in-scope control module is reviewed against its operational intent, not accepted because it exists. The reviewer asks a fixed set of questions:
The goal is not to delete a configuration because it is old. It is to show, with evidence, whether each element is still necessary and appropriate. Every retirement gets a documented basis, and process control confirms intent before anything with an interlock or safety implication is changed.
Gate: All critical and major dispositions are approved.
Phase 3: Modernization protocols and validation
Once dispositions are approved, the team needs a controlled way to convert what remains. Phase 3 turns recurring decisions into written conversion rules, so ten engineers make the same call on the same type of point.
In a Honeywell TPS/HPM to Experion C300 migration, typical rules look like this:
- Regulatory control points: Convert to C300 control modules; confirm the algorithm, mode handling, and output limits against the legacy point.
- Custom CL logic: Never convert line by line. Confirm the intent first, then rebuild it in CM/SCM logic or retire it with a documented basis.
- Inactive or spare points: Do not migrate these unless a documented future need exists.
- Alarm settings: Migrate these only after reviewing them against the site’s current alarm philosophy.
- External references: Confirm every consumer (historian, OPC, and applications) before a point is renamed or retired.
Acceptance criteria for factory acceptance testing (FAT) and site acceptance testing (SAT) are written in this phase, before implementation, and each critical function is traced from requirement to configuration to test result.
Gate: Engineering and test readiness are confirmed.
Phase 4: Automated tools and monitoring
A unit with more than a thousand control modules cannot be compared by eye. Phase 4 adds automated checks where they improve repeatability: comparing legacy and target configuration exports, flagging missing attributes, generating checklists, and tracking discrepancy and test status on a dashboard.
The tools are aids, not judges. Every output is reviewed against the process intent and the limits of the source data, and scripts are version-controlled where project procedures allow.
Gate: Tool results are reviewed by the responsible engineer.
Phase 5: Controlled deployment
A correct configuration can still fail at cutover. Phase 5 treats cutover as an operating event with its own engineering plan: the sequence, the dependencies, the manual-operation fallback, the rollback criteria, and who has authority to call it.
The go/no-go decision rests on objective readiness, not on the schedule. Typical criteria are completed testing, closed or formally dispositioned critical findings, verified backups, operations readiness, and confirmed recovery procedures. During execution, anything unexpected is assessed against the approved tolerance and handled through the predefined escalation path.
Gate: This phase is the go/no-go approval.
Phase 6: Post-migration evaluation and continuous improvement
The work is not finished when the new system goes live. Phase 6 confirms that critical functions behave as intended, reviews alarms and operator feedback, closes residual discrepancies, and compares planned against actual results.
It also closes the loop on the method itself. Lessons learned are written into the next version of the framework, so each project starts from a better baseline than the last. Every metric reported identifies its source; anything that cannot be measured objectively is reported qualitatively, not as a number.
Gate: Closeout is approved and lessons are incorporated.
Field results: A refinery alkylation unit
On a DCS upgrade of an alkylation unit at a US refinery, the Phase 2 review has covered roughly 900 of more than 1,500 control modules so far. It has produced 299 findings, about one for every three modules reviewed.
The approach has evolved over several earlier projects. Its first version, applied to DCS updates at petrochemical plants in Mexico between 2017 and 2019, cut system-update installation time by about 30%. Later versions were refined on Honeywell OPM projects and on a TPS/HPM to C300 migration with hot cutover at another US refinery.
Lessons learned
- Review before you convert. A finding resolved in Phase 2 costs a conversation and a log entry. The same finding discovered at FAT costs rework, retesting, and scheduling.
- Process control owns the intent. The controls engineer can identify an anomaly, but only the people who run the unit can confirm what a piece of logic is for. Build their review time into the plan.
- Inactive is not the same as unnecessary. Some spare points exist for a planned expansion. Require a documented basis for every retirement, in both directions.
- Write the rules down early. Conversion rules agreed in Phase 3 prevent the same debate from happening module by module across a large team.
- Measure what you can defend. Count findings, retirements, and hardware changes from the log. Do not report savings you cannot trace to a source.
Questions to ask before your next migration
☐ Is there an agreed baseline, with open questions logged rather than assumed away?
☐ Is every in-scope module reviewed against operational intent before conversion?
☐ Are findings classified, and do critical ones block implementation?
☐ Are conversion rules written down before engineers start converting?
☐ Are FAT/SAT acceptance criteria defined before implementation?
☐ Does the cutover plan include manual operation, rollback criteria, and a named decision-maker?
☐ Will lessons learned change the method for the next project?
