Consolidate systems

A typical mid-sized B2B stack has a shop, a separate PIM, a search product, a CMS, a middleware tool for the ERP connection, a BI tool for the reports, a handful of plugins, and a maintenance contract for each. Every one of them was a reasonable purchase on the day it was bought. Together they are the reason a change to a product attribute takes six weeks and involves four people who do not report to each other.

Why this is harder than it sounds

The costs of a fragmented stack sit almost entirely in the seams, and no budget line is called "seams". Licences are visible and comparatively small. What is invisible is that a single change (adding a filterable attribute, say) has to be made in the PIM, mapped in the middleware, re-indexed in the search product, templated in the CMS, and then regression-tested across all four, each with its own release calendar. A business case that counts only licence savings understates the benefit and, awkwardly, understates the effort too.

The failure mode is specific and worth memorising: consolidation fails when two systems keep writing the same field. It rarely fails loudly. The new platform and the legacy system both update the description, one of them wins depending on sync order, and for three months nobody can explain why a description reverts overnight. Ownership has to be settled per entity and, where it matters, per field, before a single record is migrated.

Then there is the archaeology. Somewhere in the stack is a plugin written in 2018 by a developer who has left, which nobody can explain, and which the invoices depend on. There is a scheduled export that feeds a customer's system and appears in no documentation. Migration is when these surface, and they surface as urgent. Budget time for finding them rather than for being surprised by them.

Two more things slow this down, and neither is technical. Systems have owners: the search product belongs to marketing, the PIM to product management, the middleware to IT. Removing a system removes something from someone's remit. And sunk cost speaks loudly about a platform bought two years ago on a five-year contract. Neither argument is illegitimate. Both are better handled in the open at the start than discovered as passive resistance in month four.

The levers

Establish what the platform already covers

Several things that are commonly bought separately are part of the platform, most notably a full PIM rather than a thin product table with a description field.

What good looks like: a written capability map. For each system you run, what it does, and whether the platform covers it, with an honest "no" where the answer is no.

What it depends on: doing this against your real requirements rather than against a feature list. A PIM comparison is decided by variants, reference entities and per-channel values, which is exactly where a superficial comparison stops looking.

1. How product information management works
2. The catalog data model
3. How storefronts work
4. Tenants, apps and packages
5. Apps and the Marketplace
6. Studios, what each part of the platform is for

Settle ownership before you migrate anything

What good looks like: a table with one row per entity (products, attributes, prices, stock, customers, orders, documents) naming exactly one system that owns it and one direction of flow. Where two systems must both hold a value, the table names which one wins.

What it depends on: a decision, not an analysis. The analysis is usually done in a morning; the decision is what takes weeks, because it reassigns responsibility between departments.

1. Deciding your system of record
2. Integration patterns
3. Field mapping

Migrate the data

Almost all of the work is preparing the files. Running the import is an afternoon.

What good looks like: you model the target structure first, map the legacy fields to it explicitly, migrate a representative slice, check it against the source, and only then run the whole set.

What it depends on: having designed the target data model. Importing a legacy structure unchanged reproduces every compromise the old system forced on you, and you will be living with it for years.

1. Plan your data model
2. Attributes and attribute groups
3. Prepare your import file
4. Import products in bulk
5. Import prices in bulk
6. Edit many products at once

Decommission properly

This is the lever everyone skips, and skipping it is why so many consolidation programmes deliver a new system and none of the promised savings.

What good looks like: the old system is switched off on a named date, its interfaces are removed, its contract is cancelled before the renewal, and its accounts are revoked. "Left running read-only for a while" is the version that never ends.

1. Monitor your syncs
2. Common sync errors
3. Security and data protection
4. Subscription and billing

A sensible order

Phase 1: inventory and ownership map. List every system, every interface between them, every contract with its renewal date, and every entity with its owner. This phase produces no software change and it is the highest-value week of the programme: it is where you find the fields that two systems both write, the interface nobody knew existed, and the contract that renews in eleven weeks. It depends on nothing but access and honesty.

Phase 2: consolidate one domain, end to end. Almost always product data first, because everything else depends on it and because the PIM is usually the clearest overlap. Migrate it, run the old system in parallel for a defined and short period with the new one already authoritative, then cut over and decommission. One domain finished completely is worth more than four domains started, and it teaches you what the next one will cost.

Phase 3: the next domain, and the seams. Content, search, reporting, and the custom middleware. By this point the ownership map is real and the migration mechanics are known, so each subsequent domain is cheaper than the one before. Replace bespoke middleware with configured connectors last, when you already know exactly what it does. That knowledge is what Phase 2 bought you.

Common mistakes

