Why Catalogue Migrations Fail
Service catalogue migrations fail for a predictable set of reasons, and almost none of them are technical. The technology for migrating catalogue items, variable sets, and workflow attachments is well understood. The problems are taxonomic, political, and governance-related - and they surface only after the technical migration is complete.
The most common failure pattern: a technically successful migration that produces a catalogue nobody uses. Items are migrated from the legacy system but not rationalised, so the new catalogue has the same 400 items that made the old one unusable. The taxonomy reflects how IT is organised rather than how the business requests services. Search works, but only if you know the exact item name. Within six months, users are going back to email.
The Taxonomy Decision Is the Migration
Before a single catalogue item is migrated, the taxonomy question must be answered: how will the new catalogue be organised, and for whom?
There are two fundamentally different organising principles:
- IT-centric taxonomy: organised by technology domain - Networking, End User Computing, Applications, Infrastructure. Makes sense to IT teams. Means nothing to a business user trying to request a new laptop or reset a password.
- Business-centric taxonomy: organised by what the user is trying to accomplish - Getting Started, Managing My Access, Hardware and Equipment, Business Applications. Requires more design effort upfront. Produces significantly higher self-service adoption rates.
The choice should be determined by who your primary catalogue users are. If the catalogue is primarily used by IT teams requesting services from other IT teams, the IT-centric taxonomy is defensible. If the catalogue serves the wider organisation - which is the case for most mature ServiceNow deployments - the business-centric taxonomy consistently outperforms.
A catalogue item that is never found is not a catalogue item. It is a service that IT has decided it offers but that the business has decided not to use.
The Rationalisation Step Nobody Wants to Do
Most legacy catalogues contain items that were created for a specific request, never updated, and never decommissioned. Items that reference decommissioned technologies. Duplicate items for the same service requested by different teams. Items with broken variable sets or approval workflows that haven't worked since the last upgrade.
Before migration, a catalogue audit is essential. The output should be:
- Active items: genuinely used in the last 12 months, functioning correctly - migrate these
- Stale items: not used in the last 12 months - archive, do not migrate
- Duplicate items: multiple items for the same service - consolidate to one before migration
- Broken items: items with broken workflows or variable sets - fix or retire before migration
- Missing items: services that are provided but not catalogued - design and add during migration
The typical outcome of a catalogue audit is that 30–40% of items can be archived, 15–20% can be consolidated, and 10–15% need to be created from scratch. Migrating all 400 items to have the same 400 items in a new catalogue is not a migration - it is a copy.
Variable Set Architecture
Variable sets are the technical component most commonly mishandled in catalogue migrations. Legacy implementations frequently have catalogue items with embedded variables rather than shared variable sets - meaning the same data field (requester name, cost centre, delivery address) is defined independently on dozens of catalogue items.
Migration is the correct time to implement shared variable sets for common data fields. This produces three benefits: consistent data capture across items, easier maintenance when fields need updating, and better reporting since the same data field is captured in the same table structure regardless of which item triggered it.
The resistance to this refactoring is usually time-based: "we don't have time to redesign variable sets during migration." The correct response is that implementing shared variable sets after migration is harder, not easier - because you now have a production catalogue with user-facing items that you cannot easily change.
Workflow and Approval Migration
Catalogue item workflows are often the most complex migration component. Legacy workflows frequently contain hardcoded group names, user names, and system references that are no longer valid. Approval chains that were designed for an organisational structure that no longer exists.
The migration approach for workflows should be: identify the business intent of each approval chain (who needs to approve this request, and under what conditions), then rebuild the workflow against the current organisational model rather than migrating the legacy flow directly.
Migrating broken workflows produces a working catalogue with broken approval chains. Rebuilding workflows for the current organisation takes longer upfront but produces a catalogue that actually works after go-live.
The Governance Model for Day Two
A catalogue without ongoing governance decays immediately. The day-two governance model must be established before go-live - not planned for "after we've settled in."
Minimum viable catalogue governance includes:
- A catalogue owner for each category with authority to approve new items and retire stale ones
- A review cadence - quarterly at minimum - for items that haven't been requested in 6 months
- A request process for new catalogue items that ensures they meet taxonomy, variable set, and workflow standards before publication
- A reporting dashboard that surfaces item usage, request completion rates, and user satisfaction by item
Without this governance, the new catalogue will reach the same state as the old one in 18–24 months.
Migration Sequencing
- Catalogue audit and rationalisation - agree what to migrate, what to archive, what to rebuild
- Taxonomy design - agree the category structure before any items are touched
- Variable set architecture - design shared variable sets for common fields
- Migration of active items in priority order - highest-volume items first, so the most-used services are available earliest
- Workflow rebuild for migrated items - against current organisational model
- User acceptance testing - with actual end users, not IT stakeholders
- Legacy catalogue retirement - do not leave both catalogues active simultaneously
- Governance model handover - with named owners, review calendar, and reporting in place
MainStack delivers service catalogue migrations and redesigns. If you are planning a catalogue migration or have a catalogue that needs rationalisation, we can run a diagnostic and produce a migration roadmap in a working session.