In the mid-2000s, manufacturers were beginning to reckon with a fundamental shift in how clients researched, specified, and purchased products. For a lighting manufacturer with international ambitions, the gap between a static website and a dynamic, integrated digital presence wasn’t just a technology problem. It was a competitive one.

Visioneering was a lighting manufacturer operating across multiple international markets at a time when the specification and procurement process for commercial lighting was becoming increasingly digital. Contractors, architects, and project managers were turning to manufacturer websites as primary resources for the technical documentation, product specifications, and supporting materials they needed to build proposals and quotations. If the information wasn’t there, current, and easy to navigate, the product often wasn’t specified at all.

The existing Visioneering website was built on static HTML, which meant that every update, every new product specification, every revised technical document required manual intervention from someone with coding knowledge. In practical terms, this created a bottleneck that frustrated both the marketing team and the engineering department, whose product documentation was the most frequently requested content on the site. Engineers would finalize a specification sheet or update a product line detail, and the path from that completed document to the live website involved a handoff process that was slow, inconsistent, and entirely dependent on individual availability. By the time updated content reached the public-facing site, weeks had sometimes passed.

As Senior Marketing Manager and a member of the executive leadership team, I could see that this wasn’t a minor inconvenience. It was costing us real business.

Understanding the Real Problem

The instinct in situations like this is often to treat the technology as the problem and assume that a new platform will resolve everything. That instinct is usually wrong, and it would have been wrong here. Spending time with both the marketing team and the five-person engineering department made it clear that the static HTML architecture was a symptom rather than a cause. The deeper issue was that there was no shared system connecting the people who produced technical content to the platform that delivered it to clients. Engineers were working in their own environment, producing specifications, photometric data, installation documentation, and product line updates without any direct pathway to the website. Marketing was managing the site independently, relying on engineers to flag updates and then translating those updates into web content through a manual process that introduced delays, occasional errors, and no small amount of frustration on both sides. Clients building lighting proposals for commercial and institutional projects needed current, accurate product data, and they needed it to be accessible without picking up the phone.

The solution wasn’t just a new content management system. It was a new way of connecting two departments that had been operating in parallel rather than in concert.

Building the Migration Strategy

The migration from static HTML to WordPress was designed from the outset as an integration project rather than a redesign project. The distinction mattered. A redesign focused on aesthetics and information architecture would have produced a more attractive website without solving the underlying workflow problem. An integration project required mapping the engineering team’s content production process and building a CMS environment that fit into that process rather than asking engineers to adapt to a system built around marketing’s needs.

Working directly with the engineering team, I developed a content architecture that reflected how product information was actually organized and used in the field. Product categories, specification formats, and documentation structures were built around the way contractors and specifiers searched for and applied technical information, not around how the manufacturer had historically organized its internal filing systems. This meant several rounds of conversation with engineers who understood the technical nuances of the product line far better than any marketer could, and it meant treating their input as foundational to the architecture rather than supplementary to it. Training for the engineering team was kept deliberately practical. Rather than positioning WordPress as a marketing tool that engineers were being asked to contribute to, it was framed as a publishing system that gave them direct control over the accuracy and currency of their own product information. That framing shift was significant. Engineers who might otherwise have viewed CMS training as an imposition became engaged participants once they understood that the platform gave them the ability to ensure their specifications reached clients without passing through an intermediary.

The integration with engineering workflows also meant establishing clear content governance standards. Specification templates were developed that allowed engineers to populate product data in a consistent format that translated directly into the website’s product pages without requiring marketing to reformat or reinterpret the source material. Version control protocols were established to ensure that outdated documentation was retired systematically rather than lingering on the site after product updates.

What Changed When the System Went Live

The immediate operational impact of the migration was felt most clearly in the time between a product update and its appearance on the live website. What had previously taken several weeks was reduced to a matter of hours. Engineering could publish directly to the site through a workflow that included a straightforward review and approval step, maintaining quality control without reintroducing the bottleneck that had defined the previous process. The commercial impact became visible in the months that followed. Website traffic increased by 27% in the period after launch, a figure that reflected how central the site had become to the client specification process. Contractors and project managers who were building proposals and quotations for commercial lighting installations were using the Visioneering website as a primary reference, downloading specification sheets, photometric data, and product documentation directly rather than requesting materials through sales representatives or waiting for printed catalogues. The site had become a functional tool in the client’s workflow rather than a digital brochure.

Support requests related to product documentation dropped measurably as clients found what they needed independently. The sales team reported that inbound inquiries were better qualified because clients were arriving having already reviewed technical specifications and confirmed product suitability for their projects. The website was doing work that had previously required human intervention, and it was doing it at scale.

What a Lighting Manufacturer Taught Me About Digital Transformation

The Visioneering migration reinforced something I’ve carried into every technology and transformation initiative since. The value of a new platform is almost entirely determined by how well it connects to the people and processes that exist around it. WordPress didn’t transform Visioneering’s digital presence because it was a superior technology to static HTML, though it was. It transformed the presence because the migration was designed around the engineering team’s workflow, the client’s specification needs, and the commercial reality that accurate, accessible product information was a direct input to purchasing decisions.

When marketing and engineering finally operated through a shared system, the website stopped being a communications asset and became a commercial one. That’s a distinction worth building toward in any organisation where technical content and client-facing communication have historically lived in separate worlds.