Modernizing Informatica Product 360: A Technical Blueprint for Moving P360 On-Premise to SaaS

A Product 360 estate is rarely the system anyone mentions at a board meeting, and it is almost always the system that stops a product launch when it breaks. It holds the attribute model that a decade of category managers have argued over, the enrichment workflows that supplier onboarding depends on, the syndication feeds that fill the web shop, and — in most estates we assess — several hundred customisations that nobody has read since the person who wrote them left. Modernizing it is not a platform upgrade. It is the controlled relocation of a live, contested, deeply integrated model of your commercial reality onto a runtime you no longer operate.

This paper is a working blueprint for that move: from Informatica MDM – Product 360 on-premise to Product 360 SaaS on the Informatica Intelligent Data Management Cloud. It is written for the architect who has to sequence the work, the delivery lead who has to size it, and the data owner who has to sign that nothing was lost. It assumes you already know what a catalog, a structure mapping, a timeline and a characteristic are. Where the plan turns on vendor specifics that shift release to release, it says so rather than pretending an article can substitute for the current Product Availability Matrix and your own sandbox.

1. The decision you are actually making

Salesforce completed its acquisition of Informatica on 18 November 2025, and that single fact has shaped every P360 conversation since — mostly unhelpfully. Competing PIM vendors have been running a disciplined campaign aimed straight at Product 360 accounts. The pitch is that roadmap attention will drift toward Salesforce-first integrations, that support relationships will churn through reorganisation, and that licensing will get more complicated before it gets simpler. Those are legitimate things to watch. None of them is, by itself, a reason to discard a working product model and eight years of enrichment logic.

The defensible position is narrower and more useful. The on-premise Product 360 runtime is no longer where the product's investment is going. Informatica now positions Product 360 as an agentic-AI PIM delivered as SaaS, with multidomain MDM, supplier onboarding and channel syndication presented as a connected cloud estate rather than a set of installable servers. Whatever the ownership structure does over the next three years, the gravity of the roadmap points one way. Planning as though your on-premise release will keep pace for another five years is the riskiest assumption available to you — riskier than migrating, and considerably riskier than deciding not to.

There are four honest options, and only one of them is usually wrong for a given organisation. Rehosting deserves particular scrutiny: moving the same on-premise stack onto cloud infrastructure or containers is infrastructure modernization wearing an application modernization badge. It buys runway and it can genuinely reduce operational pain, but it changes nothing about the attribute model, the customisation debt, or the release you are stranded on.

The rest of this paper assumes the third path. It is the one with the most technical substance and the one where most programmes get the sequencing wrong.

2. What you actually own: the anatomy of a P360 estate

Before anyone draws a target architecture, the team needs an unsentimental picture of the current one. A classic Product 360 deployment is a four-tier system whose tiers fail in very different ways, and the migration plan is largely a story about what happens to each of them.

The presentation tier is the one your users will feel. Long-tenured estates run most serious stewardship through the Rich Client, a desktop application with keyboard-driven bulk editing that experienced category managers are genuinely fast in. The browser interfaces cover media management, lighter stewardship and supplier interaction. Any move to SaaS is a move to the browser, permanently, and the productivity dip in the first eight weeks is real. Programmes that treat this as a training footnote lose their most valuable stewards to workarounds — shadow spreadsheets that quietly become the new system of record.

The application tier is where the platform does its thinking: core services and APIs, the process engine that carries enrichment and approval workflows with their human tasks and escalations, and the job and import machinery that runs structure mappings against inbound files. In SaaS this tier stops being yours. You lose the ability to tune a JVM at two in the morning and you gain the obligation to design within published limits — API rate ceilings, job concurrency, payload sizes. That trade is the single largest architectural change in the whole programme, and section 12 argues it deserves a dedicated test track rather than a paragraph in the design document.

