DCS migration. Reconstructing current scope from P&IDs.

DCS migrations are among the most expensive controls projects an operating company runs. The new platform itself is a routine engineering exercise. What consumes the schedule is reconstructing the as-built scope of the legacy system from drawings, point lists, and conversations with operators who have been running the plant for fifteen years.

The discovery phase is the one that usually blows the migration schedule, and it is the one most worth starting on properly.

What "current scope" actually means

Migration teams talk about three datasets that should agree but never quite do.

1. The as-drafted scope. What the original P&IDs showed when the plant was commissioned. This dataset can be decades old. It represents the design intent, not the current operational reality.
2. The as-built scope. What is actually wired and running today. This is the dataset the migration needs to replicate on the new platform.
3. The DCS point list. What the legacy DCS thinks it has. Tag table, alarm configurations, control strategies. This drifts from the as-built whenever a field change is wired but not configured, or configured but not wired.

The migration plans against the as-built. Reconstructing the as-built from the drawings and the point list together is the discovery work.

The full migration playbook

A structured DCS migration runs through six phases. Discovery is the first. Skipping or compressing it forces rework in every subsequent phase.

Phase 1. Current-state extraction

Lock the controlled P&ID set. Whatever the operating company has registered as the controlled drawing for each unit should reflect field changes through the latest formal MOC. Scan them at 300 plus dpi if they are paper. Verify the drawing register against the plant area list. Missing drawings mean missing scope.

Build a structured drawing-side scope. Whatever method produces the tag list, the result is what the drawing says the plant has. Per-page metadata, signal class, equipment, loop number belongs in the structured dataset. Brownfield P&ID digitization handles the raster-to-structured-list conversion for scanned drawings. The full sequence from controlled drawing set to reconciled tag database is covered in the DCS migration guide.

Pull the legacy DCS point list as structured data. Most DCS systems export their tag table as CSV or can be queried via their system engineering tool.

The export always includes more columns than you need. Map at minimum. Tag name, description, signal type, engineering unit, alarm high, low, and control strategy, PID, ratio, cascade. These are the fields the new platform needs to replicate.

Phase 2. Gap analysis

Reconcile the drawing dataset against the point list tag-by-tag. The reconciliation produces four categories.

• **Match. ** tag exists in both drawing and point list, metadata consistent. These are the migration's seed records.
• **Drawing-only tag. ** tag appears on the P&ID but not in the DCS point list. May indicate a pre-commissioned or abandoned instrument. Walk the field to verify wiring status.
• **Point-list-only tag. ** tag exists in the DCS but not on any controlled drawing. Could be a field addition that never had a drawing update, common on plants older than 15 years, a soft tag, calculated or virtual point, or a ghost tag from decommissioned hardware that was never removed from the database.
• **Conflict. ** tag exists in both but metadata disagrees. Signal type mismatch, engineering unit mismatch, or description inconsistency. Each conflict needs an engineering decision before the new platform inherits it.

Ghost tags are the migration trap. A ghost tag that migrates to the new DCS will generate a persistent "transmitter not communicating" alarm from day one of operation. Walking the field to verify wiring is the only definitive test. Calibration records and loop folders are a starting point.

Phase 3. Tag-rename mapping

Migration is the natural moment to bring tags into compliance with the operating company's current naming convention. The legacy system may have grown conventions that diverge from the current ISA 5.1 standard or the owner's updated tag standard.

Produce a tag-rename map. Three columns, old tag, new tag, reason code. Reason codes. Renamed for ISA 5.1 compliance, area code update, unit expansion numbering, or correction of a historical error.

The rename map drives the new platform's tag table population. It also drives the as-built P&ID update, which is a coordinated MOC step at project handover. If the P&IDs are updated to match the new tags, the rename map is the link between old and new across all project documents, loop folders, calibration records, SRS.

Critical constraint. Every rename must be unique. Tag collisions in the new DCS, two old tags mapping to the same new tag cause commissioning failures that are painful to debug. Run a duplicate check on the new-tag column before accepting the rename map.

Phase 4. Loop-by-loop cutover planning

