Migrating from Stibo (STEP) to Golden Suite

Stibo is the PIM-plus-MDM legacy giant. If you only need the MDM half, here's how to extract it.

Stibo STEP is a Product Information Management (PIM) platform that grew an MDM module. If you bought Stibo for the PIM and the MDM piece is incidental — or if you're using Stibo for MDM and the PIM features are noise — Golden Suite handles the MDM half cleanly and lets you keep (or replace separately) the PIM half.

Read our Stibo comparison for the honest tradeoffs. Stibo's strengths are PIM-shaped: deep product-data modeling, multi-language catalog management, retailer integrations. None of that translates to Golden Suite. If you actually need PIM, this is the wrong migration.

What carries over

  • Your golden records (the MDM data). Customer, vendor, location records that Stibo MDM has produced — these export cleanly as CSV/JSON and re-import into Golden Suite.
  • Your survivorship rules. Stibo's rules translate; vocabulary is similar.
  • Your hierarchy / relationship data. If you've built customer-to-org-to-region hierarchies in Stibo, those land in golden_store.entities with the parent-child relationships intact (Golden Suite supports the same shape).

What doesn't carry over

  • PIM data. Product attributes, marketing copy, multi-language SKU descriptions, retailer-specific overrides — all of that is Stibo-shaped. Golden Suite is not a PIM. Don't try to force it in.
  • Stibo workflows. Stibo's STEP Workflow engine has its own state machine. Golden Suite's review queues are a much smaller surface — they cover "approve / split / merge" decisions on ambiguous matches, not multi-step approval chains.
  • Multi-language asset management. No equivalent.

The decision tree before migrating

Do you need PIM (multi-language SKUs, retailer-specific catalogs, asset management)?
├── Yes → Don't migrate. Stibo or a dedicated PIM (Akeneo, Salsify) is the right tool.
└── No  → Continue.

Do you have multi-step approval workflows for golden-record changes?
├── Yes → Migrate, but plan to either (a) implement light approval flows on top of Golden Suite's audit log, or (b) drop the workflow in favor of review queues. Costs 2-4 weeks of org change.
└── No  → Direct migration. Skip to "Sequence" below.

Migration sequence

A realistic timeline: 3–6 weeks depending on how much of your Stibo data is PIM-shaped (and therefore staying behind).

Week 1 — Source vs. golden inventory

  1. List every golden-record table in Stibo. Customer, vendor, location, account, contact — typical MDM shapes. Anything PIM-shaped (product, asset, category) is out of scope.
  2. List every upstream source. Stibo MDM ingests from Postgres, Salesforce, SAP, etc. — Golden Suite connects to the same sources.
  3. Decide your data plane. Are you migrating the upstream sources to feed Golden Suite directly (cleanest)? Or are you exporting Stibo's golden records as the input to Golden Suite (faster, but you lose the ability to re-resolve)? Both are valid; the first is what we recommend for anything you'll operate >6 months.

Week 2–3 — Parallel landing + rule translation

  1. Stand up Golden Suite with the same upstreams Stibo has. Run dedup with defaults; compare output to Stibo's golden table.
  2. Translate survivorship rules. Stibo's rule editor → Golden Suite's survivorship editor. Field by field.
  3. Handle hierarchies. If you have parent-child relationships in Stibo (customer → org → region), they live on golden_store.entities rows with a parent_id link. Run a migration script to translate Stibo's RELATIONSHIP records into that shape.

Week 4–5 — Cutover prep

  1. Run parallel for 2 weeks. Both Stibo and Golden Suite produce daily golden records. Downstream consumers read from a feed-multiplexer that pulls from Stibo today, switching to Golden Suite tomorrow.
  2. Audit diffs. Stibo and Golden Suite will disagree on some records — usually traceable to a survivorship rule that's expressed differently. Resolve before cutover.

Week 6 — Cutover

  1. Flip downstream feeds. Now reading from Golden Suite.
  2. Stibo stays running read-only for one month as fallback. If you don't need it, downgrade or cancel.
  3. Disentangle the PIM half. If you're keeping Stibo for PIM, the MDM module can usually be turned off without affecting the PIM side. Check with your Stibo account team for the right billing tier.

Common pitfalls

  • Mistaking PIM data for MDM data. Product records aren't customers — don't try to force them through Golden Suite's resolver. They'll match poorly and waste your time.
  • Underestimating the workflow gap. If your team genuinely relies on Stibo's multi-step approval chains, plan the org-change cost honestly. Some teams thrive on review queues alone; some need more structure.
  • Not separating the PIM teardown. If you only need MDM going forward, lots of Stibo-adjacent integrations (digital-asset feeds, retailer catalog dumps) can be turned off — but the team running them needs to know.

When NOT to migrate

  • You actually use Stibo's PIM features in production
  • You have a multi-step approval workflow with regulatory teeth (financial-services product approval, pharmaceutical labeling) that Golden Suite's review queues don't cover
  • You're mid-implementation; finish that first, then evaluate

For teams who bought Stibo for MDM and inherited PIM noise — or who outgrew the PIM features and are paying for both — separating them is a clean win.

Questions? Email ben@bensevern.dev or /enterprise.

← Migrating from Tamr to Golden SuiteMigrating from open-source dedupe to Golden Suite →