The data tier holds the repository database, the search index that makes faceted stewardship usable, and the asset file store. Two things about it consistently surprise teams. First, the repository is not a clean relational representation of your product model — it is a platform-internal structure whose shape varies by version, which is why extraction should go through supported export paths rather than SQL archaeology. Second, the asset store is almost always larger, messier and more entangled than the item data, and it is routinely scheduled as a two-week task at the end of the plan. Section 8 exists because that estimate is wrong roughly every time.

The integration tier is the estate's true perimeter. Most on-premise P360 deployments accumulated point-to-point interfaces over years: a nightly material master feed from ERP, supplier price files in three dialects of Excel, a catalog export the web shop depends on, a syndication job for each marketplace, and a set of database extracts that finance discovered and now relies on. Nobody owns the full list. Producing it is the first genuinely hard deliverable of the programme.

The customisation iceberg

The dashed box in Figure 1 is small and it will consume a third of your budget. Mature P360 estates carry custom Java extensions, server-side scripts, bespoke validation logic, custom import handlers and UI adaptations. These were written because the platform did not do something in 2018. Three questions decide the fate of each one, and they need answering item by item rather than in aggregate: does the target platform now do this natively; is the behaviour still required by a live business process; and if it is required and not native, does it belong in a configured rule, an integration process, or an external service the PIM calls?

In assessments we have run, the typical split is roughly a third of customisations now redundant against native capability, a third re-expressible as configuration or rules, and a third genuinely bespoke logic needing a new home outside the PIM. That last third is the one to design deliberately. A SaaS PIM with an externalised rules service is a sound architecture; a SaaS PIM that people quietly work around because a rule did not survive is not.

3. Phase 0: the inventory nobody wants to do

Every failed PIM migration we have been asked to review shares one root cause: the plan was sized against the system people described, not the system that exists. Phase 0 is four to eight weeks of unglamorous archaeology that produces a machine-readable inventory of the estate. It is the cheapest insurance in the programme, and it is the phase most often compressed to make a steering-committee date.

Two columns in that table do the heavy lifting and both are usage statistics rather than definitions. Fill rate on attributes and last-run dates on mappings are what let you argue, with evidence rather than instinct, that a third of the estate does not need to move. That argument is worth more to the schedule than any tooling decision you will make.

Scoring the estate

Once the inventory exists, score it. The point is not precision — it is to make the shape of the programme legible to people who will fund it, and to stop the conversation where a 400-attribute estate with two interfaces is planned like an 8,000-attribute estate with forty.

A total of 7–14 describes an estate that can move in two or three waves inside nine months. From 15 to 25 you are running a full programme with a dedicated model workstream and a separate integration track. Above 25, the honest recommendation is to split the migration from the rationalisation: get to SaaS with a deliberately reduced scope first, then fix the model in place where iteration is cheap, rather than trying to do both against a cutover date.

Phase 0 should end with an artefact, not a slide deck. A manifest in version control, regenerated on a schedule so it stays true while the programme runs, is the difference between a plan and an opinion.

# Regenerated weekly from the source system. Under version control so the
# programme can see drift: every new attribute added during migration is
# scope that arrived after the estimate was signed.

estate:
  source_release: "<current P360 version>"
  snapshot_taken: 2026-08-15

model:
  catalogs:            { count: 12,   in_scope: 7 }
  structures:          { count: 34,   in_scope: 21 }
  attributes:
    declared:          4180
    fill_rate_over_5pct: 1640    # the real migration target
    unused_24_months:  1890      # retire, do not migrate
    ambiguous:          650      # needs a data-owner decision
  hierarchies:         { trees: 6, nodes: 18400, overlapping: true }
  locales:             [en_US, en_GB, de_DE, fr_FR, es_ES, it_IT]

logic:
  workflows:
    defined:           28
    instances_12mo:    { over_1000: 6, under_50: 17, zero: 5 }
  validation_rules:
    defined:           412
    standing_violations_over_1000: 38   # controls in name only
  custom_code:
    java_classes:      210
    entry_points:      { import_handlers: 9, ui_extensions: 14, server_hooks: 22 }
    external_calls:    [pricing-service, tax-engine, legacy-classification-api]
    test_coverage:     none

