Many companies with large and complex product catalogs, like manufacturers, digitize their catalogs in stages. First is getting information online, often as downloadable PDFs. Next is making product data fully accessible and always up-to-date, which is where teams often encounter challenges with their legacy systems. As these early solutions often lack the flexibility to structure product content to make it searchable and don’t make it easy to keep data consistent across a growing number of channels, languages, and markets.
This article takes a look at the key signs that an organization has outgrown its legacy product catalog management solution, and when a modern Content Management (CMS) is the best choice for leveling up the product experience.
#Legacy product catalog management systems
For some companies, the legacy product catalog management system is a specific software like CMS, product information management (PIM), enterprise resource planning (ERP), or a custom-built application. While in plenty of cases the definition is much more vague, with product information being stored and managed using a variety of software, spreadsheets, shared drives, and portals.
Legacy systems: the pros
Different legacy systems will, naturally, offer different benefits. Your solution might have industry-specific features, be conveniently bundled with other business tools, or have been custom-built around the quirks of your catalog.
However, the universal pro of any legacy system is that it’s already in place. People are familiar with it, the data is stored within it, and considerable cost and effort have been invested in setting it up and maintaining it.
This is a big pro. Even when legacy systems aren’t perfect, the current pain points and the potential benefits of a more modern solution have to be pretty substantial to outweigh the familiarity factor and warrant a migration.
Legacy systems: the cons
Just like with the positives, each legacy system is going to have its own unique challenges. Considering that you’re reading up on alternative solutions for digital product catalogs, you’re probably well aware of the most frustrating parts of your current setup.
However, if the list below covers the major pain points of your legacy system, then it’s worth considering a move to an API-first CMS. These challenges, which are felt by many companies as they modernize their digital catalog, are ones that a flexible CMS can quickly solve.
Content silos
It’s hard to keep product information consistent if it’s spread across a patchwork of poorly integrated software and spreadsheets. Especially if teams have to manually copy updates between tools or are managing duplicate content for different channels, regions, and markets.
If this sounds familiar, you’re not alone. In a survey of 400 tech leaders on the state of content in their organization, 91% considered content to be siloed, and 92% found it difficult to keep different data and content types consistent (84% and 91%, respectively, for respondents in the manufacturing sector).
Slow update process
With many legacy systems, updating the website is a very IT-dependent process. Often leading to major bottlenecks in getting new product information live, as even small changes have to be done by a developer or are outsourced to an agency.
According to the Future of Content survey, this is the most common frustration manufacturers have with their legacy CMS, with 48% finding it a challenge that changes can only be made by a small number of people with the right skills.
Updates tend to happen ad hoc when only a small group of people are able to make them, making it very difficult to have a formal process for managing product content. Which can lead to delayed product launches, outdated information staying live on the website, and missed opportunities for marketing and personalization.
Part of the problem is that with many legacy systems the backend and frontend is managed as one big application. So a change to the website can cause unintended errors across the system, which can make even simple updates feel risky and big improvements feel impossible. One of the ways that an API-first CMS helps teams speed up the update process is by decoupling the frontend and backend (more on that later).
When the Marketing team wanted to upload a video, they had to send it to the agency. They would upload it to a platform and send it back with an ID for insertion into the previous CMS. It was very time-consuming.
Poor CX
Digitizing the catalog is meant to make product information easily accessible, and getting it online is just the first step. If page speeds are slow, or the catalog is hard to navigate, or product information is stuck in PDFs and isn’t searchable, then it’s not a convenient experience.
A common issue with legacy systems is that they struggle to keep up as the catalog, and the content that supports it, becomes more complex. They can prevent companies from fully showcasing their catalog (variants, configurations, related products), providing helpful supplementary content (user guides, 3D models, comparison tables), or tailoring the experience to each audience (translations, regional availability, personalized portals).
Limited flexibility to adapt and scale
It’s often hard to get a legacy system to support new use cases. Teams might have good ideas for how to improve the catalog structure, or internal workflows, or customer features, but the effort it would take to make the change prevents them from even trying. Holding back business from improving the existing experience, and making it nearly impossible to scale the system to support new content types, languages, and channels.
#API-first CMS for managing product content
A content management system (CMS) is software used to create and publish content across websites, mobile apps, portals, and other digital touchpoints. There is a wide range of CMS solutions on the market that are designed for different use cases, from simple sites with a handful of landing pages to omnichannel applications with thousands of assets.
An API-first CMS sits on the more advanced end of this spectrum and, because of the structured way it handles content data, is the type of CMS that’s best suited for managing complex product catalogs.
Traditional CMS vs API-first CMS
With a traditional CMS (Squarespace, Wordpress, Sitecore, etc), you think of content as belonging to a specific webpage. The content model is tightly linked to page templates, limiting the ability to structure content to support integrations, omnichannel, and data-driven use cases. These CMSs might work for managing the product pages of a small and simple catalog, but they lack the database capabilities to handle large amounts of SKUs, variants, and complex product details.
With an API-first CMS content is created as modular blocks that can be used across many different pages and channels. Content data is highly structured so that it can be shared via APIs to any frontend or easily integrated with other systems. This structured approach makes an API-first CMS a good choice for complex use cases and high volumes of content, as it combines the efficiency of a database with the user features that make it easy to create and publish content.
Editor's Note
API-first CMS: the pros
Structured, searchable product content
Product information isn’t managed as static pages but as a database, with companies having full control over the structure of their data. This allows the CMS to handle complex catalogs with thousands of SKUs and makes the product data fully searchable for end users.
An API-first CMS also adds metadata structure to all the content that gives context to the catalog like product images, CAD files, safety sheets, industry guides, and multilingual content. Ensuring this content is always shown alongside relevant products and is also easily findable via search.
Omnichannel readiness
A major benefit of structured content is that it can be reused across any digital channel. Teams can manage the catalog in one place and updates will be instantly seen across the website, mobile app, portals, and any other touchpoints. Making it easy to keep product data consistent.
Being able to reuse content doesn’t mean that each channel has to be a carbon copy. Businesses have the flexibility to create their own content model to tailor information to each audience. Such as localized and translated content, regional availability, or custom catalogs on a logged in portal.
Efficient content updates
An enterprise level CMS is going to have editing tools that allow non-technical users to create and publish content without the help of a developer. As well as features like workflows, data validations, versioning, and custom roles and permissions that help teams formalize and streamline the update process.
The modular structure of an API-first CMS also means that changes to one part of the system won’t disrupt the rest. So product and marketing teams can update content without worrying about accidentally taking down the website, and developers can quickly build and test frontend features without the risk of breaking critical functionality.
Flexible integrations
Having all content and functionality shared via APIs makes it easy to integrate the CMS with other systems like an ERP, PIM, CPQ, commerce platform, or custom database. Businesses can quickly integrate the CMS with existing tools to get up and running, with the flexibility to add and replace data sources over time as needs change.
Data can continue to live in your existing systems but teams can access and manage that data directly in the CMS. Providing a single source of truth for product content without having to duplicate data.
Modular, scalable architecture
In an API-first CMS functionality is broken up into discrete services. Each service communicates with the rest of the system using APIs and can be independently updated or even replaced. This modular design allows businesses to quickly adapt the CMS as needs change and as the catalog becomes more complex.
It also makes it easy to scale the system. New features can be built without having to start from scratch, and both content and infrastructure can be reused to quickly support new channels or launch into new markets.
Overall, this type of CMS supports a composable approach to software architecture. Where businesses have the freedom to “compose” their own tech stack of best-of-breed tools that are designed to easily integrate with others. Rather than being stuck in the traditional replatform cycles of a monolithic system, companies can continuously add, expand, and swap out the components of their stack to quickly adapt to new needs. Making a composite approach a much more future-proof setup.
API-first CMS: the cons
Learning curve
If teams are used to working with a traditional CMS, switching to thinking about content in a modular way can take some getting used to. Training for content creators and developers should be factored into any migration plan and, if in-house teams aren’t familiar with headless development, it can be useful to work with an implementation partner to set up the system.
Implementation effort
The flip side of offering complete flexibility over the content experience is that an API-first CMS doesn’t have an out-of-the-box data structure or website templates. It does take development effort to design the content model, set up integrations, and build out the frontend experience.
One part of the implementation process that can be particularly tricky is migrating legacy data, as it likely won’t match 1:1 with your new content structure. Especially if product information is currently spread across different systems without a universal structure.
Cost considerations
An API-first CMS is going to come with upfront costs for implementation and, depending on your legacy system, might have a higher licensing cost.
The total cost consideration should also include the potential savings a more modern system could bring such as hours saved on maintaining infrastructure, updating content, having sales hunt down product information, and any bottlenecks the new system can eliminate. Along with potential revenue opportunities the new CMS makes possible such as expanding to new markets and attracting new customers.
#3 tips for a smooth migration
Having spoken with many teams that have successfully made the move from legacy systems to an API-first solution, here are 3 of the most frequently offered pieces of advice.
1. Involve cross-functional teams early
Building the content model will take an in-depth understanding of the catalog and all its quirks, as well as a big picture view of the full lifecycle of product content from how it’s created, to who maintains it, to how it’s used by customers and internal teams.
Putting together a core team of representatives from different departments (product, development, operations, marketing, etc) to give input and feedback helps to ensure the model is comprehensive and to identify potential roadblocks early on. Plus, this team can be good advocates for the new system and help train others on how to use it.
2. Use an integration layer
A big benefit of headless architecture is the ability to bring together data from multiple sources into one frontend experience. A common way to facilitate this is using an integration layer to orchestrate backend data
This layer decouples the frontend from the backend, so companies can immediately start to use the latest frontend technologies to quickly improve the customer experience while modernizing the backend at a more gradual pace.
When Komax, the equipment manufacturer moved to a headless architecture they set up a GraphQL integration layer to coordinate data between their new API-first CMS, Hygraph, their existing solutions for product and customer data, and a modern frontend built using Nuxt. With this approach, Komax was able to raise their Google Lighthouse Performance score from 74 to 99.
3. Start small
The modularity of an API-first CMS means you don’t have to move off your legacy system in one big bang migration effort, but can step away in stages.
Many companies start with a small pilot project, like using the new CMS to manage a specific product category, brand, or regional site. Allowing them to learn the system and work out the kinks on less business critical areas, then steadily expand the new solution while gradually retiring the legacy one.
A pilot project that can solve a pain point of your current system is also a great way to quickly prove the value of the new solution and gain momentum for change.
#Hygraph CMS for modern product catalogs
Hygraph is an API-first CMS that gives businesses the tools to:
- Update product details in minutes, no IT help needed.
- Provide customers with a fast-loading, easily searchable catalog.
- Maintain consistency by using one system to manage product content across all channels, brands, languages, and regions.
- Easily integrate existing, and future, business systems and data sources using GraphQL APIs.
- Quickly adapt to support growing product lines, new digital channels, and expansion into new regions and markets.
Ready to level up the product experience? Learn more about why Hygraph is the best solution to modernize and scale complex product catalogs.
Blog Author
Katie Lawson
Content Writer
Katie is a freelance writer based in Amsterdam who talks a lot about B2B SaaS and MACH technologies. She’s always looking for good book recommendations.