• Migrating before deciding ownership. Two systems writing the same field is the defect that takes months to diagnose and a weekend to have prevented.
• A big-bang across all domains. Every dependency fails at once and nothing can be rolled back independently.
• Parallel running with no end date. Parallel operation costs more than either system alone, and as long as the old one is available someone will keep using it.
• Consolidating onto something that does not cover the capability. Check the hard parts (variants, per-channel values, customer-specific assortments) before you cancel anything.
• A business case built only on licences. The larger saving is coordination cost and change lead time. Measure those before you start or you will not be able to prove the benefit afterwards.
• Leaving the old system switched on. The savings are realised on the cancellation date, not on the go-live date.

How you know it is working

• Systems in the critical path of an order. Count them: if any one of them is down and an order cannot be placed or fulfilled, it is in the path. This is the headline number for this goal.
• Live interfaces you have to keep alive, counted individually. Each one is a thing that can break at 3 a.m.
• Fields written by more than one system. Target zero. Any non-zero number is a scheduled incident.
• Elapsed time to make a change that touches product data, measured from request to live. Time one real change before you start. This is the number the business will feel.
• Contracts retired, with dates. Name them. A consolidation programme with no cancelled contracts has not consolidated anything.
• Incidents per quarter attributable to inter-system synchronisation. This should fall roughly in proportion to the interface count. If it does not, the interfaces you removed were not the ones causing trouble.

Related goals

• Cut manual work: fewer seams means less rework, from the same root cause.
• Decide on real numbers: disagreeing numbers are usually a symptom of a fragmented stack.
• Publish a digital product catalog: the domain most consolidation programmes should start with.

What you're building

The ERP and finance stay where they are. The platform takes over the PIM, the prices the ERP does not own, the customer model, the order path and the storefront, and Integration Studio replaces the middleware between them. The old PIM, the CMS and the custom middleware are switched off on a date, with their contracts cancelled. What is still bought separately is named as such, with a reason.

flowchart LR
  ERP["Your ERP and finance"]
  subgraph IS["Integration Studio"]
    WF["Workflows and import profiles"]
    RUN["Runs and monitoring"]
  end
  subgraph CS["Commerce Studio"]
    P["Products: the PIM"]
    PR["Prices"]
    C["Customers"]
    O["Orders"]
    INV["Inventories"]
  end
  subgraph XS["Experience Studio"]
    SF["Storefront and pages"]
  end
  subgraph OFF["Switched off, contracts cancelled"]
    LPIM["Legacy PIM"]
    CMS["CMS"]
    MW["Custom middleware"]
  end
  ERP -- "articles, conditions, stock" --> WF
  WF --> P
  WF --> PR
  WF --> INV
  WF --> C
  P --> SF
  SF -- "order" --> O
  O --> WF
  WF -- "order" --> ERP
  WF --> RUN

What you need

• An inventory of every system, interface and contract renewal date — Deciding your system of record
• An ownership table: one owning system per entity, and per field where two systems hold a value — Integration patterns
• A capability map that says honestly what the platform covers and what stays — Tenants, apps and packages
• The target data model designed before any legacy record is loaded — Plan your data model
• An explicit mapping from every legacy field to the new model — Field mapping
• A dated decommissioning plan per system, agreed with the system's owner — Subscription and billing
• A baseline: one real product change timed from request to live, and the current interface count — The metrics that matter in B2B

Build it

1. List every system, every interface between them and every contract with its renewal date — Deciding your system of record
2. Write the ownership table per entity and, where two systems hold a value, per field — Integration patterns
3. Write the capability map against your real requirements: variants, per-channel values, customer assortments — How product information management works
4. Design the target product model before touching the legacy export — Plan your data model
5. Map every legacy field to the new model, explicitly — Prepare your import file
6. Migrate a representative slice and check it line by line against the source — Import
7. Run the full product import, then the price import — Import prices in bulk
8. Rebuild the ERP flows as workflows and import profiles, replacing the middleware routes one by one — Connect a system
9. Run the old system in parallel for a fixed, short period with the platform authoritative — Monitor your syncs
10. Cut the storefront over to the platform's catalogue and pages — Create a storefront
11. Switch the old system off, remove its interfaces, revoke its accounts, cancel the contract — Security and data protection
12. Repeat for the next domain: content, reporting, then the remaining middleware — Build a workflow
13. Re-measure change lead time, interface count and multi-writer fields against the baseline — Reports and exports

Decisions you'll need to make

Related product areas

• Commerce Studio: Products · Import · Families · Attributes · Price lists · Organizations · Orders
• Experience Studio: Sites · Pages · Themes · Domains
• Integration Studio: Credentials · Workflows · Runs · Import/export · SFTP server