assets:
  files:               812000
  bytes:               6.4e12
  orphaned:            96000        # referenced by nothing
  formats:             { jpg: 0.61, png: 0.18, pdf: 0.14, video: 0.04, other: 0.03 }

interfaces:
  inbound:  [erp_material_master, supplier_price_files, classification_feed]
  outbound: [webshop_catalog, marketplace_a, marketplace_b, print_export, finance_extract]
  undocumented_db_readers: 4        # found via grants, not documentation

people:
  named_users:         310
  active_90d:          148          # licence and training sizing uses this
  rich_client_heavy:   22           # highest-risk adoption cohort

4. The target: what Product 360 SaaS actually changes

The target is not the same system with someone else's hostname. Informatica describes Product 360 SaaS as a cloud-native product MDM with a configurable stewardship interface, embedded integration for onboarding data at varying latencies, a workflow engine with human task interaction, built-in reference lookup and crosswalk handling, AI-assisted matching alongside a rules-based match engine, real-time validation and survivorship scoring, and dashboards over the lot. Read that list back against Figure 1 and the architectural shift is plain: capabilities you previously assembled from a server, a process engine, an import server and a heap of Java now arrive as configured features of a subscription, with the boundaries drawn by the vendor rather than by your platform team.

That is a good trade for most organisations and a genuinely constraining one for a few. The design question stops being how do we build this and becomes where does each behaviour now live — inside the PIM as configuration, in the integration layer, in a governance service, or in something of your own that the PIM calls over an API.

Three parts of Figure 2 deserve argument rather than acceptance. The integration layer is the first: moving inbound onboarding into cloud integration services rather than rebuilding custom import handlers is the decision that makes the estate maintainable afterwards, and it is the one most often skipped because the old handlers 'already work'. They do not already work — they already work on a runtime you are leaving.

The governance rail is the second. On-premise estates typically encode ownership, policy and quality thresholds inside the PIM itself, in validation rules and role definitions. Pulling catalog, lineage, quality scoring and policy into governance services alongside the PIM costs more in the design phase and pays back the first time someone asks which downstream channel a bad attribute reached. It also means the quality story survives the next platform change, which on current evidence will not be the last one.

The third is the dashed box. Every estate has logic that is genuinely yours — a pricing derivation, a regulatory classification, a competitor-mapping heuristic. Putting it in a service the PIM calls, with its own repository, tests and release cycle, converts your worst upgrade blocker into an ordinary piece of software. Programmes that instead try to force this logic back inside the SaaS platform generate the exact customisation debt they set out to escape.

The last row is the one to put in the business case, and it is not primarily a cost saving. A platform team that stops spending its week on patch cycles and index rebuilds is a team that can finally work on the attribute model, the quality scorecard and the channel readiness rules — the things that actually determine whether products launch on time.

5. The migration pattern: parallel build with reverse sync

Two patterns fail predictably. The big-bang cutover fails because a PIM is not a system you can freeze: suppliers keep sending files, categories keep launching products, and a three-month content freeze is a commercial decision no merchandising director will sign. Lift-and-shift fails for a simpler reason — it is not on offer. The SaaS runtime is not the on-premise runtime, so there is no image to move.

What works is a parallel build in which mastership moves category by category, with a reverse sync keeping the legacy platform fed for as long as any downstream consumer still reads from it. The new platform becomes the system of entry for a wave's categories on day one of that wave; the old platform degrades from system of record to system of reference, and finally to nothing. No freeze is ever required, because at any moment every category has exactly one system where stewards type.

Reverse sync is the part teams resist, because it means building an integration you intend to throw away. Build it anyway. It is typically two to four weeks of work and it converts the riskiest event in the programme — the moment a channel switches source — into something you can schedule per channel, verify, and reverse. Two rules make it safe: it must be strictly one-directional per category, so a category being mastered in SaaS is never written by a steward on-premise, and it must carry a provenance marker so that any record written by the sync is visibly not a human edit.

