A brownfield facility is an existing, operational plant that contains machinery, control, electrical and software layers added during different periods over many years. Transforming automation in this environment is more difficult than building a new line because design freedom is limited, knowledge is fragmented and shutdown windows are short. Even when a legacy system appears to be working, spare-parts availability, cybersecurity, data access and dependence on individual specialists create growing risks.

The objective of a successful transformation is not to replace everything at once, but to give the operation new capabilities while reducing production risk in a controlled manner. This requires understanding existing behaviour, documenting critical dependencies, defining the target architecture and dividing the transition into small, verifiable steps. This guide explains how to manage a brownfield automation project from initial discovery through to stable operation.

The fundamental difference between brownfield and greenfield projects

In a greenfield project, the layout, control architecture, network, security and data model can be designed to a common standard from the outset. In a brownfield project, operating production, the existing building, legacy machines, proprietary protocols, missing source code and established operating practices define the design constraints. Disconnecting a single cable may stop another machine that does not appear in the documentation.

For this reason, the first principle of a brownfield approach should be “preserve behaviour first, then improve it”. Logic that appears incorrect or inefficient in the existing system may have been introduced years ago for quality or safety reasons. Removing a function without understanding its purpose can produce unexpected results during commissioning. In factory automation modernisation, field knowledge is just as valuable as expertise in new technology.

Define the business objective and success criteria

“Modernising the system” is not a business objective in itself. The project may aim to reduce the risk of unplanned downtime, improve cycle time, provide traceability, raise the safety level, make energy consumption visible or migrate away from unsupported hardware. Each objective must be linked to a measurable KPI.

For example, if availability is to increase from 94% to 97%, the definition of downtime, measurement source and baseline period must be specified. If data collection is required, the signals to be transferred to the higher-level system and their resolution must be documented. Ambiguous objectives cause scope to expand continuously; clear objectives make it possible to distinguish mandatory work from beneficial work and items that can be deferred to a later phase.

Technical inventory: record more than you can see

Discovery is not merely a list of PLC makes and models. Controllers, remote I/O, drives, HMIs, SCADA systems, industrial PCs, robots, weighing equipment, cameras, barcode readers, safety relays, network switches and field devices must be recorded together with their serial numbers, firmware, program versions, communication protocols and backup status. Electrical drawings must be compared with the physical installation.

For every asset, ask: “What happens if it stops, is a spare available, how long will recovery take, and who understands it?” This turns a basic equipment list into a criticality inventory. The existence of a backup program is not sufficient; it must be confirmed that the correct version can be opened and that the required engineering software and licence are available.

Analyse the existing process and control logic

If documentation is outdated, the real system must be understood through observation, trends and controlled tests. Record the machine's normal start-up and shutdown sequence, fault responses, manual mode, product changeover, recipe flow, safety stops and behaviour after a power failure. The workarounds used daily by operators and maintenance teams are particularly important.

The I/O signal list must be matched with the functional description. Where possible, use passive network monitoring and SCADA trends to map communications between devices. This work forms the basis of the acceptance scenarios for the new software. Every unknown behaviour returns as a risk during commissioning.

Conduct a risk and criticality analysis

Assets can be scored according to production, quality, safety, environmental impact and recovery time. Controllers that create a single point of failure, industrial PCs without backups, obsolete drives and applications with unavailable source code should receive priority. Not every device that is less than current is urgent; what matters is the impact of failure and the ability to recover.

The risk register should not be limited to technical issues. It must also cover a missed shutdown window, delayed product validation, lead times, the departure of a key specialist, temporary production plans and who has the authority to make a rollback decision. Each high risk must be assigned a preventive action, owner and deadline.

Design the target architecture in layers

The target architecture should separate the field, control, supervisory, operations and enterprise-system layers. Sensors and drives connect to controllers; PLCs connect to the HMI/SCADA layer; and production data connects to the MES or data platform through controlled interfaces. Network segmentation, time synchronisation, user management, backup and remote access are design inputs, not features to be added later.

Standardisation does not mean using a single brand. Tag structures, alarm classes, screen templates, program blocks, documentation, backup and change management can be standardised. A vendor-independent data model reduces the need to rewrite higher-level system integrations when a device is replaced in the future. OT cybersecurity requirements must also be addressed during the architecture phase.

Select the transformation strategy

Under a “rip and replace” approach, the legacy system is removed and the new one commissioned during a single shutdown. This can be practical for small, well-documented systems with a long shutdown window, but the rollback risk is high. In a phased migration, the line is divided into cells or functions and each section is validated independently. This is the safer method for most brownfield facilities.

With a parallel-operation approach, the new control or data layer runs alongside the legacy system for a period. In shadow mode, the new application makes decisions without controlling the field, and its results are compared with those of the existing system. Adapters or gateways can accelerate the transition, but a removal date must be set so that a temporary solution does not become permanent technical debt.

Select the right pilot area

The first pilot should be neither the easiest nor the most critical area. Select a cell that represents the core characteristics of the target architecture, delivers measurable value and has a manageable impact on production if a problem occurs. The pilot tests the technical standard, project method, training approach and acceptance documentation.

Lessons from the pilot must be incorporated into the subsequent rollout plan. Update the time required for cable labelling, the I/O validation method, operator-training needs, the backup procedure and the actual commissioning rate. A pilot should not close simply with the conclusion that “it worked”; it should produce a repeatable standard package.

