Reference data management: What it is, where it should live, and when you need a tool

Reference data management is the practice of keeping the codes, classifications, and hierarchies that other data depend on consistent, versioned, and governed in every system that uses them. Country codes, currencies, units of measure, order statuses, and product categories are all reference data. Many of these lists are relatively small, but reports, integrations, and analytics queries that group or filter by them return wrong results when copies of a list diverge.

What’s needed is where each list is stored, how its history is kept, who approves changes, and whether a dedicated tool is justified. Many teams manage reference data with governed lookup tables. Others need the approval workflows, versioning, and distribution that a reference data management platform provides. Some also need a low-latency store to serve values inside transactions.

What is reference data? 

Reference data is a set of standardized codes, values, classifications, and relationships that other data uses for consistent meaning. A shipping address stores DE, and a country table maps DE to Germany. An order row stores status 3, and a status table defines 3 as “shipped.” DAMA International's DAMA-DMBOK2 defines reference data as data used to characterize or classify other data, or to relate data to information outside the organization¹. Consequently, lists of such data are often called “code tables.”

A list of that kind can carry a large load. For example, the 249 officially assigned country codes in ISO 3166-1 underpin addresses, tax rules, shipping, and regional analytics². One wrong value affects every record that references it, and systems that assign different meanings to the same code cannot exchange data reliably.

Reference data falls into three groups, depending on who defines and governs it:

• Externally governed reference data is the most familiar form of external reference data. A standards body defines and maintains it, as with ISO country and currency codes, units of measure, industry classification codes, and ICD-10 diagnosis codes, including national adaptations such as ICD-10-CM in the United States.

• Externally sourced reference data comes from a commercial provider rather than a standards body. Financial instrument data from market data vendors is a common example, and the provider's coverage, licensing terms, and corrections affect how it can be used.

• Internal reference data is defined and governed by the organization itself. Examples include product categories, cost-center codes, order and claim statuses, sales regions, and customer segments.

Some internal reference data applies only to one company's product data. A manufacturer's engine option table, which maps each code to a fuel type and engine category, is used by no other company, yet every configuration and order depends on it.

The concept of reference data isn’t new. Malcolm Chisholm's Managing Reference Data in Enterprise Databases, published in August 2000, describes reference data as data used solely to categorize other data or to relate it to information beyond the enterprise. Identifying which tables hold reference data is the first step toward managing them³.

Reference data vs. master data

Reference data classifies, while master data describes the business entities being classified. A customer record is master data. The customer segment stored on that record, such as "Enterprise" or "SMB," is reference data. 

Published definitions do not agree on the distinction between them. 

So, how do you decide? Here are two questions.

1. Does it classify, or does it describe an entity? Values that label other records, such as statuses, categories, or codes, are reference data. Records that represent a customer, product, supplier, or employee are master data.

2. What does a change mean? Adding a reference value, such as a new product category, may require a change to a business process. A change to master data, such as a customer's new address, is handled inside processes that already exist.

If both answers point to reference data, treat the table as reference data. Mixed answers indicate an edge case. Financial structures such as ledgers and cost centers are commonly listed as master data, yet many finance teams maintain cost-center lists exactly like code tables. Either treatment works, as long as one team owns the decision and every system follows it.

The classification determines scope and spending. Treating code lists as master data leads to buying entity-matching and merging capabilities that code lists do not need. Treating entity records as reference data leaves them without the stewardship that master data requires. Classifying each table first keeps the program sized to the data it governs.

Why "static" reference data keeps changing

Reference data is relatively stable, but that doesn’t mean it never changes. Values change less often than transactional data, and each change affects every system that stores the old value. The ISO 4217 maintenance agency issued Amendment 164⁸ to the currency code list in September 2017 and Amendment 179 in May 2025, so even a standardized currency code list is actively maintained⁹.

A change can alter the label, the code, or both:

• A name change with a stable code. On March 13, 2019, the ISO 3166 entry for MK changed its short and full name to North Macedonia¹⁰. Records that stored only the code MK needed no update. Tables that had copied the country name kept showing the old name until someone corrected them.

• A code retirement. ISO 4217 Amendment 172 moved the Sierra Leonean currency code SLL to the list of historic denominations, effective October 1, 2022, after a redenomination introduced SLE¹¹. Historical records still use SLL, so the code has to be retired, not deleted.

