Upgrading an old machine fleet and legal requirements – when does an upgrade make it a new machine?

In an ageing machine fleet, the boundary between a modernization and a new machine rarely lies where the project name suggests. Whether the work still amounts to restoring an existing function or has already become a substantial rebuild is determined not by the retained frame, the old control cabinet, or the asset number, but by the actual technical effect of the changes. That effect defines the scope of responsibility, the risk assessment, the documentation, and the next steps.

That is why the question of when a modernization becomes a new machine is not something to consider “at the end,” after installation and commissioning. It is a decision that must be made at the outset, before the scope is split between the integrator, the software contractor, and maintenance. If the classification is defined too narrowly, the issue will return at the most expensive stage: during acceptance, after the first trials, or after an incident. At that point, the cost no longer comes from the technical solutions themselves, but from having to correct them later under the pressure of downtime and liability.

Substantial modification – the context of the Machinery Regulation 2023/1230

Modernization of older machines is increasingly less about replacing individual worn components. In practice, entire functional layers are rebuilt: control systems, drives, safety systems, the operator interface, or communication with other equipment. Such intervention affects not only reliability and performance, but also who is responsible for the product after the changes and on what basis it can be considered safe, as discussed more broadly in safe machine automation.

From a project perspective, the key issue is to determine early on whether, after the rebuild, the user is still dealing essentially with the same machine performing the same function under a similar risk profile, or with a system that has a new operating logic, new operating states, and different effects on the operator, service personnel, or the surrounding area. The more the function, control architecture, and hazard profile change, the harder it is to defend the view that this is merely a standard modernization.

This is easy to see in an old line where relay-based control is replaced with a programmable controller, while new operating modes, automatic changeover, remote diagnostics, and a modified motion sequence are added at the same time. From a procurement perspective, this may look like replacement of obsolete components. From a safety perspective, however, it creates a different technical object: it responds differently to faults, stops motion differently, allows new operating states, and changes the relationship between people and the machine.

Only against that background should the legal requirements be considered. Replacing worn parts or restoring an existing function does not in itself mean that a new machine has been created. The situation is different when the rebuild is substantial: it changes the intended use, parameters affecting safety, or combines components into a new functional whole. The assessment cannot be based on the task name or on retaining part of the old design. What matters is the technical outcome and its impact on risk. If that outcome is unclear, it is also necessary to consider whether the modernized system should be treated as partly completed machinery or whether it requires a full safety assessment before commissioning, as with the legal requirements and CE marking for modernized machines. This should also be assessed in light of the legal requirements arising from Regulation 2023/1230.

Where cost or risk most often increases

In projects like these, the biggest cost increase usually does not come from component prices, but from misclassifying the scope of work. If the team treats the rebuild as a repair for too long and only later realizes that, in practice, it has changed the function, the control system, or the structure of the protective measures, the project stops being predictable. Assumptions have to be revisited, solutions already ordered or implemented have to be reworked, the technical documentation after a substantial modification has to be completed, and acceptance dates have to be pushed back.

The source of risk is usually fragmented decision-making. Mechanical, automation, and maintenance teams each complete their part correctly, but without a shared criterion for assessing the final outcome. Yet for safety and liability, what matters is not whether each individual element is correct, but the result of the system as a whole: whether the intended use has changed, how the machine is used, the machine boundaries, the dependencies between devices, and the risk reduction measures. If, after modernization, the operator, service personnel, or material move through the system differently than before, and safety depends on new control functions or new interactions between modules, this is no longer a simple parts replacement.

A typical situation looks harmless. A plant plans to refresh a workstation by replacing the controller, adding light curtains, and introducing automatic part feeding. Each of these changes on its own may seem reasonable and limited. The problem begins when the new system changes the motion sequence, eliminates some manual tasks, and introduces dependencies between devices that previously operated independently. In that case, it is not enough to check whether the new components have their own manufacturer documentation. The whole system must be assessed as an integrated technological function, taking into account safety functions in industrial automation and, where relevant, new safety functions in the control system.

This, in turn, triggers additional design obligations: verification of protective measures, review of the operating and maintenance instructions, updating diagrams, describing new operating modes, and defining troubleshooting rules. If the team only notices this at acceptance, the cost no longer comes from compliance itself, but from rework carried out under the pressure of production downtime. That is why responsibility cannot be effectively shifted by a clause in the purchase order alone. If the modernization has the characteristics of a substantial rebuild, the assessment must cover the safety of the entire machine or assembly of machines after the change, not just the compliance of individual deliveries.

From a legal perspective, this is a critical point. When, after modernization, the party that actually takes responsibility for the technical solution as a whole changes, both the design risk and the risk of assuming the role of manufacturer increase. Even if the formal classification still requires analysis, this is the point to stop before start-up and put the fundamentals in order: the functional scope, system boundaries, responsibility for integration, and the list of documents that are no longer valid after the change, including the consequences of taking on the role of manufacturer.

How to approach this in practice

