“Like-for-like replacement.”

It is one of those phrases that appears constantly in fire alarm maintenance.

A detector fails.

A sounder stops working.

An interface becomes unreliable.

A control panel dies.

The replacement looks similar, connects to the same wiring and performs broadly the same function, so it gets described as like-for-like.

But physically interchangeable does not necessarily mean functionally equivalent.

And on a life-safety system, the difference matters.

A genuinely like-for-like replacement should preserve the characteristics that matter to the design and operation of the system, not merely fit in the same hole.

The problem with the phrase “like-for-like”

In practice, like-for-like can mean several completely different things:

“It fits the existing base.”

“It is made by the same manufacturer.”

“It uses the same protocol.”

“It has the same number of terminals.”

“It performs roughly the same function.”

“The wholesaler said this is the replacement model.”

None of those, individually, proves equivalence.

Fire alarm systems are assemblies of interacting components. BS EN 54-13 exists specifically around the compatibility and connect ability assessment of system components, a useful reminder that compliance of individual pieces of equipment does not make arbitrary combinations equivalent.

BS 5839-1:2025 meanwhile covers the design, installation, commissioning and maintenance of non-domestic fire detection and alarm systems, including systems which initiate other fire-protection measures.

The question therefore shouldn't simply be:

“Will the new part work?”

It should be:

“Will the system still perform as it was designed to after this part is changed?”

Those are not always the same question.

1. A detector isn't just a detector

Probably the simplest example is an automatic detector.

Imagine an optical smoke detector is obsolete and the manufacturer's recommended current product physically fits the same base.

Easy replacement.

Except the new detector might have:

• different sensing characteristics;
• different selectable modes;
• different filtering algorithms;
• integrated short-circuit isolation;
• different LED behaviour;
• different current consumption;
• different protocol capabilities; or
• different environmental limits.

It may be a perfectly good detector.

It may even be the manufacturer's intended successor.

But that doesn't mean an engineer should fit it without understanding what has changed.

A particularly obvious example is replacing one detector technology with another.

Existing:
Optical smoke detector

Replacement:
Optical / heat multisensor

Both devices can detect fire.

Both may fit the same base.

Both may communicate with the same panel.

But if the new device is configured differently, responds differently or introduces additional sensing criteria, the system has changed.

That might be entirely acceptable.

It just isn't something that should happen accidentally under the banner of “like-for-like”.

2. Compatible does not mean identical

Manufacturers frequently maintain backward compatibility across several generations of equipment.

That is extremely useful.

But compatibility means that two products can operate together within defined conditions.

It doesn't necessarily mean they are identical.

A newer device might introduce capabilities that an older panel cannot use.

An older device might work on a newer panel but lack functionality assumed by a modern design.

A particular combination may require:

• specific firmware;
• particular panel software;
• restricted operating modes;
• updated configuration tools; or
• particular loop interface hardware.

This is why manufacturer compatibility information actually matters.

“It's the same protocol” is not enough.

Protocols evolve.

Device ranges evolve.

Control equipment evolves.

The fact that a panel can successfully poll a device tells you remarkably little about whether every intended function remains correct.

3. Sounders are a good example of hidden differences

A loop-powered sounder appears fairly simple.

It makes noise when commanded.

So if one fails, surely another addressable sounder is like-for-like?

Not necessarily.

Consider:

• sound output;
• selected tone;
• tone frequency;
• synchronisation;
• current consumption;
• maximum permitted loop quantity;
• address-setting method;
• isolator arrangement; and
• whether a beacon or visual alarm device is incorporated.

Even within the same product family, different settings can materially change loop loading.

Imagine an existing loop contains 90 sounders and the replacement model consumes slightly more current while operating.

One replacement probably means nothing.

Replacing fifty of them during a refurbishment might.

The individual component swap gradually becomes a system-level change.

The same applies to visual alarm devices.

Two units might both flash, yet have different coverage characteristics and installation requirements.

A red flashing thing on the ceiling is not automatically equivalent to another red flashing thing on the ceiling.

4. The terminal labels don't tell you what an interface does

Interfaces are another common source of supposedly like-for-like replacements.

The old module has:

COM
NO
NC

The new module has:

COM
NO
NC

Problem solved.