Internal reference data can change more often than externally governed lists like these. Merchandising teams split product categories, sales leadership redraws regions, and finance renumbers cost centers after reorganizations. Comparing the current product category list with the version from a year ago shows how often those changes occur.

Each of these changes needs an owner who tracks updates from standards bodies and from inside the business, and a versioning method that marks values as retired instead of overwriting them. Without both, reports keep running while the categories they group by no longer match the definitions in use.

What goes wrong when reference data is unmanaged

Unmanaged reference data tends to produce inconsistencies that nonetheless pass validation. Each value is legitimate in the system that holds it, so reports, joins, and integrations keep running on values that do not agree with one another. The effects show up later, during reconciliation or when a report cannot be explained.

Consider two departments that record the same service differently. One uses DEN for dental services; the other uses DC for dental care. Each code is valid in its own system, so it doesn’t produce an error, but a report that combines the two either double-counts the service or misses half of it.

The same cause produces a recognizable set of symptoms:

• Inaccurate analytics. Regional and product reports group by reference data, and mismatched code values require manual intervention before data can be aggregated⁶.

• Integration errors. A receiving system rejects or misinterprets a code that is not in its own list.

• Manual upkeep. Lists kept in spreadsheets are copied and edited separately, and spreadsheets offer limited validation and no automated versioning⁵, so the copies diverge.

• Late discovery. Inconsistencies stay hidden until systems are integrated or consolidated¹².

Reference data quality therefore has to be measured across systems, not within each one. Where a list is maintained determines how many copies exist across the organization. If a list is maintained separately in multiple systems, each system has its own copy, creating more opportunities for the values to diverge.

How should reference data be stored?

Reference data belongs in the simplest place that meets four requirements: 

1. How often the values change

2. How many systems read them

3. Whether the values carry their own attributes

4. Whether changes need approval and audit 

There are five basic options. Reference data should move only when its requirements change. 

Enumerated items are appropriate when the value set is intentionally part of the application's contract, so a change should require a software or schema change. The states of a state machine are a typical example. Enumerated items become a problem when the business expects values to change independently of deployments, and how much of a problem that is depends on the engine. In PostgreSQL, values can be added to an enum type, but existing values cannot be removed or reordered, so a business list stored as an enum turns every new category into a schema migration and leaves retired categories in place¹³.

Lookup tables turn each value into a row. A row can carry a description, a sort order, a display label, and a valid_to date, and a foreign key constraint rejects any record that references a value not in the table. One table per list is the simpler design. One generic table keyed on list name and code can enforce the same foreign-key integrity as one table per list, using a composite foreign key and a check constraint that pins the list name on each referencing table.  However, every list's values share one column type, unrelated lists share one index, and every consumer has to know the list name.

Seed files bring reference data into analytics pipelines with version control and code review. dbt recommends seeds for static data that changes infrequently, such as a country-code mapping¹⁴. Seeds fit small, version-controlled lists that engineers maintain. Once business users need to edit a list, or it grows large and changes often, a source table or service is the better method.

A reference data service fits when many applications read the same values and disagreement between them is costly. An example is a dedicated endpoint that serves as the point of reference for such data and offers read operations only¹⁵. Changes reach the endpoint through a controlled path behind it.

A reference data management platform adds approval workflows for business users, versioning with effective dates, hierarchy management, and cross-reference mappings between systems' code sets.

The rungs describe where a list is governed, not every place a copy of it is stored. A list governed on the reference data platform rung is often also replicated into lookup tables or a low-latency store for reading. Those copies are downstream distribution, and they never accept changes directly.

The ladder turns "where should reference data be stored?" into a decision made one list at a time: which rung does each list need? A product category list read by one service fits in a lookup table. The same list, read by many services and edited by merchandising every quarter, needs a different rung.

When a dedicated RDM tool is justified

Many teams do not need a dedicated reference data management tool. If a few lists are stored in one database, change a few times a year, and are edited by the engineers who own that database, governed lookup tables with foreign keys and a change log are sufficient.

When you need a tool is when you need capabilities that are costly to build. Homegrown setups built on databases, spreadsheets, and workflow software often lack change management, audit controls, and granular permissions, and that becomes a compliance risk^16. 

Five signals indicate that a list has outgrown tables and files:

1. Non-engineers need to edit it. Merchandising, finance, or compliance teams are responsible for the values, and routing each change through an engineering ticket delays it.

2. Changes need approval and an audit trail. Regulated reporting or internal controls require evidence of who approved each change.

3. Many systems use it. Several services, warehouses, or applications read the same list, and disagreement between them causes problems. 

4. It has structure. The list is a hierarchy, such as a product taxonomy or a chart of accounts, or it needs mappings to other systems' code sets.

5. History matters. Reports must reproduce the values that were valid on a past date.

One signal on its own rarely justifies a platform; several together usually do. Lists that show none of the signals belong in a table or seed file, whatever their business importance.

The type of tool matters as well. Master data management platforms are built around entity matching, merging, and survivorship, which resolve duplicate records for customers, products, and accounts¹⁷. Code lists do not need those capabilities, so organizations that need to only manage reference data do not necessarily need a full master data management platform. 

Checking each reference data set against the five signals limits tools to the lists that need one.

How reference data management works

Reference data management runs as a cycle of six stages, whether the lists are stored in lookup tables or in a platform. Tools differ in how much of the cycle they automate.

1. Model. Define each list's structure to fit its own domain: its code, label, description, attributes, and any parent-child relationships. A finance chart of accounts and a healthcare diagnosis code set don't have much in common besides both using codes, so build each one based on standards from its own field, not a one-size-fits-all template. That's what keeps each list actually useful for its purpose. 

2. Load and map. Bring values in from their data sources, such as a standards body's published file or an internal system. Then map each system's local codes to the shared version, which is where much of the integration effort goes.

3. Check quality. Validate values as they are entered, before they reach consumers. Data cleansing and validation at this stage, alongside data modeling and integration, stop errors from spreading⁷.

4. Approve. Route proposed changes through their owners. Two-person approval, where one person proposes a change and another approves it, is a standard control for reference data changes because one value can affect the whole organization⁵.

5. Version. Record when each value became valid and when it stopped, so history stays reproducible.

6. Distribute. Publish approved values to every consumer, from operational applications to the data warehouse, and keep them current as requirements change¹⁸.

Stages 1, 2, and 6 are required for any application to use a list, so homegrown setups include them by necessity. Stages 3, 4, and 5 are not required for an application to run, which makes them easy to defer, but they are the stages on which data stewards, auditors, and analysts depend. Effective reference data management means adding those stages to the ones already in place.

Versioning and effective dating

One common way to version reference data is to retain each historical value and record when it became and when it ceased to be valid. Other approaches, such as immutable snapshots, revision numbers, append-only change records, and temporal tables, do the same thing. Whichever method is used, retained history lets a report that runs today reproduce the categories, currencies, or regions that applied last year, which is why version control is a long-standing recommendation for reference data.

For effective dating, you need at least a pair of dates on every row. Here, valid_to holds the first date on which the row no longer applies, an exclusive end that avoids gaps and overlaps between rows. Open-ended rows use the sentinel date 9999-12-31 instead of NULL, so the comparison in the join needs no special handling for rows that are still current.

Croatia's switch to the euro shows why the end date matters: The current reference value is not always the historically valid one. An invoice dated December 2022 belongs in kuna, and Croatian tax filings for periods before the switch were still filed in kuna¹⁹. A table that held only the current currency would report that invoice in euros.

Reports then join on the transaction date instead of the current value. The half-open interval, with an inclusive start and an exclusive end, behaves the same for dates and timestamps. With non-overlapping, gap-free validity intervals, each transaction matches exactly one row:

SELECT t.txn_id, t.amount, c.label
FROM transactions t
JOIN country_currency c
  ON c.country = t.country
 AND t.txn_date >= c.valid_from
 AND t.txn_date <  c.valid_to;

The same change shows a second requirement: future-dated entries. The ISO 4217 maintenance agency announced the Croatian change on November 2, 2022, effective January 1, 2023²⁰. A team whose table accepts a future valid_from loads the change when it is announced and lets the date activate it. Without that capability, someone has to edit the table manually on the effective date.

Regulated reporting often requires one more layer. “Valid time” is the period when a value applies to the business; “transaction time” is the period when the system recorded it. Keeping both, in a bitemporal model, answers an auditor's question about what the system recorded as of a given date, which matters when a correction is backdated.

