DCS migration. Scoping the controls work from drawings
4200 tags. Three controllers. Six months to cutover. The first document the integration contractor asks for is the I/O inventory, broken down by signal class and system. The first delay is usually tracing where that inventory comes from, because the existing DCS documentation and the current P&IDs have been drifting apart for fifteen years.
Read one of your own drawings.
Drop a P&ID, instrument index, or schedule. Tagsight reads it to the tag and opens a workspace you keep when you sign in.
PDF · DWG · DXF · TIFF · PNG · XLSX
Why migrations fail at the inventory.
DCS migrations fail in three places. The I/O inventory was wrong, the loop logic carry-over missed cases, and the cutover plan did not account for what was actually in the field. The first failure mode is by far the most common, and it is the cheapest to prevent.
The inventory is the count of every signal that has to land on the new system. Every AI, AO, DI, DO, every Foundation Fieldbus segment, every Profibus address, every Modbus link to a vendor PLC. A wrong count on a 4000-tag plant means missed signals. Each missed signal is a panel modification, a cable pull, a software change, and a re-test. In the cutover phase, the consequences of those gaps add up fast.
The inventory is also the basis for almost every downstream estimate. Module count drives panel count. Panel count drives footprint. Footprint drives cabinet room space. Cabinet room space drives civil and HVAC. Loop count drives configuration effort. Configuration effort drives the labor estimate. A wrong inventory is a wrong project.
What the inventory must contain.
Tag, signal class, AI, AO, DI, DO and the F&G, SIS variants, connected equipment, line, current loop ID, signal type, 4-20mA, HART, Foundation Fieldbus, Profibus PA, hardwired DI, current panel and termination, current PLC, DCS controller and slot, channel, fail-safe state, and any safety-rating, SIL level if SIS, F&G class if F&G.
The current panel, termination and current controller assignment are what the existing system knows. The new system has to land each signal somewhere, and the from-and-to mapping is what the cutover team works from.
The safety-rating column is the most often missed. SIS tags in some legacy installations are not visually distinguished from BPCS tags on the same P&ID. The only way to identify them is by cross-reference to the SIS logic or the cause-and-effect matrix. A migration that drops SIS tags into a non-SIS controller is a recordable safety event.
From P&ID to module allocation.
Once the inventory is solid, module allocation is mechanical. Group AI tags into 8 or 16-channel cards. Group AO tags. Same for DI and DO. The constraint is usually power dissipation per card and area-grouping discipline, do not put one tag from area 200 on a card otherwise serving area 100.
A workable allocation pass starts from the inventory grouped by area and signal class, then assigns cards with a 20 percent spare capacity per card type. Spare capacity is the buffer for changes during construction. Less than 20 percent and you will repeatedly run out and need a card swap. More than 30 percent and the panel cost climbs unnecessarily.
Foundation Fieldbus and Profibus PA segments need separate planning. Each segment supports a finite number of devices, typically 8 to 16 depending on power budget and a maximum cable length. Allocate by area first, then by segment, then by device.
HART instruments are AI tags but carry digital diagnostics. Verify that the chosen AI cards are HART-pass-through capable if the project intends to read HART data. Not all are.
Loop mapping and configuration carry-over.
Each control loop on the existing system has to land on the new system with the same logic. PID gains, derivative filters, output rate limits, alarm priorities, interlock conditions. The carry-over from the legacy system is partly a configuration export, partly a re-build from the loop diagrams.
Legacy DCS configurations exported as native files, Honeywell EBR, Yokogawa TPS, ABB BCV are the cleanest input. Where the export is not available or the new system is too different, the loop diagrams plus the cause-and-effect matrices are the source. The I/O list cross-references the loop and the cause-and-effect, so a tag-by-tag walk is feasible.
The trap is the configuration drift that happens over the life of the legacy system. Operators and engineers have made tuning changes over fifteen years. The latest legacy configuration is the source of truth, not the loop diagrams from 2008. Verify against the running system, not the design documents.
SIS separation, before you forget.
Process safety in modern installations runs on a separate controller, Triconex, HIMA, ICS Triplex, ProSafe-RS, Yokogawa ProSafe, Honeywell SafetyManager from the BPCS. The controllers are physically and logically distinct. Tags on the SIS are SIL-rated, follow IEC 61511, and trip the plant when the demand is real.
Migrating SIS tags into a BPCS controller violates the separation principle and breaks the safety case. Migrating BPCS tags into an SIS controller wastes SIL-rated I/O.
Identifying SIS tags requires the cause-and-effect matrix or the SIS logic diagrams. P&IDs sometimes mark SIS tags with a color or a callout, and sometimes do not. A safe migration treats every PSL, PSH, LSL, LSH, TSH, TSL as a candidate SIS tag until proven BPCS, not the other way around. The default-to-safe assumption is the right policy.
F&G, fire and gas tags are usually on yet another controller, often a third panel system. The same separation rules apply.
Vendor packages and serial links.
Vendor packages, compressors, fired heaters, cooling tower chemistry, pump packages usually ship with their own PLC. The package PLC handles its own internal control. The plant DCS sees a digital communication link to the package. Modbus TCP, Ethernet, IP, Profinet, sometimes Foundation Fieldbus HSE, sometimes serial Modbus over RS-485.
The inventory has to capture each link as a row. Tag, link protocol, link address, and the data points exchanged across the link. The data points may number from a handful to several hundred per package. They become OPC tags or function-block inputs on the new DCS.
The migration risk on packages is that the new DCS speaks a different industrial protocol than the legacy DCS. A Modbus TCP package that worked with the old system can usually be re-pointed to the new system. A Foundation Fieldbus HSE package may need a gateway. A proprietary protocol, some HVAC vendors, some safety vendors may need replacement of the gateway hardware.
List every package with its protocol and its data-point count up front. Do not discover the gateway problem at site acceptance.
Cutover planning from the inventory.
Cutover is the multi-day or multi-week window where the legacy DCS is taken out of service and the new DCS is brought in. The plant is either down or running on bypasses. The window is expensive, and overruns are very expensive.
The inventory is the basis of the cutover sequence. Group tags by panel, by area, by criticality. Plan the order of disconnection from the old system and connection to the new system. Identify the bypasses or the manual operations that cover each tag during its transition window.
Pre-cutover bench testing of every loop on the new system reduces site time. Loop check sheets, generated from the inventory, become the field punch list during cutover. Each sheet shows the from-and-to, the test signals to inject, and the expected response.
A cutover plan that does not start from a verified inventory is a plan that will run long.
Returning the as-built to engineering.
After cutover, the as-built drawings need to reflect the new system. New panel drawings, new loop diagrams, new I/O assignments on the P&IDs, where shown. The work is partly mechanical and partly review.
The most-frequent oversight is the failure to update the P&IDs themselves. The instrument bubbles do not change, the field instrument is the same, but the controller designation often does. A migration from Honeywell to Emerson is invisible at the field but very visible in the title block, the panel reference, and the instrument-tag suffix in some conventions.
A workable as-built process re-extracts the new drawing set, diffs against the pre-migration drawing set, and confirms that every change is intentional. Differences that are not deliberate are mistakes. Deliberate differences are the migration scope. The diff itself is the artifact that the operations team inherits.
Downloads.
FAQ.
What does a DCS migration inventory cost in labor terms.
On a 4000-tag plant, a manual inventory build is two to four senior controls engineer-weeks if the documentation is reasonable. Twice that on a brownfield site with messy documentation. Automated extraction off the P&IDs and the legacy DCS configuration cuts the senior-engineer time to days, with most of the remaining hours spent on review and SIS classification.
How do I find the SIS tags in a legacy P&ID.
The cause-and-effect matrix is the most reliable source. Every safety function lists its inputs, sensors and outputs, actuators. Those are the SIS tags. The P&IDs sometimes use a color or callout for SIS tags but the convention varies. Default to treating safety-style tags, PSL, PSH, LSL, LSH, gas detectors as candidate SIS until cross-referenced.
Can I migrate Foundation Fieldbus segments as-is.
Usually yes, if the new DCS supports Foundation Fieldbus H1 cards. The segment cabling and devices stay. The H1 card on the new DCS replaces the one on the old. Configuration is re-done because the function block locations move from the old DCS to the new.
How much spare capacity should I plan per I/O card.
Twenty percent is a working default for new construction. For a migration where the field is fixed, the spare can be lower because the future changes are smaller. Some projects run at half the new-construction reserve. A few owners specify 30 percent on greenfield to handle multi-year creep.
What is the cutover risk I should pay most attention to.
Hidden serial links to vendor packages. Every Modbus, Profibus, or proprietary link is a potential cutover surprise. Catalog them in the inventory phase and bench-test the gateways before site acceptance, not during cutover.
How do I handle motor I/O during migration.
Each motor contributes a small bundle of I/O, run command, run feedback, fault, optional speed reference and feedback. Re-create the bundle on the new system. The motor itself does not move. The relay logic and the variable frequency drive interfaces are what get reconfigured.
What about tuning data.
PID gains and filter constants from the legacy DCS are the starting point on the new DCS. Most migrations re-tune during commissioning, but the legacy values are the safe initial conditions. Capture them as part of the configuration export.
Do I need to update P&IDs after migration.
Yes, when the migration changes anything visible on the P&ID. Controller designations, panel references, and any added or removed instruments all require P&ID revision. Field instruments that are unchanged do not require P&ID changes, but the title block revision and the engineering data block usually do.
What about HMI graphics.
HMI graphics are a separate workstream from the I/O migration but they share the inventory. The tag list feeds the graphics builder. The loop list feeds the standard graphic templates. Graphics development is typically the longest-duration activity in a migration project.
How do I price a migration off the inventory.
Per-tag rates by class are common. AI, AO costs more than DI, DO because of cabling and termination work. SIS tags cost more than BPCS because of the SIL verification overhead. Add a fixed cost per panel for the panel build, a fixed cost per controller for the controller build, and a percentage for project management and engineering review.
What documentation should I retain from the legacy system.
Configuration export, panel drawings, loop diagrams, cause-and-effect, and the alarm rationalization records. The legacy panel drawings are the as-built record that proves what was there before. They belong in the MOC package and the operations turnover.
When is migration the wrong answer.
When the controllers can be supported indefinitely with parts and engineering. Some legacy DCS platforms have third-party support that extends life by another decade. The trigger for migration is usually obsolescence, parts unavailable, capability gap, cannot support a new business need, or risk, cyber posture not viable. Migration for its own sake is rarely justified.