Wave selection follows a simple rule: the first wave should be commercially real but operationally forgiving. Not the flagship category, and not an abandoned corner nobody checks. A live category with an engaged owner, a manageable attribute set and one downstream channel gives you honest feedback within six weeks, which is the only thing that will tell you whether the rest of the estimate is fiction.

6. Migrate the model before you migrate the data

The single most consequential sentence in this paper is this one: do not migrate the model you have, migrate the model you should have. A P360 attribute dictionary is an archaeological record of every campaign, acquisition, marketplace integration and departed category manager of the last decade. Carrying it across intact means paying to move it, paying to test it, paying to train people on it, and then living with it on a platform where changing it is somebody else's release cycle.

The rationalisation is evidence-driven, not aesthetic. Fill rate, last-changed date and downstream consumption are the three signals. An attribute filled on under five per cent of items, unchanged for two years and read by no channel is not a business requirement, whatever anyone says in the workshop. Present the evidence per attribute to a named data owner, timebox the decision, and default to retire when the timebox expires. Programmes that instead run consensus workshops on four thousand attributes are still running them a year later.

Retired does not mean deleted. Archive the values into cold storage with a documented retrieval path before the on-premise instance is decommissioned. The cost is trivial and it removes the single most effective objection to rationalisation, which is the fear that a regulator or a lawsuit will one day ask for a value nobody thought was needed.

The bottom row deserves a dedicated test suite. Variant inheritance with per-child overrides is where two platforms most often disagree quietly: values look right on the parent, look right on a sampled child, and are wrong on the 4% of children where an override existed for a reason nobody remembers. Reconciliation by record count will not catch it. Only attribute-level comparison on the full child population will.

Hold the mapping itself as data rather than as a spreadsheet attachment. It is the contract between the model workstream and the migration engineers, it changes weekly, and it needs a review history.

{
  "$schema": "./mapping.schema.json",
  "wave": 1,
  "reviewed_by": "category-owner:power-tools",
  "mappings": [
    {
      "source": "ITEM.TechSpec_VoltageText",
      "disposition": "migrate",
      "target": "product.electrical.voltage",
      "target_type": "decimal",
      "unit": "V",
      "transform": "parse_numeric_with_unit",
      "on_parse_failure": "quarantine",
      "notes": "Free text in source: '230V', '230 volt', '230-240V'. 4.1% unparseable -> steward queue."
    },
    {
      "source": "ITEM.LegacyPromoFlag_2019",
      "disposition": "retire",
      "fill_rate": 0.004,
      "last_changed": "2021-03-11",
      "downstream_consumers": [],
      "archive_to": "s3://p360-archive/wave1/legacy_promo_flag/",
      "approved_by": "data-owner:merchandising",
      "approved_on": "2026-07-29"
    },
    {
      "source": "ITEM.MarketingCopy_LONG",
      "disposition": "migrate",
      "target": "product.content.longDescription",
      "locale_qualified": true,
      "fallback": "explicit",
      "notes": "Source inherited en_GB from en_US when empty. Target does not. 11,400 items need an explicit backfill before go-live or the UK shop renders blank."
    },
    {
      "source": "ITEM.SupplierPartNo",
      "disposition": "migrate",
      "target": "product.identifiers.supplierPartNumber",
      "key_role": "crosswalk",
      "notes": "Used to re-link supplier records after load. Must survive verbatim - no trimming, no case folding."
    },
    {
      "source": "ITEM.Classification_Legacy",
      "disposition": "transform",
      "target": "product.classification.primary",
      "transform": "lookup:legacy_to_gpc.csv",
      "unmapped_nodes": 47,
      "blocking": true,
      "notes": "Wave cannot load until all 47 unmapped nodes have a decision."
    }
  ]
}

7. Moving the data: mechanics that decide whether the load is repeatable

