You run two or three Shopify stores. One per region, or one per brand, or one for retail and one for wholesale. Every product update has to happen two or three times. The product team starts in store A, copies to store B, and someone forgets store C. Metafields drift apart. Media files have different filenames in each store. Descriptions diverge over time. The team spends hours each week reconciling instead of selling.
This article is the engineering reality of multi-store Shopify catalogs, why the manual approach fails, and how I would build a PIM layer (Product Information Management) that keeps the stores in sync without replacing Shopify.
The Short Answer
Shopify does not offer a native PIM. Shopify B2B helps with multi-customer pricing inside one store. Shopify Plus offers Combined Listings and Markets for some multi-region cases. Neither is a PIM that owns the canonical product data and pushes it to multiple stores.
The fix is a small custom application that becomes the canonical source for product data. The product team edits in the PIM. The PIM pushes synced product data, metafields, media, and translations to each Shopify store via the Admin API. Stores can have store-specific overrides for price, region-specific copy, or local SKUs. The PIM tracks what was overridden and what was synced.
This is buildable in three to six weeks. It does not require Shopify Plus. It does not require replacing your existing storefronts.
Why Manual Or Plugin-Based Approaches Fail
Manual sync across stores. Works for ten products and one team member. Falls over at fifty products and any team turnover. Errors compound silently.
Excel-based product data with bulk imports. Spreadsheet exports from each store, manual reconciliation, bulk re-import. The reconciliation step is where data drifts because nobody is the source of truth.
Apps that sync products between Shopify stores. Most apps in this category sync core product fields and break on metafields, on media, on translations, or on store-specific overrides. The "almost-works" sync is worse than no sync because it produces false confidence.
Migrating to a PIM SaaS like Plytix or Salsify. Sometimes the right answer for very large catalogs. For mid-size stores, the SaaS cost and integration overhead exceed the cost of building a focused PIM layer that does what you actually need.
Combined Listings on Shopify Plus. Real, useful for multi-region cases where stores share most product data. Limited where stores have substantially different catalogs or where the override surface needs to be richer than what Combined Listings exposes.
How I Would Build The PIM Layer
Phase 1: Discovery (week zero)
Before building, I need to understand the catalog shape, the store differences, the product team's actual workflow, and the integration points.
What I do. Audit each store's product catalog. Identify what is the same across stores (the canonical fields) and what is different (the override surface). Walk through the product team's workflow: where do new products come in, where do they edit, where do approvals happen. Identify integration points: ERP, supplier feeds, image asset stores.
What you get. A written discovery report covering: the canonical data model, the override surface, the workflow, the integration points, and the build scope.
Phase 2: Canonical data model (week one)
The PIM has its own data model, separate from Shopify's. It has to handle every product attribute that any store needs, plus the override surface.
What I build.
- Core product entity. Title, description, vendor, type, tags, status, SKU, barcode, variants. The fields every store has.
- Metafield surface. Structured metafields with their value and their data type. The PIM is type-aware so we cannot push a string into a number field.
- Media. A canonical media library with images and videos, each tagged for use in specific stores or all stores. Filenames are consistent across stores.
- Translations. Per-locale fields for title, description, and key metafields. The PIM owns the canonical translations.
- Override surface. Per-store overrides for any field. Each override is recorded with its store, its value, the user who set it, and the timestamp. Stores receive their override values; everything not overridden inherits from canonical.
- Audit trail. Every change to canonical data and every override is logged.
Phase 3: Sync engine (week two)
The sync engine pushes canonical data plus per-store overrides to each Shopify store via the Admin GraphQL API.
What I build.
- Push pipeline. When canonical data changes, the affected stores are queued for sync. The push uses Shopify's GraphQL bulk operations where possible (large catalogs) and individual mutations for incremental updates (small changes).
- Idempotency. Each push is idempotent. Re-running a push does not corrupt state. Failures retry with backoff.
- Conflict detection. If a store-side change happened that the PIM did not initiate (someone edited directly in Shopify admin), the conflict is flagged for review, not silently overwritten.
- Selective sync. Some products are pushed to all stores. Some only to a subset. The PIM's store-assignment field controls which.
- Media sync. Media files are uploaded to each store's file storage. The PIM tracks the per-store URL so deletes do not orphan files.
- Metafield sync. Metafield definitions are created in each store if they do not exist. Values are pushed with type validation.
Phase 4: PIM admin UI (week two to four)
The product team needs to edit canonical data and review overrides. The admin UI is where they live.
What I build.
- Product list. Searchable, filterable, sortable. Bulk actions (status, store assignment, tag changes).
- Product editor. All canonical fields. Per-locale translations. Per-store overrides shown clearly so the team knows what is canonical and what is store-specific. Save validates against the data model before pushing.
- Media library. Upload, tag, organise. Image transformations for responsive variants if needed.
- Sync status. Per-product, per-store sync state. Last sync time, last error, last successful push. Failed syncs surface for retry or investigation.
- Audit log viewer. Searchable history of every change to canonical data and every override.
Phase 5: Webhook listeners (week four)
The PIM listens to webhooks from each Shopify store so we can detect store-side changes that need to be reconciled with canonical.
What I build.
- Subscriptions to
products/update,inventory_levels/update, andmetafield_definitions/updatefrom each store. - A reconciliation step that compares the incoming change to the PIM's expected state. Differences are flagged for the product team to review.
- An option to "promote" a store-side change to canonical, or to "revert" it back to canonical. Both paths recorded in the audit log.
Phase 6: Migration of existing catalog data (week four to five)
The PIM is empty until we migrate the existing data from one of the stores into it.
What I do. Pick the most authoritative store as the migration source. Pull all products into the PIM. Reconcile against the other stores. Surface differences as overrides or as data corrections. Validate that pushing from PIM to each store produces the same data we started with (a no-op push to verify).
Phase 7: Documented handover
You keep the PIM application, the database, the Shopify API credentials, the admin UI, and the runbook for support. The product team gets training on the new workflow.
Honest Variables That Change The Cost Shape
Store count. Two stores is a smaller engagement than five. Each store adds API calls, webhook subscriptions, and reconciliation surface.
Catalog size. A 200-SKU catalog migrates and syncs in minutes. A 50,000-SKU catalog needs careful bulk handling and may need staged migrations.
Metafield complexity. Stores with simple metafields are cheap. Stores with deeply nested metafield structures and many definitions add to the data model.
Media volume. Stores with thousands of images per product add storage and transfer time.
Translation scope. Two locales is straightforward. Ten locales with per-locale workflow approval is a larger engagement.
Existing custom code. Stores with theme-side or app-side custom code that depends on specific metafield names are a constraint we have to work with.
Plan. Standard Shopify works. Plus offers slightly better APIs and Combined Listings as a partial alternative; the discovery tells you whether it pays back.
Why I Wrote This
Most articles on "multi-store Shopify product sync" recommend an app from the App Store. This article exists because none of those apps build a real PIM and the engineering reality is well-defined. If you are running multi-store Shopify and the manual reconciliation is eating the product team's week, the technical assessment is the route in.