Product data readiness: What to do before your PIM system goes live

Where to start

Taking stock of what you have

Product data is typically scattered across more systems than any one team has full visibility into, and consolidating it without that visibility is how duplicates, conflicts, and missing attributes get migrated straight into your PIM. A data audit provides the baseline for every subsequent decision.

What to document in your audit:

• Every system that stores or maintains product data, including ERP, spreadsheets, supplier portals, and any shared drives or inboxes
• Which team owns each system, and what data they’re responsible for
• Where the same data appears in more than one system with different values
• Whether field names and definitions are consistent across systems
• Where data is incomplete, missing, or has no clear owner

Defining what a “Product” means in your organization

Most PIM implementations inherit ambiguity that different functions have carried for years, because merchandising, operations, e-commerce, and IT rarely start from the same definition of what a product is. Your data model can only be as precise as the agreement behind it.

Questions to align on before modeling:

• What is the base unit of a product in your organization, and is that definition consistent across all functions?
• How do you handle variants, and which attributes define a separate SKU versus a product option?
• Do packaging levels get their own SKUs, or are they treated as logistics units attached to a sellable SKU?
• Which system holds the authoritative product identifier, and is it used consistently across all other systems?
• Are there product types in your catalog that follow different rules, and have those differences been documented?

Who you need

Identifying your data owners

PIM implementations that skip upfront ownership assignment consistently run into the same problem: attributes are populated inconsistently because multiple teams believe they’re responsible, or no one does because it was never decided. Before any modeling begins, each attribute group in your catalog must have a named owner.

Who to identify before you start:

• A data owner for each product category or attribute group
• A decision-maker who can resolve conflicts when ownership is disputed
• Someone accountable for data quality in each source system you identified in your audit
• A project lead who can coordinate across functions and keep the program moving

Getting IT, Compliance, and channel teams in the room

The decisions made in pre-PIM planning directly affect how your system integrates, which fields your model needs, and whether your data meets the requirements of the channels you publish to. Bringing IT, compliance, and channel owners in late means revisiting decisions that should have been made once.

Who else needs to be involved and why:

• IT, to map integrations between your PIM and connected systems, including ERP, DAM, and your e-commerce platform
• Compliance or regulatory teams, to identify attributes that carry legal, safety, or labeling requirements before the model is built
• Channel owners, to surface the specific field requirements, character limits, and format rules each destination demands
• Supplier or procurement teams, if incoming supplier data needs to conform to your model from the point of entry

What you need to build

Your data model

The data model is the structure your PIM enforces. It defines what a product record looks like, what attributes it carries, how variants relate to parent products, and how different product types are handled across your catalog. 

Most teams make the mistake of letting the PIM tool shape this decision, but the tool can only enforce a model you’ve already designed. Going into implementation without one means making structural decisions under time pressure, and those decisions are expensive to reverse mid-build.

What your data model needs to define:

• The core product entities in your catalog, including base products, variants, and any packaging or logistics units
• Which attributes sit at the parent product level versus the variant level
• Which attributes are the “varies by” dimensions that define separate SKUs, such as size, color, or configuration
• How different product types or categories are modeled, particularly where rules differ between them
• How your product identifiers map across systems, and which identifier is the authoritative key

Your taxonomy and attribute dictionary

A taxonomy without an attribute dictionary is a filing system with no rules about what goes inside each folder. The two need to be built together, because your category structure determines which attributes are required, which are optional, and which don’t apply at all.

What to define for each:

• A category hierarchy that reflects how your products are structured for both internal management and channel publishing
• A complete list of attributes per category, with clear names, definitions, and acceptable values
• Which attributes are mandatory before a product record can be published
• Controlled vocabularies for attributes where free-text input creates inconsistency, such as color, material, or unit of measure
• Who is responsible for maintaining each attribute group once the PIM is live

Your system-of-record map