The copy-and-paste trap in software transformation

Translating legacy PLC code line by line onto a new platform may appear to be a shortcut. However, bypasses, repetitions and ambiguous tags accumulated over the years are then carried into the new system. At the opposite extreme, rewriting everything from scratch without understanding current behaviour causes valuable production knowledge to be lost. The correct approach is to preserve functional behaviour while improving the software structure in a controlled manner.

Standard equipment modules, state machines, and alarm and interlock structures should be established. The corresponding legacy and new behaviour of every change must remain traceable. Source code should be held under version control; authorised changes, test records and restoration packages are all parts of the same process.

HMI and SCADA modernisation

A new screen should do more than look more colourful. Operators must be able to understand the normal state quickly, distinguish deviations and be guided towards the correct intervention. Colour should communicate alarm and status meaning, while animation should be used sparingly. Alarm floods should be reduced by reviewing alarm priorities, delays and suppression rules.

A SCADA transformation must account for historical-data migration, report continuity, user roles, electronic-record requirements and time synchronisation. Establishing a tag-naming and data-quality contract for software integration makes the commissioning of higher-level systems easier.

FAT, simulation and virtual commissioning

Every hour spent on site is expensive, so all feasible tests should be completed in advance. Cabinet power-up tests, I/O card checks, network configuration, program unit tests and HMI navigation should be validated during FAT. A simulator or digital model can be used to exercise start-up, shutdown, recipe, fault and safety scenarios.

Test scenarios must cover exceptions as thoroughly as normal production: what happens if a sensor remains active, communication is interrupted, a product is left midway through the process, power returns or an operator follows the wrong sequence? When errors are discovered off site, the shutdown window can be reserved for wiring and controlled validation.

Shutdown and cutover planning

The cutover plan should be prepared on an hour-by-hour basis. It must define when the final product will leave the line, when equipment will be made safe, who will verify backups, the removal and installation sequence, I/O tests, dry runs, tests with product, quality approval and handover to production. Every step must have a named owner and estimated duration.

Decision gates must be defined: if a particular result has not been achieved by a specified time, when will rollback begin? Legacy hardware, programs, cable markers and connection plans must be kept ready for rollback. A rollback plan is not an indication of failure; it is a discipline for maintaining production continuity. Communication channels among shift, maintenance, IT/OT, quality and supplier teams must be established in advance.

SAT, performance acceptance and ramp-up

A site acceptance test does not end when power is applied and signals are visible. Functional, cycle, quality, safety, alarm, authorisation, data, backup and recovery scenarios must be validated. Critical safety functions must be measured and documented by competent personnel. Tests with products must cover the actual product mix and boundary conditions.

A period of intensive support should be planned after production starts. Engineering and maintenance teams should remain on site during the first shifts, issues should be prioritised and a daily decision meeting should be held. Temporary adjustments must be distinguished from permanent corrections. Performance should be accepted against KPIs over an agreed period, not after only a few successful cycles.

Transforming people and knowledge

Roles change as technology is modernised. Operators must learn the new interface, maintenance teams the diagnostic tools, automation teams the software standard, and IT teams their network and backup responsibilities. Rather than a one-off presentation, training should include role-based theory, practical exercises and fault scenarios.

The knowledge held by employees familiar with the legacy system must be captured at the start of the project, but the new system must not remain dependent on a single person. Up-to-date electrical drawings, network diagrams, I/O lists, program backups, version records, parameter lists, and operating and maintenance instructions are mandatory deliverables.

Common brownfield-project mistakes

  • Assuming the documentation is correct without validating it on site.
  • Compressing the entire scope into one major shutdown without intermediate acceptance gates.
  • Rewriting code before understanding all behaviours of the legacy system.
  • Deferring networks, time synchronisation, users, backups and cybersecurity to a later phase.
  • Involving operators and maintenance teams only on the day of commissioning.
  • Failing to define the time, equipment and decision authority required for rollback.
  • Leaving temporary gateways and access routes in place after the project is complete.

A practical transformation roadmap

The first phase covers inventory, criticality, backup validation and urgent risk reduction. The second establishes the standard architecture, pilot and test infrastructure. In the third phase, lines are transformed in waves aligned with the production schedule. The final phase completes data utilisation, performance optimisation and the controlled retirement of legacy components.

Technical debt, benefits and the risk register must be updated at the end of every wave. This transforms the programme from a simple device-renewal exercise into a sustainable automation-management model. To obtain an independent assessment of your facility's current condition, you can begin with automation consulting and an on-site survey.

Frequently asked questions

When should a functioning PLC be replaced?

Age alone is not a decision criterion. Manufacturer support, spare-parts availability, a validated program backup, the impact of failure, cyber risk and integration requirements must be evaluated together. Highly critical devices with limited recovery capability take priority.

Can a transformation be completed without stopping production?

Some data and supervisory layers can be installed in parallel; changes to field wiring, control and safety usually require a planned shutdown. The objective is not to claim zero downtime, but to reduce downtime to short windows that have been tested in advance.

What is the first step in a brownfield project?

A validated technical inventory and criticality analysis. A sound roadmap cannot be created without knowing which asset controls what, whether a current backup exists and how recovery will be performed in the event of a failure.