What if the greatest risk in a PLC migration is not the new hardware, but the assumptions made before cutover? For mission-critical infrastructure, PLC migration project management must address operational downtime, the specialist knowledge needed to work with legacy Siemens S5 systems and the gap between RIBA design stages and practical automation engineering.
A zero-downtime outcome may be desirable, but it cannot be assumed. It depends on the existing system, operating constraints and a carefully planned transition. A migration is more than a hardware replacement: it is an opportunity to document the control architecture, manage risk and make informed decisions about its future.
This article sets out a structured approach to building a documented, low-risk migration roadmap, from early RIBA-aligned design through engineering, testing and cutover planning. It also considers how to account for IEC/BS 61499 requirements and develop the control architecture, rather than simply reproducing legacy arrangements. Drawing on specialist experience in Siemens S5 to S7 migration and control systems design from RIBA Stage 1 to Stage 5, AAC LTD | All About Control explains how disciplined project management can align design intent with the realities of mission-critical operations.
Key Takeaways
- Use PLC migration project management to turn an ageing control system upgrade into a planned modernisation programme, rather than waiting for obsolescence to dictate the timing.
- Map automation engineering deliverables to RIBA Stages 1 to 5 so design intent, technical decisions and project responsibilities remain aligned.
- Assess failure modes and operational constraints before cutover, then determine whether staged commissioning or a parallel run could reduce disruption.
- Consider IEC 61499 when shaping a distributed control architecture, while confirming how the standard fits the project’s requirements and existing systems.
- Seek engineering and consultancy expertise that spans the project lifecycle, particularly when planning a Siemens S5 to S7 migration.
The Strategic Imperative for PLC Migration Project Management in 2026
In airport operational technology, a legacy PLC can become a constraint well beyond its control cabinet. If system knowledge is concentrated among a shrinking pool of specialists, or replacement components are difficult to source, routine faults may take longer to diagnose and recovery planning becomes less certain. Across baggage handling and airside systems, that uncertainty matters: a disruption may affect connected processes, operational schedules and the teams responsible for maintaining safe, reliable service.
Continuing to patch an ageing installation may seem less disruptive than modernisation, but it can preserve technical debt rather than reduce it. Each temporary fix adds to the work needed to understand, test and support the system. Effective PLC migration project management makes the change a planned programme. First, establish the asset condition and operational dependencies. Then document control behaviour, identify gaps in specialist knowledge and agree how migration risk will be assessed before scheduling cutover.
Addressing the Siemens S5 Obsolescence Risk
Ageing hardware can be vulnerable to component failure, while incomplete records or limited access to legacy expertise can make faults harder to isolate. Patching may address an immediate symptom, but it cannot by itself resolve parts availability, supportability or architectural limitations. A migration plan should distinguish short-term risk controls from the longer-term route to a supportable system. For further technical context, see this guide to Siemens S5 to S7 migration.
The Business Case for Modernisation
Build the business case around operational exposure, not an assumed industry-wide downtime figure. For a baggage handling or airside system, identify the processes affected by a control failure, the duration and consequences of interruption, available fallback arrangements and the resources needed for recovery. This gives stakeholders a project-specific basis for comparing planned migration with the risks of continued reactive maintenance, without treating an unverified cost estimate as a forecast.
Modernisation can also support better operational visibility. Where a redesigned control system makes more useful data available through SCADA integration, teams can assess system behaviour in greater context and use that insight to inform maintenance and operational decisions. The value depends on the engineering and the needs of the site, not simply on installing new hardware.
Plan for evolution, not a guaranteed service life. Assess a future-ready architecture against integration needs, maintainability and the organisation’s digital transformation and sustainability objectives, including opportunities to use operational data to identify inefficiencies. Distributed control concepts described in IEC 61499 standards may inform architectural choices, but their suitability should be tested against project requirements. A phased, documented roadmap helps balance current reliability needs with future options.
Structured Methodology: Aligning PLC Migration with RIBA Design Stages
A control system migration can fall short of its objectives before any code is written if the brief, operational needs and design responsibilities are not aligned. PLC migration project management benefits from a structured framework that connects early decisions to engineering deliverables and site commissioning. RIBA Stages 1 to 5 offer a useful sequence, provided they are applied to the project’s automation requirements rather than treated as a substitute for detailed engineering.
At each milestone, stakeholders should be able to see what has been decided, what evidence supports that decision and what remains unresolved before the project proceeds. This makes the transition from concept to live operation more controlled, particularly where airport systems have site-specific interfaces and tight operational constraints.
From RIBA Stage 1 to Stage 3
During Stage 1, establish the strategic brief: define the control system’s purpose, operational dependencies, constraints and desired outcomes. Assess the existing architecture and available records, and identify uncertainties that could affect scope or migration planning. In Stage 2, translate the brief into a concept that stakeholders can review before detailed design begins.
By Stage 3, develop the concept into coordinated requirements, including a functional requirements specification (FRS) that describes expected system behaviour, interfaces, alarms and operating modes. Agreeing these requirements with engineering, operations and other relevant stakeholders helps prevent a gap between design intent and the software eventually developed. It also gives the project a clear basis for managing changes.
RIBA Stage 4 and Stage 5
Stage 4 develops the coordinated design into technical detail. Software engineering can then be traced back to approved requirements, with testing planned around defined functions and interfaces. Factory Acceptance Testing (FAT) provides an opportunity to evaluate the configured system in a controlled environment before site implementation. Record findings and resolve them against agreed acceptance criteria.
At Stage 5, the design meets the realities of the site. Installation sequencing, access, existing equipment interfaces and operational windows all need to inform commissioning plans. A controlled transition should define how the new system will be verified, how outstanding issues will be managed and who can approve progression to live operation. This is where control systems design consultancy can help connect engineering decisions with site-specific constraints.
For organisations planning control systems design from RIBA Stage 1 to Stage 5, AAC LTD | All About Control’s automation engineering consultancy can be considered as part of the project’s specialist engineering requirements. A disciplined stage-gate approach keeps stakeholders aligned and provides a documented route from initial brief to commissioning, without assuming every project will follow an identical sequence.
Engineering for Zero Failure: Risk Mitigation and Downtime Management
In a live airport environment, migration risk is not confined to the replacement PLC. A change to control logic or an interface can affect connected baggage handling, airside equipment and supervisory systems. Identify how failures could propagate before implementation begins. The aim is to reduce risk through evidence, testing and controlled decision-making, not to promise that failure or passenger impact is impossible.
For aviation operations in 2026, mission-critical resilience means a control system can sustain or recover its required function when faults or planned changes occur, with risks and recovery actions understood in advance.
Mission-Critical Risk Assessment Strategies
Begin with an auditable view of the system being migrated. Check I/O lists against the installed configuration, trace legacy code dependencies and document interfaces to SCADA and other airport OT systems. Where records are incomplete, treat assumptions as open risks to verify, rather than allowing them to become hidden design decisions.
For each failure mode, record the affected process, how the fault could be detected, its operational consequence and the agreed mitigation. This helps distinguish a local fault from one that could interrupt a wider sequence, such as baggage routing or an airside control function. PLC migration project management should also establish who can approve testing, cutover and rollback, and what evidence is required at each decision point.
Minimising Operational Disruption
A parallel run can provide a controlled way to compare the new architecture with the operating legacy system before responsibility transfers. It needs careful engineering: define which system has control authority, prevent conflicting outputs and verify signal mapping and behaviour under representative conditions. Parallel operation is not automatically safe or suitable for every system, so the design must account for site interfaces and operating constraints.
For a large baggage handling system, phased migration may allow defined sections or functions to be tested and transferred in sequence, subject to the system architecture and operational plan. Specialist integration knowledge matters in a live environment because equipment dependencies, access restrictions and passenger flows can shape when and how commissioning takes place. The objective is to minimise operational and passenger impact, while recognising that no plan can guarantee zero impact.
A virtual commissioning approach can help engineers test control logic against a representative model before site cutover. AAC LTD | All About Control has a proprietary AIAB™ platform; its suitability and capabilities for a particular migration should be confirmed during project scoping rather than assumed. Testing should be supported by a rollback protocol that specifies trigger conditions, decision authority, safe restoration steps and checks to confirm the legacy system is ready to resume control. Keep the plan documented and rehearsed. That preparation makes a difficult cutover more governable.
Modernising Control Architecture with IEC 61499 Standards
A PLC migration can be an opportunity to review not only the controller, but also how control logic is organised and maintained. Traditional PLC applications commonly use a cyclic execution model, whereas IEC 61499 describes distributed, event-driven control using function blocks. That difference has practical consequences: engineers need to examine how functions, signals and system interactions behave, rather than assume legacy code can simply be transferred unchanged.
IEC 61499 is an open standard, but that does not mean every implementation is open-source or automatically compatible across vendors. Hardware independence is an architectural aim, not a guarantee. Before committing to a new approach, the project team should test how the proposed design handles actual interfaces, operational requirements and support arrangements.
The Shift to Distributed Control
In a distributed design, control functions can be structured as connected components rather than relying solely on one centralised programme. This can support modularity and make it easier to understand how individual functions interact, provided the architecture is properly engineered and documented. Explore the principles behind IEC 61499 control architecture when assessing whether this model fits the system being migrated.
EcoStruxure Automation Expert (EAE) is associated with this software-defined approach. AAC LTD | All About Control is a Schneider Electric EAE Master Partner, giving project stakeholders a basis for discussing how the platform may fit their control architecture. Evaluate vendor-agnostic design in practical terms: identify which software components can be reused, what depends on a specific runtime or device, and how the system will be supported over time.
Future-Proofing Your Investment
For a legacy migration, modularity matters when it addresses real operational needs. Define boundaries around functions that may change independently, document interfaces and verify how updates will be tested without compromising connected processes. This can make future modifications more manageable, while avoiding the assumption that any standard removes the need for platform-specific engineering or lifecycle planning.
AI and advanced analytics also require deliberate design. Consider what operational data is available, how it can be accessed and what governance or security constraints apply. Where required, the control layer should provide suitable, well-defined data interfaces. Analytics capabilities should not be treated as an automatic outcome of adopting IEC 61499 or EAE.
Strong PLC migration project management links architectural ambition to the constraints of the existing installation, validating interoperability and maintainability alongside functional performance. To discuss how IEC 61499 principles may apply to a mission-critical migration, explore AAC LTD | All About Control’s control systems expertise.
Partnering for Success: Technical Mastery in Complex Systems Integration
In a mission-critical airport environment, the right integration partner needs to understand more than the replacement controller. They need to connect control system design, software engineering and site commissioning while accounting for the operational dependencies that make each installation distinct. A generic delivery model may not provide the specialist knowledge a legacy migration requires, so assess partners against the system, risks and project stages involved.
Look for relevant evidence, not broad assurances: experience with comparable airport control systems, familiarity with the legacy platform and a clear method for managing decisions from initial design through commissioning. Ask who will be responsible for the engineering, how design changes will be controlled and how the project team will stay aligned with operational stakeholders.
The Specialist SME Advantage
A specialist SME can offer a focused route to technical expertise, but the project structure matters. Confirm whether senior engineers and decision-makers will be involved at the milestones where their input is needed, and how responsibilities will be maintained if requirements change. In high-pressure delivery scenarios, clear communication and candid escalation help teams address issues methodically rather than allowing uncertainty to accumulate.
Airport control systems rarely fit a template. Bespoke software engineering and consultancy should reflect the site’s defined operational requirements, interfaces and constraints, rather than simply reproduce existing logic without review. AAC Ltd specialises in mission-critical airport control systems, including Siemens S5 to S7 migration, and provides control systems design from RIBA Stage 1 to Stage 5.
Delivering Operational Excellence
Replacing PLC hardware is only one part of the engineering challenge. The migration plan must also account for how the new control layer interacts with supervisory systems. Verify signal mapping, alarms, operating states and interfaces against agreed requirements. Explore the considerations involved in airport SCADA systems as part of the wider integration approach.
Commissioning should be supported by traceable test results, a controlled cutover plan and clear handover information so the operating team can understand the system as delivered. Clarify which commissioning activities are included in the project scope and what arrangements, if any, apply after handover. Ongoing support should never be assumed.
Effective PLC migration project management depends on choosing a partner whose expertise aligns with the full project lifecycle, not just equipment replacement. To discuss your requirements, optimise your next PLC migration project with AAC Ltd.
Make Your Next Migration a Strategic Step Forward
A dependable migration is shaped by decisions made well before cutover: a clear project brief, engineering aligned with operational needs and a realistic plan for testing and transition. Treating control architecture as a long-term asset, rather than simply replacing obsolete equipment, helps organisations consider maintainability and future requirements alongside immediate reliability.
That is the value of disciplined PLC migration project management. For mission-critical aviation systems, specialist knowledge can help connect design intent with the practical demands of integration and commissioning. AAC Ltd brings specialist aviation sector expertise, control systems design capability from RIBA Stage 1 to Stage 5, and Schneider Electric EAE Master Partner status to this work.
If you are assessing a legacy system or planning a migration, start with a structured conversation about the operational context, engineering scope and risks to manage. Consult with our mission-critical migration experts to explore how a considered approach can support your project. With the right expertise and preparation, modernisation can be a confident step towards a more resilient control environment.
Frequently Asked Questions
What are the main risks involved in a PLC migration project?
The main risks are operational disruption, incorrect or incomplete transfer of control behaviour, interface problems and insufficient testing before cutover. In an airport, a fault may affect connected functions such as baggage handling or supervisory systems, so dependencies need to be understood as well as the PLC itself. PLC migration project management should document risks, assign owners, define acceptance criteria and establish cutover and rollback decisions before implementation.
How long does a typical Siemens S5 to S7 migration take?
There is no reliable single duration for a Siemens S5 to S7 migration because project scope and site constraints vary. The schedule depends on factors such as the number of control functions and interfaces, the quality of legacy documentation, the extent of software changes, testing requirements and available commissioning windows. A realistic programme follows system discovery and requirements definition, then accounts for engineering, verification, site work and stakeholder approvals.
Can a PLC migration be performed without shutting down operations?
Some parts of a migration can sometimes be prepared or tested while operations continue, but a no-shutdown cutover cannot be assumed. Feasibility depends on the existing architecture, system interfaces, safe isolation arrangements and acceptable operating conditions. A parallel run may allow comparison of old and new behaviour, but it requires careful control of outputs and authority. The migration plan should state what can happen live, what requires an outage and how rollback would work.
Why is RIBA Stage design relevant to automation engineering?
RIBA stages provide a structured way to connect the project brief with design development and site delivery. Applied to automation, they help clarify operational requirements, assess existing systems, develop functional specifications and progress towards detailed engineering and commissioning. This gives stakeholders defined points to review scope, resolve assumptions and approve deliverables. RIBA does not replace automation engineering; it helps organise that work and align it with the wider project lifecycle.
What is the difference between IEC 61131 and IEC 61499 standards?
IEC 61131-3 is commonly associated with PLC programming languages and a cyclic execution model, in which logic is repeatedly scanned. IEC 61499 describes a function-block approach for distributed control, using event-driven execution and aiming to separate application logic from specific hardware. These are different engineering models, not interchangeable labels for a controller. Choosing between them requires consideration of the application, platform, integration needs and capability to maintain the resulting system.
How much does a mission-critical PLC migration project cost?
There is no responsible way to give a meaningful project cost without understanding the installation and migration scope. Cost drivers include system complexity, the number of interfaces and I/O points, legacy code condition, design changes, testing, site constraints and the cutover strategy. For a useful estimate, define the required outcomes and engineering deliverables first, then ensure the proposal makes assumptions, exclusions and commissioning responsibilities clear.
What is the role of a Schneider Electric EAE Master Partner?
A Schneider Electric EAE Master Partner has a recognised relationship with Schneider Electric’s EcoStruxure Automation Expert ecosystem. For a project team, this can provide relevant platform knowledge when evaluating an EAE-based control architecture, including how software components and hardware are selected and integrated. It does not remove the need to assess project-specific suitability, interoperability, testing and support arrangements. AAC Ltd is a Schneider Electric EAE Master Partner.
How do you handle legacy code during a system upgrade?
Start by preserving and reviewing the available legacy code, then compare it with system documentation and observed operation to identify dependencies and gaps. Separate functions that should be retained from those that need redesign, and document the reasoning so changes can be traced to requirements. Test recreated or modified logic against defined operating scenarios, I/O behaviour and interfaces before cutover. Treat undocumented assumptions as risks to resolve, not facts.