Extraction should go through supported export paths rather than direct reads of the repository schema. This is not purity — it is that the repository layout is platform-internal and version-dependent, so SQL written against it is a liability that breaks on the next patch and produces subtly wrong results in the meantime, particularly around inheritance, effective dating and localised fallbacks that the application resolves at read time. Extract through the application and you get the values the business actually sees.

Between the two platforms, build a staging area you own — a schema or object store with your own model, your own keys and your own history. Every serious migration ends up needing to answer 'what did we send, when, and what came back', and a staging layer is the only place that question has an answer. It also lets you re-run a load without re-extracting, which you will do more times than the plan assumes.

Keys and crosswalks

Decide the identity strategy in week one and write it down, because everything downstream inherits it. Three identifiers matter and they are routinely conflated: the source system key from ERP or the supplier, the on-premise internal identifier, and the identifier the new platform will assign. Keep all three in a crosswalk table for the life of the programme and for at least a year after. The crosswalk is what makes reverse sync possible, what makes reconciliation meaningful, and what lets you answer a support ticket in 2028 about where a particular record came from.

Never let the new platform's generated identifier leak into a downstream contract during the transition. Channels should key on the business identifier — SKU, GTIN, supplier part number — so that a re-load, a rollback or a re-match does not orphan a marketplace listing.

Load order

Referential integrity dictates a strict sequence. Violating it produces the characteristic failure mode of PIM migrations: a load that reports success while silently dropping every value whose reference target did not yet exist.

1. Reference data first — value lists, units, locales, enumerations. Nothing that references them can be trusted until they are complete and normalised.
2. Classification schemes and hierarchy nodes, including the unmapped-node decisions from Table 5. An unmapped node is a blocking defect, not a warning.
3. Suppliers and organisational entities, so that item records can attach to a real counterparty rather than a placeholder that later needs merging.
4. Parent or family records, then child and variant records, so inheritance resolves in the right direction.
5. Attribute values, in batches aligned to the mapping file so a failure is attributable to a mapping rather than to 'the load'.
6. Relationships — accessories, cross-sells, replacements — which can only be built once both ends exist.
7. Asset references, after the binaries have landed and their target URLs are stable.
8. Workflow state — and in most cases, deliberately not. See section 9.

Every load step must be idempotent. Re-running the same batch twice has to produce the same state, not duplicated multi-values or a second set of relationships. This one property is what turns a nerve-wracking cutover into a rehearsable one, and it is worth refusing to start the first wave without it.

Deltas and the throughput arithmetic

The catalog keeps moving during the migration, so every wave needs an initial bulk load followed by delta cycles until that wave's mastership flips. Capture deltas from the source application's change tracking rather than by diffing extracts — a diff cannot see a value that was changed and changed back, and it cannot see a deletion at all.

Do the arithmetic early, because it usually reorders the plan. Take your item count multiplied by average attributes per item, divide by the throughput your target actually sustains within its published concurrency and rate limits, and compare the answer to the window you have. Teams routinely discover that a full reload takes 40 hours rather than the assumed 4, which means the cutover weekend must be built around deltas, not a fresh load. Measure this in the sandbox during Phase 0. It is the cheapest number to get and the most expensive one to guess.

8. Digital assets: the workstream that is always underestimated

Item data is finite and structured. Assets are neither. A mid-size estate carries several hundred thousand to a few million files, a meaningful fraction orphaned, another fraction duplicated under different names, renditions generated by rules nobody has read, and links that resolve by filename convention rather than by identifier. Plans that allocate two weeks at the end are the plans that slip.

The first decision is strategic rather than technical: does the PIM own the assets, or does an external DAM own them and the PIM reference them? Retailers with heavy campaign and video workflows are usually better served by an external DAM with the PIM holding references, because the asset lifecycle is driven by marketing rather than by product. Manufacturers and distributors whose assets are mostly product photography and datasheets are usually better served by keeping them native, because the value is in the tight coupling to the item. Deciding this after the migration has started is expensive; deciding it during Phase 0 costs a workshop.

