1
Lifecycle assessment sets the timing, not the failure
An obsolescence and lifecycle review tells you how exposed each system is before a card failure forces an unplanned outage. Planning early keeps the shutdown window under the site's control.
Planning an automation upgrade on a live Australian plant is a different exercise from a new build. The existing controls keep production running, the available shutdown windows are short, and any change has to fit around equipment that may no longer match its drawings. The goal of planning is to modernise the control system without introducing new risk and without surrendering the choice of when the line goes down. Most upgrades begin not because the site wants new features, but because the supportability of the existing platform is thinning out: spares are harder to source, the programming software runs on one ageing PC, and a single card failure would turn a routine repair into a multi-day recovery.
This guide sets out how to assess obsolescence and lifecycle exposure, rank the risk, choose between a phased and a big-bang approach, work within brownfield constraints, hold spares and standards continuity together, and stage the work so it can be justified and approved. For delivery support, Metromotion Controls covers this work through automation upgrades and PLC, SCADA and HMI programming.
Start with an obsolescence and lifecycle assessment
The first question is not what to buy but how exposed the plant already is. A lifecycle assessment maps every significant control asset against its manufacturer lifecycle status and the practical consequence of its failure. Most major vendors publish a lifecycle classification for their products, typically running through active, mature or classic, end of life, and discontinued. Rockwell Automation, for example, frames modernisation around exactly this status, encouraging sites to plan a migration while a platform is still serviceable rather than after it is retired (Rockwell Automation, modernisation).
For each asset, record three things:
- Lifecycle status. Where the controller, I/O, drives, HMIs, and networks sit in the vendor lifecycle, and the published or expected end-of-support date.
- Spares reality. Whether a failed unit can be sourced from the vendor, from authorised channels, or only from the grey market and refurbishment trade where pricing and reliability are unpredictable.
- Failure consequence. What a single failure does to production, and how long recovery realistically takes given current spares and knowledge.
The output is a ranked picture of risk. A controller that is still supported with healthy spares and a low failure consequence can wait. A discontinued processor whose only spare is the card already running in the rack has crossed into planning territory, regardless of how reliably it has run so far. The point of assessing lifecycle early is that support risk arrives years before the hardware stops working, and that gap is the window in which the site can still control the shutdown.
Audit the existing plant before scoping
A lifecycle assessment tells you what is exposed; an asset audit tells you what is actually installed. The two are different, because the field rarely matches the records. The audit is a systematic walk-down of control hardware, field devices, electrical infrastructure, networks, and documentation, and it underpins everything that follows. Scoping an upgrade without a real audit means scoping against assumptions, and assumptions are where brownfield projects overrun.
A useful audit captures:
- What exists. PLC models and firmware versions, I/O counts and types, network topology, panel condition, drive platforms, and the age and type of field instruments.
- What is at risk. End-of-life hardware, obsolete communications such as legacy serial or proprietary networks, undocumented modifications, and devices that no longer match the drawings.
- What the plant needs. Known operational faults, missing functionality, the daily workarounds the shift team lives with, and any regulatory or safety obligation the current system does not meet.
The most common source of cost overrun on a brownfield upgrade is hidden complexity discovered during installation rather than during design. Undocumented serial links to packaged equipment, hand-modified ladder logic, and P&IDs that no longer reflect the field are the usual culprits. A thorough audit, often supported by systems integration discovery work, is the most effective way to bring that risk forward into the design phase where it is cheaper to resolve.
Risk assessment across production, safety, and data
Once the plant is mapped, the risk assessment turns it into a priority order. It is worth separating risk into three views, because they rank the same equipment differently.
| Risk view | What it asks | What it ranks first |
|---|---|---|
| Production continuity | What happens to output if this fails? | Bottleneck lines, single points of failure, long-recovery assets |
| Safety | Does this system carry a safety function? | Interlocks, guarding, emergency stop and trip systems |
| Data and compliance | Does this hold records or traceability we must keep? | Historians, batch records, alarm logs, regulatory data |
Where a system carries a safety function, the upgrade falls under the functional safety lifecycle, and the assessment should establish the required safety integrity level before any design choices are locked in. The relevant standards are IEC 61508 for the general functional safety lifecycle and IEC 61511 for the process sector, and both treat modification of a safety system as a lifecycle event that has to be assessed rather than a like-for-like swap. Metromotion Controls handles this scope through functional safety work, and the detail is covered further in our guide to SIL assessment in Australia.
The risk assessment is what justifies the staging order later. A line that is both a production bottleneck and running discontinued hardware ranks above a well-supported line with spare capacity, even if both are technically due for modernisation.
Phased versus big-bang cutover
The central planning decision on a live plant is how to cut over. The two ends of the spectrum are a phased migration, where the plant is upgraded section by section, and a big-bang cutover, where the whole system changes in one outage.
| Approach | When it suits | Main risk |
|---|---|---|
| Phased | Most live brownfield plants with ongoing production | Higher total engineering hours; needs interfaces for old and new to coexist |
| Big-bang | Tightly interlocked systems, or an existing major planned shutdown | All risk concentrated in one cutover event; rollback is costly |
A phased approach divides the upgrade into logical sections by area, line, or system. Each stage has its own design, factory acceptance test, cutover, and handback, and the unaffected areas keep running on the existing controls throughout. The trade-off is that the site temporarily carries two platforms, and the design has to provide a clean interface between them, often a gateway or a mapped data exchange so the new and legacy systems can pass interlocks and status across the boundary during the transition.
A big-bang cutover avoids the cost and complexity of running two platforms in parallel, but it concentrates all the risk in a single event with an expensive rollback. It is the right choice when the plant cannot be split cleanly, for example a continuous process with interlocks that span the whole line, or when the site already has a long planned shutdown such as an annual maintenance window that can absorb the work. For most discrete and batch plants, phased migration is the lower-risk default, which is why it is the usual recommendation for live sites in our legacy PLC migration guide.
A worked example: phasing an ageing line
The following sequence is illustrative. The numbers are typical engineering planning figures used to show how a phased upgrade is staged, not a result from any specific project. Consider an ageing packaging and filling line running a discontinued processor with mixed legacy I/O, a single ageing operator HMI, and a serial link to a packaged labeller.
Stage 0, discovery and design (allow 4 to 6 weeks). Complete the audit, confirm the I/O count, document the serial link to the labeller, recover or rebuild the P&ID and I/O lists, and fix the target platform and tag naming standard. Define the staging order from the risk assessment.
Stage 1, network and visualisation (no production outage). Stand up the new control network and a new SCADA or HMI alongside the existing system, reading from the legacy controller through a gateway. This delivers improved visibility and a historian early, proves the network, and gives operators time on the new interface before any controller changes. A typical allowance here is 3 to 5 days of on-site work spread across normal running.
Stage 2, controller migration on a planned shutdown (one weekend window). With the converted program already proven against simulated I/O in factory acceptance testing, swap the processor and migrate the I/O during a single planned outage. A wiring conversion approach keeps field re-termination short. Verify I/O point by point, run the site acceptance test, and sequence the restart deliberately to avoid pressure surges on transfer lines.
Stage 3, packaged equipment and data continuity (no production outage). Re-point the labeller interface to the new controller, confirm the historian and batch records are flowing into the new system, and decommission the legacy HMI once operators are confident on the new one.
The value of this shape is that the riskiest single event, the controller swap, is isolated to one short window, fully rehearsed, and surrounded by stages that carry no production outage at all. Each stage delivers standalone value, which also makes the spend easier to approve in increments.
Brownfield constraints, spares, and support continuity
A live site imposes constraints that a greenfield design never faces, and they shape the plan more than the technology choice does.
Shutdown windows. The available outage time is usually fixed by production, not by the project. Planning works backward from the window: what can be proven off-line beforehand, what must happen during the outage, and what can be completed afterward with the line running.
Documentation condition. The cleaner the input documentation, the faster and cheaper the upgrade. Current electrical drawings, PLC program backups with version history, I/O lists that match the field, and a written record of known faults are the ideal inputs. Sites that cannot provide these should budget time at the start of the project to recover them, because that recovery is real work that has to happen somewhere.
Spares through the transition. During a phased upgrade the site temporarily holds two platforms, so the spares plan has to cover the legacy hardware still in service and the new standard at the same time, with a defined retirement date for the old holdings. The longer-term aim is standardisation: when every line eventually runs the same controller family, I/O range, and drive platform, the shared spares pool shrinks and the depth of in-house knowledge grows. Standardising the platform is one of the clearest ongoing benefits of a planned upgrade, and it is worth letting it influence the platform choice from the start.
Support arrangements. Settle who holds the program backups, who can attend a breakdown, and what the recovery path is before the first cutover. Post-start support should be locked in before the outage begins, not arranged after a problem appears. Metromotion Controls provides this cover through ongoing support once a line is migrated.
Data and standards continuity
An upgrade that loses the plant's accumulated records or breaks its conventions creates a different kind of cost. Continuity has to be designed in.
On the data side, the items to carry forward are the historian record, batch and production reports, alarm history, and any traceability data the site is obliged to keep. A common and worthwhile pattern is to stand up the new historian early, as in Stage 1 of the worked example, so that a continuous record exists across the cutover rather than a gap. Tag naming and alarm philosophy should be standardised as part of the design, because a consistent tag standard is what lets later stages and future lines integrate cleanly. The principle of a structured, prioritised alarm system is set out in the widely used alarm management standard ISA-18.2 (ISA, standards), and an upgrade is the natural point to bring an older, flat alarm scheme into line with it.
On the standards side, the governing Australian and international standards have to be confirmed and applied to the relevant part of the scope. The electrical installation work follows AS/NZS 3000, the Wiring Rules, available through Standards Australia (Standards Australia). Any control panel built or modified during the upgrade falls under AS/NZS 61439 for low-voltage switchgear and controlgear assemblies, which is the relevant standard for the control panel engineering scope. Where the network is being rebuilt, an upgrade is also the right time to bring the OT network onto a current, segmented design rather than carrying forward a flat legacy topology.
Common mistakes to avoid
A few pitfalls recur often enough to be worth naming directly.
- Scoping from the drawings instead of the field. Trusting as-built documentation that has not been verified on site is the most common root cause of overrun. The field almost always differs from the records.
- Underestimating code conversion. An automated converter produces a faithful structural starting point, not a finished program. Analogue scaling, block-transfer handling, timing assumptions, and indirect addressing all need manual review before the converted code is trustworthy on a live line.
- Treating the restart as an electrical event. Re-energising pumps, valves, and drives in the wrong order can cause pressure surges and water hammer that damage pipework and instruments. The restart sequence is engineering, not a step left to whoever is on shift, a point covered further in our note on pump control and water hammer.
- Ignoring the packaged equipment. Third-party skids, labellers, and OEM units with their own controllers and serial links are routinely missed in discovery and then discovered during the outage. They belong in the audit and in the factory acceptance test scope.
- No rollback per stage. A cutover without defined go/no-go gates and a written rollback at each one leaves the line able to reach an undefined state. Every stage should have a known position to return to and a clear point of no return once legacy hardware is removed.
The Australian context
Automation upgrades in Australia sit inside a clear regulatory and standards framework, and the relevant parts have to be confirmed during discovery rather than at the outage.
The safety of the work itself is governed by the model Work Health and Safety laws, administered nationally by Safe Work Australia and enacted by the state and territory regulators. Their guidance on managing the risks of plant covers isolation and energy control during maintenance and modification, including lockout and tagout of electrical, pneumatic, hydraulic, and stored energy before anyone works on the equipment (Safe Work Australia, managing the risks of plant). Energy isolation should be planned into the cutover sequence as a designed step.
The electrical scope is framed by AS/NZS 3000 for the installation work and AS/NZS 61439 for any switchboard or control panel work. Where the upgrade touches a safety function, the functional safety lifecycle under IEC 61508 and the process-sector standard IEC 61511 apply, and a modification is treated as a lifecycle activity in its own right. For acceptance testing, IEC 62381 provides a common industry framework for how factory acceptance, site acceptance, and site integration tests are structured and recorded (IEC 62381). Working to a recognised structure keeps the test scope, pass criteria, and sign-off consistent, which matters most when several parties share responsibility for a cutover.
For local manufacturers in sectors such as food and beverage and dairy, sector hygiene and traceability obligations sit on top of this framework, which is another reason data continuity through the upgrade has to be planned rather than reconciled afterward.
Bringing the plan together
A sound upgrade plan starts from a lifecycle assessment, is grounded in a real audit rather than the drawings, and is staged in an order that the risk assessment justifies. For most live Australian plants a phased cutover keeps production running while spreading both the risk and the capital spend, with the riskiest single event isolated to a short, well-rehearsed window. Spares, support, data, and standards continuity are design inputs from the start, not loose ends to tidy after handback. Planned with enough lead time, an upgrade keeps the shutdown window, and the risk, under the site's control rather than a failure's.
References
- Rockwell Automation, Modernization, lifecycle status and migration planning guidance: https://www.rockwellautomation.com/en-us/capabilities/industrial-maintenance-support/modernization.html
- ISA, International Society of Automation standards (including ISA-18.2 alarm management): https://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees
- IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems: https://en.wikipedia.org/wiki/IEC_61508
- IEC 62381, Automation systems in the process industry: Factory acceptance test (FAT), site acceptance test (SAT), and site integration test (SIT): https://webstore.iec.ch/en/publication/67572
- Safe Work Australia, Managing the risks of plant in the workplace: https://www.safeworkaustralia.gov.au/safety-topic/managing-health-and-safety/plant
- Standards Australia, AS/NZS 3000 Wiring Rules and AS/NZS 61439 switchgear assemblies: https://www.standards.org.au/