Adding valid_from and valid_to before the first change preserves history from the start. Dates added after values have been overwritten cannot recover history that was lost.

Cross-reference mappings and hierarchies

A cross-reference mapping translates one system's codes into another's. Separate systems often use different codes for the same concept: a billing platform, a CRM, and a warehouse each maintain their own status or region list, and every report that combines them depends on a mapping. Managing mappings between reference data representations and domains is a core RDM function for that reason. For example, Statistics Canada publishes a concordance between the 2018 and 2019 versions of its country classification²¹, listing each old and new entry side by side with a note on what changed. 

An internal mapping table needs a few more fields:

The mapping_type row is often omitted. Many-to-one mappings lose detail when data moves toward the shared list. One-to-many mappings, where one old code becomes several new ones, may require an allocation rule, a ratio, or additional business context. If another attribute determines which target applies, the mapping is deterministic; where no such rule exists, an allocation needs a documented decision from the list owner. A code with no equivalent on the other side needs an explicit type of its own, so consumers can tell a deliberate gap from a missing mapping. Recording the type tells analysts which numbers came through translation intact.

Hierarchies add another dimension. Reference code tables can be flat lists or hierarchies, and hierarchy management means governing parent-child relationships as well as the values¹⁶. Moving one product category under a new parent changes every rollup that uses it, so hierarchy changes need the same approval and versioning as value changes.

With owners and dates attached to mappings and hierarchies, integrations stay correct as the lists on both sides change.

Distributing reference data to consumers

Reference data is read constantly and written rarely, so distribution is a tradeoff among freshness guarantees, latency, availability, and operational complexity. Consumers query a central source, which simplifies freshness guarantees but adds a network dependency to the read path. Alternatively, consumers maintain local replicas, which reduces latency and improves availability but requires a defined propagation and staleness model.

Every lookup is also a call on the request path. A lookup against an in-process copy costs little; one that crosses the network adds a round trip, and its tail latency adds to the request's. Fan-out compounds the effect. If a request makes 10 calls and their tail events are independent, the chance that at least one of them exceeds its own 99.9th-percentile latency is 1 − 0.999^10, about 1%. At 50 calls, it is about 5%. A reference lookup added to each of those calls raises the request's tail latency even when each lookup is fast on average.

There are four ways to handle this. Either way, one source accepts changes, and every other copy is downstream of it:

• Embed the value. Copy the label or attribute into each record at write time. Simple static data is often embedded directly instead of looked up, which works until the value changes and every embedded copy is out of date¹⁵.

• Query a central service. A read-only endpoint serves one authoritative version. Every lookup pays a network round trip, and every consumer depends on the service's availability: If it is unreachable, every transaction that needs a lookup stalls or fails. A client cache or read replica in front of the service reduces both costs but reintroduces stale reads, so the service is only as consistent as the caching in front of it.

• Replicate into each platform. Push approved lists into operational databases, data catalogs, and data warehouses on a schedule or on change⁵.

• Query in place. In cloud data integration, consumers query shared data where it resides instead of copying it, which removes duplication but adds latency and governance complexity across federated sources²². For pricing and reference data in finance, direct query models reduce file movement and staging, leaving fewer handoffs where access controls and lineage can fragment²³.

Latency. Every lookup is also a call on the request path. A lookup against an in-process copy costs little; one that crosses the network adds a round trip, and its tail latency adds to the request's. Fan-out compounds the effect. If a request makes 10 calls and their tail events are independent, the chance that at least one of them exceeds its own 99.9th-percentile latency is 1 − 0.999^10, about 1%. At 50 calls it is about 5%. A reference lookup added to each of those calls raises the request's tail latency even when each lookup is fast on average.

Freshness. A central service serves an approved change as soon as it is published; every replica or cache receives it later. Replication introduces an ordering problem. A transaction can arrive carrying a code that its local replica has not yet received, such as a product category approved minutes earlier. The consumer then has three options: reject the transaction, hold it in quarantine until the replica catches up, or accept it and validate later. Each is defensible for some lists and wrong for others, so the choice needs to be made and documented per list.

Availability. A distribution design has to state what consumers do when a node, a site, or a network link fails. A local replica keeps serving during a network partition, possibly with stale values. A central service keeps values consistent, but lookups fail while it is unreachable. Which failure is acceptable depends on what a stale value costs: a product category that lags by an hour in a dashboard is a nuisance, while a stale sanctions entry during payment screening is a compliance problem.