One practical note that saves a week of confusion: verify a sample of migrated assets by checksum, not by opening them. Renditions regenerated with a different encoder are visually identical and byte-different, which is fine, while a truncated transfer is byte-different and also visually identical until someone zooms in. Checksums on masters plus dimension-and-format assertions on renditions is the combination that actually proves the transfer.

9. Workflows and business rules: re-express, do not transcribe

Workflow migration goes wrong when a team treats the existing process diagram as the requirement. It is not the requirement; it is one platform's encoding of a requirement, shaped by what that platform could do in the year it was built. The requirement is the business intent: who must approve what, under which conditions, with what evidence, and what happens when they do not respond.

Start from the instance statistics in the Phase 0 manifest. A typical estate has twenty-eight defined workflows of which six carry almost all the volume, seventeen fire occasionally, and five have not run in a year. Migrate the six properly, review the seventeen with their owners, and delete the five. Then, for each surviving workflow, write the intent as a short paragraph and rebuild from that paragraph rather than from the diagram. Teams that do this consistently end up with fewer, simpler processes and stewards who understand them.

In-flight instances are their own decision, and the default should be to drain rather than migrate. Migrating live workflow state between platforms is disproportionately expensive and fragile, since it means recreating tokens, assignments, timers and history in an engine with different semantics. Announce a date after which no new instances start on the old platform, let the queue drain, and handle the residue manually. For long-running processes such as seasonal supplier onboarding, the residue may be a few hundred items and a fortnight of steward attention — far cheaper than the engineering alternative.

Rules deserve a taxonomy before they are touched. Blocking rules prevent bad data entering and belong in the platform where the data is entered. Measurement rules describe quality and belong in the quality layer where they can be scored and trended without stopping anyone's work. Derivation rules calculate values and belong wherever the inputs live, which is often not the PIM at all. Sorting four hundred rules into these three buckets typically retires a quarter of them outright — particularly the ones with tens of thousands of standing violations, which are not controls but unresolved backlogs wearing a control's clothing.

10. Integration cutover: strangle, do not switch

The integration perimeter is where a technically sound migration becomes a visible business incident. Every interface should move on its own schedule, behind a routing layer, with a documented way back. Cutting all of them on one weekend concentrates every unknown into the same forty-eight hours, which is precisely the wrong shape of risk for a system that feeds revenue channels.

The routing layer does not need to be elaborate. For file-based interfaces it is a directory and a switch; for API consumers it is a façade endpoint whose backing system is configuration. What matters is that changing a consumer's source is a config change made by one person in minutes, and reversible by the same person in the same minutes, rather than a code deployment negotiated with another team.

The last row is a deliberate technique and worth defending to a nervous steering committee. Revoking a shared database account on an announced date, with the platform team on standby to restore it in minutes, discovers undocumented consumers faster and far more safely than any documentation exercise. Doing it in month two costs an afternoon. Discovering the same consumer during cutover weekend costs the cutover.

Two properties make the whole perimeter survivable. Every outbound message needs a stable business key and a version so a consumer can detect and discard replays. Every inbound interface needs to be replayable from a retained source file or event log, so recovery after a failed load is a re-run rather than a request to a supplier for yesterday's file.

11. Proving nothing was lost: the reconciliation harness

Sooner or later a category manager will open a product in the new system and say a value is wrong. What happens next determines whether the programme keeps its mandate. If the answer is a week of manual investigation, confidence drains and stewards start keeping their own spreadsheets. If the answer is a reconciliation report that already shows the value, its source, its transform and its verification status, the conversation takes four minutes.

Build the harness in wave 1 and run it on every load thereafter. It has four layers, and the common mistake is stopping after the first — record counts match beautifully while values are quietly wrong.

Layer two is where the engineering effort belongs, and it is affordable if you compare hashes rather than values. Normalise both sides into the staging model — trimmed, case-folded where the attribute is case-insensitive, units converted, locale-qualified — then hash per record and compare. Mismatches are then investigated as values; matches cost nothing to prove.

