After a dozen RMS upgrades, our consultants have catalogued the 9 most dangerous configuration pitfalls that derail timelines and inflate costs.
Upgrading to Oracle Retail Merchandising System 23B should, in theory, be a well-trodden path. Oracle’s documentation is thorough, the support ecosystem is mature, and most retail IT teams have lived through at least one RMS version cycle. So why do so many 23B migrations still blow their budgets and miss their go-live dates?
The honest answer is that the traps aren’t in Oracle’s code — they’re in your data, your customisations, and your assumptions. After leading migrations for grocery chains, fashion groups, and specialty retailers across the Asia-Pacific and Middle East regions, our team has seen the same failure patterns repeat. Here are the nine that hurt the most.
Callout
Before you begin:
Run Oracle’s Pre-Upgrade Advisor tool against your current environment and retain the full output. Many teams skip this step, then spend weeks in post-migration firefighting tracing issues the tool would have flagged in minutes.
The 9 Traps
01 — Assuming your cost component structure is clean
RMS 23B tightens validation on cost component sequences. Legacy environments often have orphaned or duplicated component codes that silently pass old validation but fail on import. Audit your COST_COMP table before you touch the upgrade scripts.
02 — Migrating supplier records without normalising UDAs
User-defined attributes attached to suppliers accumulate over years and rarely get cleaned up. 23B enforces stricter UDA type constraints. We’ve seen 40,000-record supplier migrations abort at the 90% mark because of a single misconfigured UDA template.
03 — Underestimating the Oracle Integration Cloud delta
If your RMS talks to finance, WMS, or e-commerce via OIC, check every integration flow against the 23B API changelog. Several SOAP endpoints that were deprecated in 22B are now removed entirely. Teams relying on old integration playbooks get burned here every time.
04 — Running UAT on stale data snapshots
UAT environments seeded from three-month-old production extracts don’t reflect current inventory positions or active purchase orders. Defects that surface only in live data conditions get missed, then discovered on go-live weekend.
05 — Skipping the merchandise hierarchy reconciliation
23B introduces changes to how sub-class and class level attributes are inherited. If your hierarchy has grown organically over years, expect inconsistencies. A pre-migration hierarchy audit isn’t glamorous work, but it saves days of post-go-live patching.
06 — Treating custom RMS extensions as low-risk
Bespoke PL/SQL that worked fine in older versions can behave unpredictably after the 23B schema changes. Every customisation should be regression-tested in isolation before it touches the integrated environment.
07 — Missing the batch scheduler sequence changes
Oracle reordered several nightly batch dependencies in 23B. Teams that copy-paste their old batch schedules without reviewing Oracle’s updated Batch Process Guide end up with pricing and stock ledger jobs running out of sequence — often silently, with no immediate errors.
08 — Not training buyers before cutover
The 23B UI for purchase order approval and supplier cost management has changed meaningfully. Buyers who haven’t had hands-on training before go-live create a wave of support tickets that overwhelms your hypercare team at exactly the wrong moment.
09 — Skimping on the cutover dress rehearsal
A single end-to-end cutover rehearsal — ideally on a weekend, with your real data and real team — surfaces timing issues, access problems, and dependency gaps that no amount of planning documentation will catch. Every hour spent on rehearsal saves three in the actual cutover window.
The Bigger Picture
None of these traps are exotic. They’re repeatable, preventable, and almost always traced back to the same root cause: insufficient pre-migration discovery.
The teams that sail through 23B upgrades are the ones who spend 30% of their project timeline on assessment and data cleanup before a single upgrade script runs.
If you’re planning an RMS 23B migration in the next six months, start your pre-migration health check now. The cost of discovery is a fraction of the cost of a failed go-live. A structured RMS readiness assessment typically takes two to three weeks and surfaces the issues specific to your environment — not a generic checklist.