How to avoid vendor lock-in in a government smart lighting project

A government smart lighting project avoids vendor lock-in when the authority can replace a failed controller, change its management platform, or appoint a new maintenance provider without replacing otherwise serviceable infrastructure. A low installation price is not good value if these changes later require the original supplier’s permission, proprietary tools, or unpriced integration work.

The procurement objective should therefore be demonstrable, contractually protected replaceability—not simply an “open platform” claim. Hardware interfaces, communications, software access, data rights, and transition costs must all support that objective. An integrated solution can still be appropriate, provided its components and services remain separable on workable terms.

Identify what would actually have to change

Lock-in is not confined to the central management software. It can arise at the luminaire connection, within a wireless network, through cloud subscriptions, or in the credentials needed to commission replacement equipment. A system may export energy reports freely while preventing another provider from controlling its installed lighting nodes.

Before issuing the tender, require an architecture showing luminaires and drivers, control nodes, gateways where applicable, communications services, the management platform, and external integrations. For every boundary, establish who controls the interface and what replacement would require.

This exercise distinguishes manageable dependence from expensive dependence. Replacing a software subscription is materially different from sending crews to every lighting column to replace a controller.

Specify interoperability at the correct interface

“Standards-based” does not mean universally interchangeable. A standard may address a mechanical socket, communication between a driver and controller, or the interface between a management platform and an outdoor device network. Compliance at one layer does not establish compatibility across the whole system.

For example, applicable Zhaga Book 18 and D4i requirements can support a defined interface between outdoor luminaires and control devices. They do not, by themselves, establish that a controller will join an alternative supplier’s radio network. Similarly, TALQ addresses interoperability between central management software and outdoor device networks; it does not make every field controller interchangeable.

Tender requirements should identify the relevant standard, version, profile, required functions, and evidence of conformity. Where certification applies, verify that it covers the offered product and configuration—not merely another product in the supplier’s portfolio. Require a function-by-function compatibility matrix covering switching, dimming, scheduling, alarms, energy reporting, and firmware management where needed.

Physical lighting specifications must be assessed separately. A product such as Modern Street Lighting｜MSL-XY, listed with 150–250 W light power and 8–14 m pole heights, provides information relevant to lighting and structural selection. Those specifications do not establish controller interchangeability or platform compatibility. Procurement documents must separately define the control interface, driver requirements, commissioning access, and replaceable components.

Where an interface is proprietary, require bidders to disclose it explicitly. A proprietary element is not automatically unacceptable, but its replacement consequences must be visible and priced before award.

Turn data ownership into operational access

A clause stating that “the authority owns the data” is insufficient if exports omit device relationships, use undocumented identifiers, or require a paid consultancy engagement. Ownership must include practical access throughout the contract and during transition.

Define the records to be delivered: asset identifiers, locations, device models, firmware versions, schedules, dimming settings, alarm histories, energy measurements, and relevant configuration metadata. Require documented schemas, units, timestamps, and relationships between records. A replacement provider should not have to reconstruct the asset register from screenshots.

API access also needs commercial and technical conditions. Establish which operations are available, authentication arrangements, rate limits, bulk-export capability, additional charges, and notice periods for incompatible changes. An API limited to reading dashboards cannot substitute for an interface needed to operate lighting.

Credential control requires particular care. The authority should have contractual rights and secure procedures to transfer administration, re-provision devices, and rotate credentials during a provider change. This does not require unrestricted distribution of private keys or removal of security controls. It requires a documented transition process that does not depend on the outgoing supplier’s discretionary approval.

Price the exit, not just the installation

Lifecycle comparisons should use the same operating assumptions and evaluation period for every bid. Include platform subscriptions, connectivity, support, firmware maintenance, API access, data retention, spares, training, and necessary gateway or server replacement. Identify which prices are fixed, indexed, usage-based, or subject to renewal negotiation.

Add a defined supplier-change scenario to the evaluated cost. Ask each bidder to price transferring management to a replacement provider while retaining serviceable luminaires and as much of the control infrastructure as technically feasible. The response should identify:

• Equipment that must be replaced and the technical reason for replacement.
• Site visits, access equipment, recommissioning, and testing requirements.
• Data extraction, interface integration, and configuration-transfer work.
• Parallel operation, temporary connectivity, and termination charges.
• Transition assistance, training, and documentation fees.

These are procurement scenarios, not forecasts that a transition will occur. Their purpose is to expose dependencies that an installation-only comparison hides. Model supplier failure and service termination as well as voluntary migration: a low exit fee offers little protection if devices cannot be re-provisioned without an unavailable cloud service.

Evaluate the cost of partial change too. Replacing failed controllers or retendering maintenance should not automatically trigger migration of the entire lighting estate.

Make replacement a witnessed acceptance test

Interoperability presentations are weaker evidence than a representative demonstration. Before full deployment, require bidders to prove the interfaces and replacement routes on which their proposals depend, using the offered hardware, firmware, and software versions.

A meaningful pilot could transfer a representative group of lights to an alternative management platform, introduce an approved alternative controller where interchangeability is claimed, and export records for import into an independent environment. Verify required functions after the change—not just whether devices appear on a screen.

Test loss of connectivity as well. The specification should define the safe operating state, local schedule behavior, restoration process, and which functions remain available without the platform. Continued basic lighting operation does not prove complete independence, but it limits the operational consequences of a subscription dispute or service outage.

Record configuration details, exceptions, manual interventions, and the time and tools required. Tie acceptance and relevant payments to those results. If an alternative route requires custom engineering, establish who funds and supports it before deployment.

Put transition obligations where they can be enforced

The contract should align responsibilities across the equipment supplier, platform operator, communications provider, and maintenance contractor. A single lead contractor can simplify accountability, but the authority still needs access rights that survive subcontractor replacement or contract termination.

Specify documentation handover, administrative access, export formats, transition assistance rates, support periods, and continued service during an agreed migration window. Address product discontinuation, security-update obligations, compatibility changes, and advance notice of end-of-support. Preserve configuration records and interface documentation as the installed system changes.

Source-code escrow may help with some custom software risks, but it is not a substitute for a workable exit. Code without build instructions, dependencies, licensing rights, and deployment capability may be unusable. For a hosted service, data portability and tested migration arrangements can be more consequential.

The award decision should favor the strongest combination of lighting performance, operating reliability, lifecycle cost, and verified replaceability—not the largest number of “open” claims. Before signing, the authority should know what it can retain, what it must replace, who can perform the change, and how the cost will be determined. That is the practical boundary between buying an integrated lighting system and accepting indefinite supplier dependence.