In every pattern, one source accepts changes, and every other copy is downstream of it.

Serving reference data at low latency

Payment screening shows every distribution requirement at once. A screening check runs on every payment, so it is high-volume. It sits on the authorization path, so its latency adds to the latency of each payment. It cannot be skipped when a dependency fails, so it is availability-critical. It must use the applicable current sanctions or restricted-party data, which can cover countries, entities, individuals, and aliases, so it is correctness-critical: a stale entry can let through a payment that the governed data would block. 

For a small list read by one service, an in-process map loaded at startup is the right design: It adds no network call and no new system. The case for a shared store comes from the volume and fan-out of lookups, not from the size of the list. When many service instances across several regions read the same values, an in-process copy per instance means every instance has to receive each update, apply it, and agree on which version is current. Some reference data is also not small; financial instrument data sets, for example, are far larger than a country list.

A store that serves these lookups needs five properties:

• Predictable tail latency at high read volume, measured at the 99th percentile and beyond, not only on average

• Defined read consistency, so consumers know whether a read can return a value older than the latest approved version

• Agreement across regions, so every region serves the same list and an approved update becomes visible in each region with known lag

• Defined behavior under failure, including node loss, site loss, and network partition

• A change feed from the governed source, so approved updates arrive without a batch reload

Aerospike is designed for this workload. Aerospike’s strong consistency mode, introduced in Database 4 and validated externally with Jepsen testing, provides linearizable single-record reads (selectable per read); Aerospike Database 8 builds distributed ACID transactions on top of it.  

For multi-region deployments, there are two models: 

• Multi-site clustering runs one strongly consistent cluster across sites and adds 2 to 100 milliseconds of write latency, depending on the distance between sites. 

• Cross Datacenter Replication (XDR) replicates asynchronously between independent clusters in active-passive, active-active, star, linear-chain, and hybrid topologies. Within a cluster, rack awareness places each record’s replicas in separate failure domains, such as racks or availability zones. With the replication factor set to the number of zones, the cluster can lose one zone and keep serving the list. This holds for a clean zone failure. Behavior during an ambiguous network partition depends on the cluster’s roster and consistency mode. By default, a strongly consistent namespace serves reads from each record’s master copy, which guarantees the latest committed value. Clients can instead opt in to reading from a replica in their own zone, which cuts cross-zone latency but no longer guarantees the latest value. Use the default for lookups that must reflect the latest approved change, and the replica read for lookups that can tolerate slightly stale data.

The two replication models correspond to the stale-value question. A list that every region must enforce identically at the same time, such as a sanctions list, fits a strongly consistent multi-site cluster, at the cost of added write latency for cross-site coordination. A list where a short replication lag is acceptable fits XDR, which keeps each region's reads local and lets a region keep serving if its link to the others fails.

In this architecture, Aerospike is the read-optimized distribution layer, not the reference data management platform. The RDM platform remains the system of record: Business users edit and approve values there, versions and history are kept there, and each approved change is published as an event. Aerospike stores the current values keyed for lookup, and applications read from it. Approval workflows, audit, and effective dating stay in the governed source.

Separating governance from serving lets each layer be chosen on its own terms. The RDM platform is selected for workflow and stewardship features, the serving layer for latency, replication, and failure behavior, and the change feed is the contract between them.

Letting business users edit reference data safely

People who know when a reference value should change are often not the people with write access to the table. Merchandising is responsible for product categories, finance is responsible for cost centers, and compliance is responsible for restricted-country lists, but engineers may be responsible for making changes. The solution is a workflow in which owners propose changes and someone else approves them before they reach consumers; broader table permissions do not provide that.

Safe editing needs four controls:

1. An editing surface built for non-engineers. A form or spreadsheet-like grid, not a notebook or SQL client. RDM tools aim to put lifecycle management in the hands of business users through governance interfaces and workflows, which reduces the load on IT¹⁶.

2. Validation at entry. Required fields, allowed formats, and duplicate checks catch errors while the editor is still looking at them.

3. Approval before publish. Edits land in a draft state. A second person, such as a data steward or list owner, approves them before they become visible downstream.

