Hosted vs Customer-Hosted Catalog Software Who holds your catalog when the contract ends?

Every catalog system lives somewhere. Either the vendor runs it for you, or you run it on computers you control. The choice feels like an IT detail when you sign, and it decides who holds years of fitment and product data when prices change, a vendor is sold, or you want to leave.

Two ways to run catalog software

Hosted (also called software as a service, or SaaS) means the vendor runs the application on its own infrastructure and you use it through a browser. The U.S. National Institute of Standards and Technology (NIST) defines SaaS precisely: the customer uses the provider's applications and "does not manage or control the underlying cloud infrastructure", including network, servers, operating systems and storage, "or even individual application capabilities", apart from limited user settings [1].

Customer-hosted means the software is installed on a computer or server your business controls, in your own office or in your own cloud account. In NIST's terms, a business that rents raw computing from a cloud provider (infrastructure as a service) still has "control over operating systems, storage, and deployed applications" [1]. The software is the same kind of tool either way; what changes is who holds the keys.

Some catalog services sit in between: you send spreadsheets or load sheets, and the provider maintains the real catalog in its own system. For ownership purposes, that is hosted. The catalog you depend on lives on someone else's infrastructure.

What owning the catalog means

With hosted software, ownership is whatever the contract says. NIST's guidance on public cloud computing is direct about this: "ownership rights over the data must be firmly established in the service contract," the contract should state that the customer keeps exclusive ownership of all its data, and those terms "must not be subject to unilateral amendment by the cloud provider" [2]. The same guidance notes that where data is physically kept is often "unavailable or not disclosed to the service consumer" [2].

Responsibility does not move with the data. NIST puts it plainly: accountability "cannot be delegated to a cloud provider" [2]. If a receiver gets bad fitment, it is still your brand on the part.

Reference data adds a second layer, and it applies whichever way the software is run. ACES and PIES records are built on the Auto Care Association's reference databases: the Vehicle Configuration Database (VCdb), Product Classification Database (PCdb), Product Attribute Database (PAdb), Qualifier Database (Qdb) and Brand Table. Auto Care owns them and licenses them by subscription, 12 months at a time [5][6]. In its own words, the VCdb, Qdb, PCdb and Brand Table are "required to create and/or receive ACES xml files" [10]. Auto Care now delivers the databases through an API as often as daily, with manual downloads moved to a monthly schedule [9].

The license reaches everyone who touches the files. Auto Care's license treats files built from its databases as derivative works: the subscriber owns its own data and a limited, partial share of the copyright in those works, while Auto Care keeps ownership of everything it licensed [6]. A third party hired to create those works must be an Auto Care subscriber before the work starts, and anyone a subscriber distributes them to must be a subscriber in its own right [6]. Brand identity travels inside the files too: the PIES schema requires a Brand ID on every item, and ACES files carry the brand in the file header or on each application [11][12]. Whoever runs the software, someone must keep that reference data current and licensed, and you should know who.

With customer-hosted software, the catalog sits in a database on your infrastructure. Ownership is a fact of where the data is, not a clause you have to negotiate. The trade-off is that keeping that database safe is also yours.

The exit test

The clearest way to compare the two models is to ask what happens on the day you leave. NIST tells organizations to plan an exit before they sign: the strategy should cover a normal end of contract and an unexpected one, "such as that due to service provider bankruptcy", and "the ability to export all of the organization's data in a usable format" is "a vital aspect of an exit strategy" [2]. It also lists the recovery of useful metadata as part of the exit [2].

For an aftermarket catalog, "usable format" has a head start. The Aftermarket Catalog Exchange Standard (ACES) and the Product Information Exchange Standard (PIES) are Auto Care's industry standards for fitment and product information, exchanged as XML that every trading partner can read [4][7][8]. An export in current ACES and PIES can be loaded by any system built on the standards.

A standard export is not the whole catalog, though. ACES and PIES carry what the standards define. Your own descriptions, web copy, categories, part relationships, notes and working history may live in fields the standards do not cover. If those come out as a raw dump with no documentation, or not at all, you leave with the data a receiver already has and lose the work that made your catalog yours.

A customer-hosted system answers the exit test differently: there is nothing to retrieve, because the database never left. What you need to check instead is whether that database is open to you, documented, and readable without the vendor's software.

Who does the work

Neither model is free of effort; the work just lands in different places. The U.S. Cybersecurity and Infrastructure Security Agency (CISA), writing for federal agencies, describes the split well: securing a SaaS product "relies heavily upon the service provider," which means placing more trust in that provider, while with infrastructure services "much responsibility falls on the agency" [3]. CISA also warns that providers draw that line differently from one vendor to the next, and defines vendor lock-in as a customer having "dependencies on services and resources" inside one provider [3].

In plain terms:

• Hosted takes servers, backups, upgrades and uptime off your plate. You accept the provider's pricing, schedule, outages and terms, and your access depends on the account staying open.
• Customer-hosted gives you control of the data, the timing and the access. You or your IT provider take on installation, backups, security and updates on your side, and you should expect the software vendor to make that simple.

A small brand with no IT staff is not automatically better off hosted, and a large one is not automatically better off running its own systems. The right answer depends on who you trust to hold the catalog, and whether you can leave without losing it.

Questions to put to any vendor

These work for either model. A good answer is specific and written down; a vague one is an answer too.

1. Where does my catalog physically live, and who can access it? Ask by name: which company, which country, which staff roles.
2. Who owns the data, in the contract? Look for exclusive ownership and terms the vendor cannot change on its own.
3. What exactly do I receive if I leave? Current ACES and PIES XML, plus everything outside the standards, in a documented format. Ask for a sample.
4. What happens if your company is sold or closes? The exit plan should not depend on the vendor still being there.
5. Can I query my own data directly? Reporting, business-intelligence tools and your own systems should not need the vendor's permission or an extra fee.
6. Is everyone who builds or receives my files an Auto Care subscriber? Ask whose subscription covers the reference data, how quickly a new VCdb or PCdb release reaches your catalog, and who rechecks your fitment against it.
7. What work lands on my side? For customer-hosted software: the hardware and operating systems supported, who handles backups and updates, and what help is included.

If a vendor answers all seven clearly, either model can serve you well. If the exit question gets a vague answer, that tells you who would really hold your catalog.