After the tag table is finalized, cutover sequencing is the engineering document that determines plant availability during migration.

Group loops by cutover unit. The standard approach is unit-by-unit, one process area at a time, with the migrating unit temporarily on manual control or isolated while its DCS scope cuts over. For a continuous process, this requires either a planned shutdown window or a phased approach where the new DCS runs in shadow mode alongside the legacy system.

Identify hard interlock dependencies. Some loops in one unit interlock with loops in another unit that is not yet migrated. These cross-unit dependencies must be resolved before the cutting unit goes live. List each dependency explicitly in the cutover plan.

Plan the tie-back period. During cutover, the migrating unit's instruments temporarily report to both the legacy DCS and the new platform, or to the new platform alone with manual backfill for critical setpoints. Define the tie-back duration per loop. How long can that loop run on manual before it must be on automatic control.

Define the hold, proceed criteria per loop. Before each loop goes to automatic on the new DCS, verify. Transmitter signal reading matches expectation, control output within range, alarms configured and armed. The loop-check procedure references the new tag table directly. A structured instrument index per unit, derived from the migrated tag table, is the commissioning document for this step.

Phase 5. MOC documentation

The migration is a significant change to the control system. IEC 61511 and most operating company safety management systems require a management of change record covering.

• Scope of change, tag list, drawing revision numbers, PLC, DCS software version changes
• Risk assessment, including any changes to SIS scope or safety function timing
• Pre-startup safety review, PSSR checklist
• Commissioning sign-off per loop

The drawing-extracted dataset plus the tag-rename map plus the cutover plan form the input package for the MOC. On large migrations, hundreds of loops, the MOC package is substantial. Plan for the documentation effort as part of the project schedule, not as an afterthought.

Phase 6. Commissioning hand-off

The new DCS vendor's commissioning team needs.

• Final tag table, new tags, signal types, EU ranges, alarm setpoints
• Controller strategy, PID tuning parameters, cascade configurations, ratio factors from the legacy system
• Loop-check checklists indexed to new tags
• Alarm philosophy document, alarm priorities, inhibit groups, trip setpoints

The tag table and alarm setpoints come from the reconciled discovery dataset. PID tuning parameters come from the legacy DCS export or from the engineers who tuned the loops. Alarm setpoints in the legacy DCS may not match the SRS. Flag discrepancies for engineering review before they migrate to the new platform.

Common patterns

SIS scope that lived inside the legacy DCS. Older DCS systems sometimes ran safety logic alongside regulatory control. Modern IEC 61511, ISA 84 requires physical separation. Migration is the natural moment to extract SIS scope into a separate logic solver, typically Triconex or an equivalent SIL-rated platform. The drawing-extracted dataset, filtered by SIS-prefix tags, gives you the SIS scope register.

Tag-renaming opportunities. The legacy DCS may have grown house conventions that diverge from the operating company's current tag standard. Migration is the moment to bring tags into compliance. The drawing-extracted dataset preserves the as-drawn tag. The migration register tracks the rename. Updating the drawing legend to match is a coordinated MOC step at handover.

Configuration drift in alarm thresholds. Alarm setpoints in the legacy DCS may not match what the SRS or the original commissioning record specified. Migration discovery surfaces these. Some are intentional operational adjustments, some are forgotten one-off changes. Each gets settled before the new platform inherits them.

Vendor migration patterns

The discovery method is the same regardless of the legacy or target platform. What differs is the tag-table structure on the new side and the export shape on the legacy side. Notes on the eight platforms that appear most often in migration projects.

DeltaV to Experion

Emerson DeltaV organizes its database by module and parameter path, e.g. UNIT01/FIC-101/PV. Honeywell Experion uses a point-and-parameter model with different naming constraints. The migration map needs to resolve DeltaV module names to Experion point names. DeltaV allows longer tag strings than some versions of Experion's legacy TPS conventions. Check the target platform's tag-length limit before generating the rename map.

CENTUM to PCS7