4. A record at three levels. Access audit shows who read or queried the data. Change audit shows what changed and when. Workflow audit shows who proposed, approved, and published each change. Platform logs usually cover the first: Unity Catalog, for example, captures user-level audit logs of data access and tracks lineage²⁴. Change and workflow audit have to come from the table's history and the approval process.

Granting a business user write access to a governed table provides editing without approval, and the change record shows the write only after it has happened. Teams that build their own solution do the same thing a tool provides: a draft table that business users edit, an approval step, and a publish job that copies approved rows into the table consumers read.

Each list needs three named roles:

One person can hold more than one role on a small team, as long as every change has a proposer and a separate approver and the record of both is retained. This arrangement removes engineers from routine changes and gives auditors the evidence they request.

Governance, ownership, and compliance

Reference data governance is the set of policies that decides who may change a list, how changes are approved, and how the organization shows it followed those rules. It is part of broader data governance alongside metadata management and data quality, and because the lists are often small and their owners identifiable, it is a practical place to start.

It’s often required by regulation. In banking, reference data underpins both master data and transactional data, and it can be an important dependency. If two business units map the same counterparty type to different codes, the aggregated risk report will be wrong. 

Organizations are starting to build the structures to handle this. The EDM Association's 2026 Global Data Management Benchmark surveyed more than 435 organizations across more than 50 countries and several industries^25. More than 70% of respondents report having a Chief Data Officer or equivalent role, and over 70% report formal governance structures, but many still lack the funding models and measurement frameworks needed to make that governance operational. The benchmark also finds that financial institutions outperform other sectors on most measures, so the averages may overstate maturity in industries under less regulatory pressure. In financial services, governance is moving toward controls embedded in workflows, platforms, and data models from the start instead of controls added afterward²³. For reference data, that means the approval step, version history, and change record produce compliance evidence as part of normal work.

How to evaluate a reference data management tool

A reference data management tool should be judged on its features and on whether people will use it day to day. Published evaluation criteria cover mapping, versioning, hierarchy management, security, connectivity, and lifecycle workflows, and they remain the baseline, but it can be hard to figure out usability, time to value, and cost from those¹⁶. 

Usability matters because reference data changes are small and frequent, so issues with routine edits accumulate across every change. The scorecard below covers features and practical factors together. The right-hand columns show how much each criterion matters to an analytics or mid-size team and to a regulated enterprise.

Vendors rarely publish pricing. Where a pricing model is described, it can scale with usage, such as number of users, data volume, or configuration. Knowing the drivers makes it possible to model cost against your own inventory of lists and editors.

Stack fit includes vendor ownership. For example, Informatica is now part of Salesforce, which completed the acquisition on November 18, 2025²⁶, and is in the process of integrating Informatica's MDM and data management services into its platform, with capabilities arriving through 2026²⁷. Ownership changes change roadmaps and integration priorities, so the evaluation should cover how the product will be developed and supported over the next few years.

A special case: Migrating from Microsoft’s Master Data Services

Microsoft has removed Master Data Services from SQL Server. Microsoft's list of discontinued Database Engine functionality states that MDS is removed in SQL Server 2025 (17.x), along with Data Quality Services²⁸. Microsoft continues to support MDS in SQL Server 2022 and earlier, and organizations that need to move to SQL Server 2025 will need to replace or migrate their MDS workloads. Many organizations used MDS for cost centers, product hierarchies, and shared code sets.

A migration involves more than moving tables, because MDS combined several functions in one product. Some companies have used it as a central repository for values previously scattered across CSV files, and Microsoft Fabric does not currently provide a like-for-like replacement for the MDS product²⁹. Updating a data platform does not, by itself, carry those functions across.

A like-for-like replacement should cover what MDS users relied on:

• Editable entities and attributes, so business users can maintain lists without SQL

• Hierarchies, including the ability to move members and keep the history of each move

• Business rules, so invalid values are blocked at entry

• Versions, so a list can be locked for a reporting period and compared with the next one

• Spreadsheet-style editing, because many MDS users worked through the Master Data Services add-in for Excel and will expect a comparable experience²⁹

• Integration with the existing stack, so the warehouses and reports that read MDS today can read the replacement

A data catalog is not a direct substitute. Catalogs support data discovery, documentation, and governance of data sets, but a replacement has to host editable lists with rules and versions. 

Some MDS entities are code lists that can be handled by something simpler, such as a governed lookup table. Identifying them before selecting a replacement makes the migration easier.