Except the interface may also differ in:

• contact rating;
• monitored versus unmonitored operation;
• default relay state;
• behaviour during loss of loop communication;
• behaviour during processor reset;
• onboard isolation;
• input monitoring resistance;
• fault reporting;
• activation delay; or
• whether outputs latch.

These details matter enormously when the interface controls another life-safety function.

Fire alarm systems can provide signals which initiate equipment such as smoke control, automatic door releases, fuel shut-offs and lift grounding.

If a relay controls something important, the relevant question isn't:

“Does it have a normally-open contact?”

It is:

“Does the complete interface still behave correctly during fire, fault and loss-of-power conditions?”

The replacement module can click perfectly during a fire test while behaving completely differently when communication fails.

That difference may be more important than what happens during normal operation.

5. Panel replacement is almost never as simple as it sounds

The phrase becomes particularly dangerous around control panel replacement.

“We're replacing the panel like-for-like.”

What does that actually mean?

Same manufacturer?

Same number of loops?

Same protocol?

Same enclosure size?

Because changing a fire alarm control panel can affect almost everything:

• loop capacity;
• loop current;
• power-supply capacity;
• battery capacity;
• network architecture;
• cause-and-effect programming;
• fault monitoring;
• event logging;
• output behaviour;
• disablement behaviour;
• configuration limits;
• interface operation; and
• compatibility with existing field devices.

Two four-loop panels are not automatically equivalent because both have four loops.

And even replacing an older panel with its current-generation successor can involve substantial changes behind the scenes.

If the configuration has to be recreated, network settings rebuilt and cause-and-effect logic reconstructed, this is no longer just a hardware swap.

You are effectively recommissioning a significant part of the system.

Calling it “like-for-like” doesn't make that responsibility disappear.

6. Cause and effect can make a replacement much bigger than it appears

This links directly to something we covered in our previous article on fire alarm cause and effect.

Suppose an output module controlling smoke ventilation fails.

Physically, it is one module.

But that device may sit at the end of a chain like this:

Detector activates
        ↓
Fire condition generated
        ↓
Cause-and-effect logic
        ↓
Network transmission
        ↓
Output group activates
        ↓
Interface module operates
        ↓
Smoke control receives signal
        ↓
Ventilation system responds

Replacing the module only addresses one part of that chain.

If the replacement requires readdressing, configuration changes or alterations to the output group, the complete cause-and-effect function should be verified afterwards.

Watching the replacement relay operate isn't enough.

If its purpose is to start smoke control, test the smoke control response.

If its purpose is to recall a lift, test the lift.

If its purpose is to release a door, check the door.

“Like-for-like” should never become an excuse to avoid functional testing.

7. Power supplies and batteries aren't just numbers on labels

Power equipment creates another deceptively simple example.

Consider a failed power supply rated:

24 V DC, 5 A

A replacement is also:

24 V DC, 5 A

Like-for-like?

Maybe.

But what about:

• standby load capability;
• alarm load capability;
• battery charging characteristics;
• maximum battery capacity;
• recharge capability;
• fault monitoring;
• mains-failure signalling;
• battery-fault signalling;
• output supervision; and
• temperature behaviour?

The headline voltage and current ratings don't describe the whole product.

Batteries have the same problem.

Two batteries might both say:

12 V 17 Ah

That does not automatically mean every aspect of their application is identical.

Battery capacity also shouldn't be treated in isolation from the actual system load and required standby period.

If system equipment has changed since the original battery calculation was performed, blindly fitting the size already in the cabinet simply perpetuates an assumption.

Sometimes maintenance is a useful opportunity to ask:

“Is this still correctly sized?”

rather than:

“What battery was already fitted?”

8. External equipment makes “like-for-like” even harder

The principle extends beyond the fire alarm panel itself.

Consider equipment interfaced with fire detection:

• smoke-control actuators;
• dampers;
• door retainers;
• access-control interfaces;
• shutdown relays;
• automatic vents;
• suppression controls; and
• lift interfaces.

A replacement actuator might have the same nominal force but a different:

• stroke;
• operating speed;
• current demand;
• duty cycle;
• control method;
• mounting geometry; or
• fail-safe arrangement.

A replacement door retainer might physically hold the same door but have different electrical characteristics.