Every attribute in your PIM has a source, and without a documented system-of-record map, that source defaults to the last person who touched the record. Your ERP owns pricing and logistics specifications. Your DAM owns digital assets. A spreadsheet should not own anything, but in most organizations, it currently does. 

Sorting out which system is the authoritative source for each attribute group before migration prevents duplicate ownership conflicts that are difficult to unwind after go-live.

What your system-of-record map needs to cover:

• The authoritative source system for each attribute or attribute group
• Which systems are allowed to contribute to a field, versus which one holds the master value
• How data flows between systems and in which direction
• Which legacy sources need to be retired or consolidated post-migration
• Where manual data entry will still be required, and who is accountable for it

Where your data needs to go

Mapping channel and destination requirements

Your data model should be shaped by where your data needs to be published, and most teams design it the other way around. Every channel your products appear on, whether that’s your own website, a marketplace, a retailer portal, or a print catalog, has its own required fields, character limits, format rules, and content standards. A model that isn’t built with those requirements in mind will produce records that need reworking before they can be published anywhere.

What to gather per channel before you model:

• The full list of required and optional fields for each destination
• Character limits and formatting rules for titles, descriptions, and key attributes
• Image specifications, including file type, resolution, and minimum number of assets required
• Any category-specific requirements, such as nutrition fields for food or safety data for industrial products
• The feed format each channel expects and how frequently it needs to be updated

Understanding your integration points

The PIM doesn’t operate in isolation. It connects to your ERP, DAM, e-commerce platform, and potentially marketplace connectors and retailer portals, and how you model your identifiers and system-of-record assignments depends directly on how those integrations are structured. 

If you leave integration mapping to the implementation phase regularly, you’ll find yourself revisiting data model decisions that you thought were settled.

What to document before implementation begins:

• Every system your PIM needs to connect to, and the direction data flows between them
• Which system sends data to the PIM, and which systems receive data from it
• How product identifiers are structured in each connected system and whether they align
• Where data transformations will be needed because the source and destination formats don’t match
• Which integrations are real-time and which are batch, since that affects how you manage updates and version control

How to prepare your data

Cleansing for portability, not perfection

The goal of pre-PIM data cleansing isn’t pristine data. It’s data that can move between systems, be compared across sources, and be validated against your model. Teams that treat cleansing as a cosmetic exercise before migration end up with the same structural problems inside a more expensive system. Focus your cleansing effort on what will block migration or break your model, and defer lower-priority cleanup to post-migration workflows.

What to prioritize in your cleansing effort:

• Duplicate records and how to resolve them, including which record survives and how legacy identifiers remain searchable
• Incomplete mandatory fields that will fail validation against your publish-readiness rules
• Values that fall outside your defined controlled vocabularies and need to be mapped or corrected
• Records with conflicting data across source systems that require a survivorship decision before migration
• Products without a clear authoritative identifier that need one assigned before they can be modeled

Normalizing to standard code sets

Inconsistent units, date formats, currency codes, and country references are among the most common sources of downstream errors in a PIM, and they’re also among the easiest to fix before migration. Standardizing these before any records move eliminates an entire category of validation failures and channel feed errors that would otherwise surface repeatedly after go-live.

Standard code sets to normalize before migration:

• Currency codes to ISO 4217
• Country codes to ISO 3166
• Language tags to BCP 47
• Units of measure to UN/CEFACT Recommendation 20
• Date formats to ISO 8601

Defining enrichment ownership

Enrichment is not a migration task. It’s an ongoing content supply chain that needs defined sources, contributors, and approval processes for every attribute in your model. Without that structure in place before go-live, enrichment defaults to whoever has access, resulting in inconsistent records and making quality measurement nearly impossible.

What to define per attribute before migration:

• The authoritative source for the attribute’s initial value
• Who is permitted to contribute to or update it after initial entry
• What are the allowable values or format requirements
• The approval process before an enriched value is considered publish-ready
• Which attributes are considered foundational and should not be changed once shared with trading partners or published to channels

How to govern it

Setting up ownership and accountability

