Case Study - Making a warehouse of unlabelled art searchable

Overview

Cadogan Tate moves and stores objects that cannot be replaced — paintings, sculpture, antiques and vintage furniture belonging to private collectors, galleries, museums, auction houses and dealers, across thirteen locations in the UK, Europe and the United States.

Nothing about the data was missing. Every item, every movement, every condition record was already captured. It simply was not retrievable — not by the client, and not quickly by anyone except a trained operator.

The records lived in Moveware, a moving-and-storage ERP with a dated interface that had never been web-enabled. When a client asked where their items were, an account manager opened the ERP, worked the screens until the right records surfaced, copied what they found into an email and sent it back. Clients routinely waited days for an answer the system already held.

And when the operator got there, the record often did not say much. A bronze of a mounted rider had been catalogued, in full, as Statue.

That is a retrieval problem twice over — one of access, one of description. It shaped everything we did.

The constraint

Three things made this harder than a portal build.

The company was mid-acquisition-spree. Cadogan Tate was buying adjacent firms, each arriving with its own systems. Anything we built had to survive integration with platforms that were not yet chosen.

The ERP could not be changed on our schedule. Moveware upgrades ran through the vendor, at meaningful cost per upgrade, on the vendor's release cycle rather than ours. We could ask for capability, but we could not build it ourselves or plan a date around it.

There was no in-house engineering team. Nobody internal was going to own this after us, which changes what you are allowed to build. Rohit was on site in London four times that year working directly on the internal systems.

We did consider buying our way out — an off-the-shelf WMS, or a replacement ERP. Neither survived contact with the actual workflows, which are specific to handling objects that cannot be replaced and are not the workflows a general warehouse product is built around. Replacing the system of record would have put live movements at risk to fix a problem that was never about the system of record. So the ERP stayed, and we built around it.

What we built

A read path out of the ERP

The first job was getting catalogue and inventory data — the art and vintage furniture actually sitting in the warehouses — out of a system never designed to give it up, without touching the way it takes data in.

We started with a nightly batch into MySQL. Nightly was enough to prove the portal was worth having and not enough to run a business on, because in fine art logistics the question a client asks is almost always about something that moved this morning. When the ERP gained support for database triggers, we moved the sync onto them. A change written in the ERP now reaches the portal in under a minute.

Staging the data into a schema we controlled is what made the rest possible. Once the operational record was mirrored, we could index it, enrich it and search it without asking the ERP to do anything it was not built for.

Giving the objects their words back

The portal runs on Elasticsearch over items, photographs, locations, condition reports and movement history. Standing that up is ordinary work. The part that mattered is that a search index is only as good as the text in it, and much of this catalogue had almost no text at all.

Objects arrive described by whoever received them, often in a hurry, sometimes decades ago. A bronze of a mounted rider is entered as Statue. It is correctly stored, correctly tracked, and effectively invisible: no client searching their own collection will ever type the one word that finds it.

So we ran computer vision over the item photography and used the model's output to enrich the index — tagging that bronze with horse, rider, cowboy, and every other term a person might actually reach for. The catalogue keeps its original records untouched; the index gains the vocabulary those records never had.

This is the part we would point to first. The retrieval problem was not that the search engine was bad. It was that the documents were empty, and no amount of query tuning fixes an empty document.

An iOS app that writes the manifest

Packing was the other place information went missing — recorded on paper, or in someone's memory, and reconciled later.

The app has crews photograph each item as it is packed, then photograph the sealed box. From those images the manifest assembles itself, so what is in the box is recorded at the moment it goes in rather than reconstructed afterwards. Boxes and containers carry QR codes, so locating, loading and moving a consignment becomes a scan instead of a search through paperwork.

The team

Twelve engineers. Rohit as architect and one senior engineer in the United States, who between them covered DevOps and on-call; the rest of the team in Vadodara doing development.

The engagement ran from March 2023 to November 2025. Rohit architected the build and held that seat for the first eighteen months; the team carried it through to the end without him. That is the more useful fact if you are weighing whether a distributed team holds together — it kept delivering for more than a year after the architect moved off.

Results

Clients stopped asking. The account manager is no longer the interface between a collection and the person who owns it — a client opens the portal, searches their own items, and gets an answer at the moment they want it rather than several days later. Objects that were invisible to search because nobody had described them are now findable by what they look like.