Yokogawa CENTUM VP tags use a station, tag convention. Siemens PCS7 uses an area, unit, module hierarchy. The CENTUM station maps roughly to the PCS7 area. CENTUM tags map to PCS7 module instances. The rename map needs to assign each CENTUM tag a PCS7 area prefix to fit the hierarchy. PCS7's SFC, Sequential Function Chart is the target for CENTUM's sequence logic. This translation is the most labor-intensive part of a CENTUM to PCS7 migration and is not covered by a simple tag table conversion.

I/A Series, Foxboro to 800xA

Foxboro Evo (I/A Series) uses compound and block naming for control strategies. ABB 800xA uses an aspect-object structure. The migration team must map each I/A Series compound to an 800xA object type. The discovery phase collects the compound list from the I, A export. The engineering phase maps compounds to 800xA templates before the tag table is built.

PlantPAx migration, legacy Rockwell to current PlantPAx

Older Rockwell PlantPAx systems on ControlLogix may be running pre-v4 PlantPAx libraries. Migration to PlantPAx v5 or later involves library tag structure changes in addition to any hardware changes. The tag table migration must account for the new PIDE and ALMA object structures if the add-on instructions are being updated. Extraction from the legacy Studio 5000 project file gives the existing tag table. The migration map resolves old tags to new PlantPAx object names.

Why drawing-side extraction matters more than point-list mining

It is tempting to run the migration purely from the legacy DCS point list because it is already structured data. The trap. The point list cannot tell you what is wired in the field. A tag that exists in the DCS but no longer wires to a transmitter is a ghost tag. The migration team that does not catch it programs the new DCS to expect a signal that will never arrive.

Drawing-side extraction is the ground truth. The drawing shows what is wired. The DCS point list shows what is configured. The migration's reconciled dataset is the intersection plus the documented exceptions in either direction.

Upload the controlled P&ID set and the comparison output drops into Excel. Triage still needs engineering judgment. The discovery work compresses from a forensic spreadsheet exercise into an engineering review of a reconciled dataset.

Related

• Brownfield P&ID digitization. Getting scanned drawings into a structured form for discovery
• Extract instruments from a P&ID. Produces the drawing-side dataset directly
• Lifecycle: FEED. Where migration scope is first formally defined
• Lifecycle: commissioning. Where the cutover plan executes
• Emerson DeltaV platform notes
• Honeywell Experion platform notes
• Yokogawa CENTUM platform notes
• Siemens PCS7 platform notes

FAQ

Why does DCS migration scope reconstruction take so long.

Three reasons compound. The legacy DCS point list has drifted from the P&IDs over a decade-plus of operation. Tribal knowledge about which loops are critical or experimentally configured lives in the heads of operators who are not always on the migration team. The new platform vendor wants their tag table populated against a clean baseline, not against a list that disagrees with the drawings.

Can the migration start before the as-built is finalized.

Yes if the migration is partial. One unit at a time, leaving the rest on the legacy DCS. The migrating unit's scope can be locked while other units stay in operation. Full-plant migrations need the as-built locked before the new platform's tag table is finalized.

Why is drawing-side extraction better than mining the legacy point list.

The point list cannot tell you what is wired in the field. A tag that exists in the DCS but no longer wires to a transmitter is a ghost tag. The drawing is the ground truth. The point list is the configuration view. The migration scope is the reconciliation of the two.

How do we handle loops where the legacy DCS tuning has drifted far from the original design.

Document the current DCS tuning parameters, P, I, D, setpoint, output limits from the legacy system export. These are the actual operating values, regardless of what the original SRS specified. Migrate the current values to the new platform and flag any that deviate significantly from the SRS for engineering review. Do not migrate the SRS values and expect the plant to behave as before. The operators have tuned around decades of fouling, equipment wear, and process changes.

What is the minimum documentation set for an IEC 61511-compliant migration MOC.

At minimum. A scope-of-change document listing every modified SIS function tag, a risk assessment confirming no increase in process risk from the migration, a validation plan for each migrated SIS function, and a pre-startup safety review, PSSR sign-off. Most operating companies have a specific MOC form that covers these. Use their form rather than a generic template. The SIS-specific documentation is additive to the general MOC, not a substitute for it.