Most PIM failures don’t happen at the technical level. They happen because no one defined who is accountable for what, and the system ends up enforcing a governance structure that was never actually agreed on. A governance charter and a RACI need to exist before go-live, not as documentation that follows implementation, but as the operational agreement that implementation is built around.

What your governance structure needs to cover:

• A named owner for every attribute group in your data model
• Clear accountability for data quality in each source system feeding the PIM
• A decision-making process for resolving conflicts when attribute values differ across systems
• Defined roles for who can create, edit, approve, and publish product records
• An escalation path for data quality issues that don’t get resolved at the contributor level

Building workflow gates before go-live

Workflow gates are the mechanism that turns governance from a policy into an enforced process. Without them, publish-readiness becomes a judgment call rather than a standard, and records go live with missing or incorrect data because no automated check stops them. Your gates need to be category-specific and channel-specific, because what’s required to publish an apparel product differs significantly from what’s required for an industrial component or a food product.

What your workflow gates need to enforce:

• Mandatory field completion before a record can move to the next stage in the workflow
• Validated values against your controlled vocabularies before approval
• Asset requirements met, including minimum image count and file specifications, before publish
• Compliance attribute completion for product types that carry regulatory or labeling requirements
• A defined approval step before any record is published to an external channel or shared with a trading partner

How to know you’re ready

Assessing your current data maturity

Where your data stands today determines what you can realistically do next, and most organizations overestimate their readiness by measuring it against the amount of data they have rather than how well it’s governed. A maturity assessment gives you an honest starting point and helps you set a timeline that reflects your actual state rather than an optimistic one.

Questions to assess your current maturity level:

• Do you have a documented attribute dictionary, or are definitions inconsistent across teams and systems?
• Are ownership and accountability assigned for each attribute group, or is maintenance ad hoc?
• Do you have repeatable workflows for product setup and enrichment, or does each product move through the process differently?
• Are you tracking data quality metrics such as completeness, accuracy, and timeliness, or are quality issues only discovered when something breaks?
• Is governance embedded in your day-to-day operations, or does it only get attention when there’s a problem?

What “ready enough” actually looks like

“Ready enough” doesn’t mean every record is perfect. It means your model is stable, your governance is operational, and your pilot category meets the completeness and quality thresholds your channels require. Teams that wait for perfect data before migrating never migrate. Teams that migrate before their model is stable spend implementation fixing structural decisions that should have been made in pre-work.

Indicators that you’re ready to begin a phased migration:

• Your canonical data model is documented and agreed on across functions
• Ownership is assigned for every attribute group and every source system
• Your workflow gates and approval processes are defined and tested
• Your pilot category meets the mandatory field requirements for at least one target channel
• Your governance charter and RACI are in place and understood by everyone involved

Sequencing what moves first

The first category you migrate sets the pattern for everything that follows, so the sequencing decision matters more than most teams give it credit for. Starting with your cleanest data, your highest-volume category, or your most critical channel are three different strategies with distinct logic, and the right choice depends on your specific goals and constraints.

How to think about migration sequencing:

• Start with a category where ownership is clear, data is relatively complete, and the channel requirements are well understood
• Avoid starting with your most complex category or your highest-risk channel, regardless of how much pressure there is to prioritize them
• Use the pilot migration to validate your model, your workflow gates, and your integration connections before scaling
• Document what breaks and what holds during the pilot, because those findings will reshape your approach for subsequent categories
• Treat the pilot as a test of your governance and process, not just a test of the tool

Start your PIM preparation the right way 

Getting your product data ready for a PIM is the kind of work that doesn’t feel urgent until you’re mid-implementation and rebuilding decisions that should have been made weeks earlier. The organizations that get this right treat pre-PIM preparation as a program in its own right, not a preliminary step. 

If you’ve worked through this guide and identified gaps in your data model, governance, or ownership structure, that’s exactly the point. Inriver is built to enforce the operating model you design into it, and our team can help you build that foundation before you go live.