-- Layer 2. Both sides normalised into staging first, so a difference here
-- is a real difference and not a formatting artefact. Run per wave, per load.

WITH src AS (
  SELECT business_key,
         attribute_code,
         locale,
         normalised_value
  FROM   stg_legacy_values
  WHERE  wave = :wave
    AND  attribute_code IN (SELECT attribute_code
                            FROM   mapping
                            WHERE  disposition = 'migrate')
),
tgt AS (
  SELECT business_key,
         attribute_code,
         locale,
         normalised_value
  FROM   stg_saas_values
  WHERE  wave = :wave
),
joined AS (
  SELECT COALESCE(s.business_key, t.business_key)   AS business_key,
         COALESCE(s.attribute_code, t.attribute_code) AS attribute_code,
         COALESCE(s.locale, t.locale)                AS locale,
         s.normalised_value                          AS src_value,
         t.normalised_value                          AS tgt_value,
         CASE
           WHEN s.business_key IS NULL             THEN 'UNEXPECTED_IN_TARGET'
           WHEN t.business_key IS NULL             THEN 'MISSING_IN_TARGET'
           WHEN s.normalised_value IS NOT DISTINCT FROM t.normalised_value
                                                   THEN 'MATCH'
           WHEN t.normalised_value IS NULL         THEN 'LOST_VALUE'
           ELSE 'DIFFERENT'
         END AS verdict
  FROM   src s
  FULL OUTER JOIN tgt t
         ON  s.business_key   = t.business_key
         AND s.attribute_code = t.attribute_code
         AND s.locale         IS NOT DISTINCT FROM t.locale
)
SELECT verdict,
       attribute_code,
       locale,
       COUNT(*)                                            AS records,
       ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER (), 3)  AS pct_of_wave,
       MIN(business_key)                                   AS example_key
FROM   joined
WHERE  verdict <> 'MATCH'
GROUP  BY verdict, attribute_code, locale
ORDER  BY records DESC;

-- Gate: LOST_VALUE and MISSING_IN_TARGET must be zero before the wave's
-- mastership flips. DIFFERENT is allowed only where the mapping declares a
-- transform, and each such attribute needs a signed expectation on file.

Layer three is the one that ends arguments. Generate the channel export from both platforms for the same population and diff the files. A byte-identical web shop export is a claim no stakeholder can dispute, and where the diff is non-empty it names the exact field rather than gesturing at the migration. It also catches an entire class of defect that record-level comparison misses — sort order, delimiter handling, character-set edge cases and truncation — all of which are invisible in the data and extremely visible on a product page.

12. The non-functional track nobody schedules

On-premise, non-functional problems were solved by adding hardware or tuning a runtime. Neither lever exists now, and the constraints are published rather than negotiable, so they have to be designed for. Give this its own track from wave 1 with four questions it must answer in the sandbox, using production-shaped volumes rather than a test extract of a thousand items.

• How long does a full reload of the largest wave take within the platform's concurrency and rate limits? This number sets the entire cutover design, and it is the most common source of a late plan change.
• What does steward search feel like at full catalog volume, with your facets, on your worst-case category? Search responsiveness is the difference between adoption and shadow spreadsheets, and it cannot be assessed on a small dataset.
• What happens when the nightly ERP feed, a large supplier import and a syndication run collide at 02:00? Contention that an on-premise job server absorbed will now queue against a shared limit.
• What is the recovery path when a load half-completes? Idempotent re-run, documented and rehearsed, or a support ticket and a wait — and you need to know which before you depend on the answer.

Where a limit genuinely does not fit the requirement, raise it with the vendor during design, in writing, with numbers. That conversation goes well six months before go-live and badly the week after.

13. The cutover: a runbook, not a weekend of heroics

Because mastership has moved wave by wave, the final cutover is a smaller event than it would be in a big-bang programme — but it is still the moment the legacy platform stops being authoritative for anything. It should be boring, and boring is a product of rehearsal. Run the full sequence at least twice against a production-shaped environment, timing each step, before the real one.