The starting point should not be how to label the project, but who will be responsible for the machine as a whole after the rebuild. The answer determines the schedule, budget, acceptance approach, and documentation preparation. If the change affects control logic, safety functions, the operating sequence, interaction with other equipment, or parameters that determine risk, the project should be managed as if the classification could lead to the system being treated as a new machine or at least as a substantially modified technical whole.

This is not about excessive formalization, but about making decisions in the right order. First, determine who is responsible for the solution architecture, who approves the system boundaries, and who ensures documentation consistency. Only then does it make sense to divide the scope into mechanics, automation, software, and maintenance support. If no one manages the change as a single technical solution, the project usually looks cheaper in the purchase order, but becomes more expensive during trials, acceptance, and after start-up. In such cases, it is also important to properly organize cooperation between the integrator, software house, and maintenance team, much like in the broader choice between in-house engineering and outsourcing.

A good test is to trace one specific change. An old machine gets a new controller, drives, protective light curtains, and is integrated into a line with automatic infeed and outfeed of parts. The mechanical core of the equipment remains the same, so it is easy to treat this as just a refresh. After the change, however, it turns out that the emergency stop works differently, guard locking is implemented differently, and the operator is no longer running a single machine but part of an integrated process. At that point, the main burden of the project lies not in the price of the components, but in the need to redefine the functions, check fault scenarios, and update instructions, diagrams, and acceptance rules.

In practice, before work begins, it is worth answering at least three questions:

• After the change, does the way machine motion or stopping is controlled change?
• Does the rebuild affect safety functions or the boundaries of the entire system?
• Does one party need to consolidate the solution and confirm its correctness as a whole?

If the answer to these questions is yes, a heightened assessment and documentation regime should be adopted. You cannot assume that declarations for the new parts will close the matter. Only then does it make sense to decide whether the scope of changes brings the project close to being treated as a new machine. It is also worth separating two issues that are often mixed together in practice: whether the project requires a new legal classification, and whether the machine is actually safe after modernization. These issues are related, but they are not the same, and each requires separate confirmation before production start-up, preferably based on a risk analysis in the project.

What to watch out for during implementation

Most mistakes occur when the right questions are asked too late. If the team only discovers after installation that the operating logic, system boundaries, or safety functions of the entire machine have changed, the implementation falls into costly correction mode. The documentation has to be revisited, the technical solutions checked again, compliance evidence supplemented, and acceptance postponed. After start-up, what matters is not the project name in the purchase order, but the actual technical effect of the rebuild.

That is why, already at the concept stage, it is worth adopting a simple criterion: after modernization, can it still be reliably said that this is the same machine with a restored or improved subassembly, or has a newly shaped production function, a new control method, or a new risk configuration been created? This does not replace analysis, but it helps structure decisions. If the change requires the operating sequence, access areas, manual modes, stopping, interdependencies between machines, or the system response to failure to be redefined, a heightened technical and formal regime should be assumed from the outset.

A borderline case is well illustrated by replacing the control system with a programmable one, adding new drives, and changing how the machine interacts with the infeed conveyor. Formally, this can be described as a modernization of an existing line, but technically the effects go much further: start-up conditions change, stopping times change, the relationship between guards and motion changes, and the machine behaves differently after a power loss and restart. If this is combined with a new operator panel, a new setup mode, or remote service access, the risk no longer arises from individual parts but from the architecture of the entire solution, including the safety functions in the control system after the rebuild.

In that situation, the right question is not whether the new components have their own declarations, but who takes responsibility for the correct operation of the integrated system and whether this can be demonstrated through testing, risk analysis, and as-built documentation. This is usually the point at which practical safety and legal classification stop running on separate tracks. If the scope of the rebuild is large enough to create a new functional configuration of the machine or assembly of machines, it is not enough to keep the old manual and attach the documentation for the new subassemblies. You need to verify whether this triggers the obligation to carry out a full conformity assessment for the whole, prepare complete technical documentation after a substantial modification, and update the user information to reflect the machine’s actual condition after the changes.

In ambiguous projects, the safest approach is to base the decision on a documented description of the modernization scope, an analysis of the impact on safety functions, and a clear indication of the party responsible for integration. Without this, it is easy to overlook not only obligations related to CE marking after a substantial modification, but also the simpler and often neglected duty to properly update the machine operating instructions after the rebuild, diagrams, descriptions of operating modes, and maintenance rules. Where the scope points to a full compliance route, this also affects the final EU Declaration of Conformity.

The management conclusion is simple: the way the modernization is classified must be decided before detailed solutions are ordered, not after they are delivered. Otherwise, any late need for additional tests, guards, interlocks, validation of safety functions, or documentation corrections will look like an unplanned cost, even though it actually results from a wrong initial assumption. In borderline projects, it is therefore worth tracking not only the installation schedule, but also the number of open safety risks before acceptance, changes in control logic after integration testing, and the completeness of documentation for the user and maintenance team. These signals quickly show whether this is still a modernization of an existing machine or already a project that in fact leads to the creation of a new machine and the assumption of responsibilities normally assigned to the manufacturer. At the planning stage, it also helps to account for the hidden costs of choosing the right conformity assessment path, the broader context of machine safety in plant practice, and the recurring implementation issues described in common machine-building mistakes.