A new smoke-control controller might accept the same fire input while interpreting faults completely differently.

The further you move into interfaced systems, the less useful “it looks the same” becomes.

9. Small substitutions can accumulate into a redesign

One replacement normally isn't the problem.

It's what happens over twenty years.

Original detector becomes obsolete.

A newer detector is fitted.

Then the sounders are replaced.

Then several interfaces change.

Then the network card is upgraded.

Then one panel gets replaced.

Then batteries are increased because additional devices were added.

Then somebody modifies the cause and effect.

Each change individually gets described as maintenance.

Eventually almost none of the system matches the original design.

There is nothing inherently wrong with a system evolving.

Buildings evolve too.

The problem is when the documentation doesn't evolve with it.

After enough undocumented “like-for-like” replacements, future engineers are presented with a system whose drawings, configuration, device schedules and actual hardware all tell slightly different stories.

10. Manufacturer discontinuation doesn't remove engineering responsibility

When a manufacturer discontinues a component, they may provide a recommended successor.

That information is extremely valuable.

But “replacement for Product X” shouldn't automatically be interpreted as:

“No further consideration required.”

It may simply mean:

“This is the currently supported product intended for this application.”

There may still be:

• firmware requirements;
• programming differences;
• configuration changes;
• commissioning instructions; or
• limitations when used with older equipment.

Read the documentation.

Check the compatibility information.

Understand the application.

If the manufacturer says a firmware update is required, that isn't optional because the device happened to power up without it.

11. When maintenance becomes modification

There is an important conceptual boundary here.

Replacing a failed component with a genuinely equivalent component is maintenance.

But once the replacement changes the system's:

• detection characteristics;
• coverage;
• alarm output;
• cause and effect;
• power requirements;
• fault behaviour;
• interface operation;
• network architecture; or
• intended functionality,

you should at least recognise that you are moving beyond a straightforward component replacement.

That doesn't mean the change is prohibited.

It means it needs to be engineered rather than assumed.

The current BS 5839-1 code of practice addresses the design, installation, commissioning and maintenance lifecycle of non-domestic fire detection and alarm systems.

Those activities aren't completely isolated from one another.

A maintenance decision can create a design change.

A design change can create a commissioning requirement.

Pretending otherwise by writing “LFL replacement” on the worksheet doesn't change the technical reality.

So what should engineers actually check?

Before describing a replacement as like-for-like, consider whether the important characteristics remain equivalent.

Compatibility

Is the replacement specifically compatible with:

• the control equipment;
• the loop protocol;
• the device base;
• firmware versions; and
• other connected system components?

Function

Does it perform the same required function?

Not merely:

“Does it activate?”

But:

“Does it produce the response required by the system design?”

Electrical characteristics

Consider:

• supply voltage;
• standby current;
• alarm current;
• contact rating;
• loop loading;
• battery loading; and
• monitoring arrangements.

Fire behaviour

For detection and alarm devices, consider whether relevant characteristics such as detection method, settings, alarm output and coverage remain appropriate.

Fault behaviour

Ask what happens during:

• cable failure;
• communication loss;
• power failure;
• processor reset; and
• component failure.

A system's behaviour when something goes wrong is part of its design.

Cause and effect

If the replacement forms part of an input or output function, test the complete sequence.

Documentation

Update whatever needs updating:

• device schedules;
• drawings;
• configuration records;
• cause-and-effect matrices;
• battery calculations; and
• commissioning records.

If something has materially changed, future engineers need to know.

“Like-for-like” should describe the outcome

There is nothing wrong with the phrase like-for-like.

It is useful when it genuinely applies.

The problem is using it as shorthand for:

“The replacement fitted.”

A better definition would be:

A replacement that preserves the relevant functionality, compatibility, performance and system behaviour required by the existing design.

Sometimes that will be the manufacturer's current equivalent device.

Sometimes it will require configuration changes.

Sometimes a new calculation will be required.

Sometimes the replacement will reveal that the original equipment was no longer appropriate anyway.

And sometimes the honest answer is:

“This isn't actually like-for-like. It's a modification.”

That isn't a problem.

Failing to recognise the difference is.

Ultimately, like-for-like should describe what the system does after the work, not what the replacement component looks like before you fit it.