Note what is absent from that runbook: a step called 'decommission the old platform'. Keep it running, read-only, for at least a full business cycle — a quarter in most organisations, a full season in retail. The licence and infrastructure cost of three extra months is trivial against the value of being able to answer, definitively, what a record looked like before. The team will also want it during hypercare more often than anyone predicts.

14. The part that is not technical

A PIM migration is judged by stewards, and stewards judge it in the first fortnight. The cohort to worry about is the small group of long-tenured power users who live in the Rich Client, know every keyboard shortcut, and maintain the categories with the highest revenue. Their productivity will drop when they move to a browser, and their opinion will set the tone for everyone else.

Three interventions consistently pay for themselves. Bring the power users into view design during wave 1 rather than showing them the result — the layouts they ask for are usually better and their endorsement is worth more than any training session. Measure the productivity dip openly, in items enriched per hour, and publish the recovery curve, because a named and tracked dip is a project phase while an unacknowledged one is evidence that the new system is worse. And staff hypercare with people who sit near the stewards for the first two weeks, not a ticket queue.

Role mapping deserves the same scepticism as attribute mapping. Migrating the existing role matrix wholesale carries a decade of accumulated exceptions into a system where permissions may be modelled differently. Use the 90-day login activity from Phase 0: define roles around what people actually did, then handle the genuine exceptions individually.

15. Risk register

These are the risks that actually materialise, ordered roughly by how often we have watched them do so. Note that only two are technical.

16. Sizing and sequence

Estimates below are planning anchors, not quotes — they assume the model rationalisation runs inside the programme rather than as a separate initiative, and they exclude licence cost. The team sizes are core delivery only; category owners, stewards and channel owners are additional and their availability is usually the real constraint.

17. Ten positions worth defending

If this paper collapsed to a single page for a steering committee, it would be these ten. Each one is contested in most programmes, and each one is where we have seen the difference between a migration that lands and one that limps.

1. Do not migrate the model you have. Rationalise on evidence — fill rate, last-changed date, downstream consumption — with a named owner and a timebox per decision.
2. Protect Phase 0. Four to eight weeks of inventory is the cheapest risk reduction available, and the first thing a schedule pressure will try to remove.
3. Build the reverse sync even though you will delete it. It is what buys the absence of a content freeze and turns channel cutover into a scheduled, reversible event.
4. Name where the surviving bespoke logic lives on day one. An externalised rules service is a design decision; discovering you need one in month eight is a rewrite.
5. Make every load idempotent before the first wave. This single property converts cutover from an act of courage into a rehearsed procedure.
6. Reconcile at attribute level across the full population, not by counts and samples. Counts match while values are wrong — that is the defining failure mode of PIM migrations.
7. Diff the channel output. A byte-identical export is the only evidence the business truly accepts, and it catches formatting defects no data comparison sees.
8. Measure throughput against real platform limits in the sandbox during Phase 0. Guessing this number is what forces a plan change in the final month.
9. Start the asset transfer in wave 1 whatever the cutover date says. Bandwidth does not negotiate, and the asset workstream is underestimated more reliably than any other.
10. Bring the power stewards in as co-designers in wave 1. Their endorsement is worth more than the training budget, and their disengagement is the failure mode no architecture prevents.

Closing

The uncomfortable truth about a Product 360 modernization is that the platform migration is the easy half. Moving items, assets and mappings between two systems is well-understood engineering with known failure modes and a reconciliation harness that can prove it worked. The hard half is deciding, category by category and attribute by attribute, what your product data is actually supposed to say — a question the on-premise estate let you avoid for a decade by simply adding another field.

That is also the argument for doing it now rather than deferring. The migration forces the conversation, and the organisations that come out of it well are the ones that treat the forcing as the point rather than as an obstacle to a go-live date. The platform question — which vendor, which roadmap, whose ownership — will keep moving, as it has for the last two years and will for the next five. A rationalised, documented, portable product model is the asset that survives whichever way it moves.