The most dangerous weekend in retail IT — how to orchestrate a major RMS upgrade with minimal downtime and maximum confidence.
Types of RMS Upgrades
Not all RMS upgrades are created equal. The complexity and risk vary dramatically:
In-Place Upgrades (Minor Patches)
For minor patches and point releases within the same major version, Oracle provides database scripts that are applied directly to the existing database.
The Process
- Download patch from Oracle Support (My Oracle Support / MOS)
- Review release notes — identify any pre-requisites, deprecated features, or breaking changes
- Take a full database backup — RMAN backup of the entire database
- Apply database scripts — run Oracle's upgrade SQL scripts in sequence
- Recompile invalid objects —
EXEC DBMS_UTILITY.COMPILE_SCHEMA('RMS13') - Apply application patches — deploy updated WebLogic/ADF/JET artifacts
- Run validation scripts — Oracle provides post-upgrade validation queries
- Smoke test — verify critical business flows (item creation, PO submission, batch execution)
Downtime Window
In-place patches typically require 2-6 hours of downtime:
- 30 min: Shutdown application, take backups
- 1-3 hours: Apply database scripts
- 30 min: Recompile, validate
- 30 min: Application deployment and restart
- 30 min: Smoke testing
Lift and Shift Migrations
Major version upgrades (v14 → v16, v16 → v19+) require a Lift and Shift strategy because the database schema changes are too extensive for in-place scripts.
The Approach
┌──────────────┐ ┌──────────────┐
│ SOURCE │ │ TARGET │
│ (Legacy │ DATA │ (New │
│ RMS v14) │ CONVERSION │ RMS v19+) │
│ │ APPLICATION │ │
│ Production │ (DCA) │ Clean │
│ Database │────────────────▶ │ Install │
│ │ │ │
│ 15 years of │ Extract ──▶ │ Base schema │
│ data │ Transform ──▶ │ + Extension │
│ │ Load ──▶ │ schema │
└──────────────┘ └──────────────┘
The Lift and Shift process runs over several months:
- Clean Target Environment: Install the new RMS version on a fresh database with no data — just the empty schema
- Configure Target: Set up SYSTEM_OPTIONS, organizational hierarchy, merchandise hierarchy, calendars, and all foundation data in the target
- Data Migration Waves: Over several months, static Master Data (Items, Suppliers, Locations) is extracted from the Legacy system, transformed, and loaded into the Target via the Data Conversion Application (DCA)
- The Cutover Weekend: The business stops processing in Legacy. A final delta sync of dynamic data (Inventory, Open POs) is loaded into the Target. Downstream integrations are pointed to the Target, and the system goes live
Data Cleansing Opportunity
A Lift and Shift is the perfect opportunity for data cleansing. Don't migrate 15 years of closed Purchase Orders to your new Cloud environment if you don't have to. Archive them to a data warehouse instead. Retailers typically reduce their active data volume by 40-60% during migration.
Data Conversion Application (DCA)
The Data Conversion Application (DCA) is Oracle's toolset for migrating data between RMS versions. It consists of:
DCA Components
- Extract Programs: Pro*C or PL/SQL programs that read data from the source database and write to flat files
- Transform Programs: Programs that map source data formats to target data formats (column name changes, data type changes, code translations)
- Load Programs: Programs that read the transformed flat files and load them into the target database's staging tables
- Validation Programs: Programs that validate loaded data against the target schema's constraints and business rules
Migration Entity Order
Data must be loaded in a specific sequence because of foreign key dependencies:
| Order | Entity | Dependency |
|---|---|---|
| 1 | Organizational Hierarchy | None (top of hierarchy) |
| 2 | Merchandise Hierarchy | Depends on Org Hierarchy |
| 3 | Calendar | None |
| 4 | Suppliers | Depends on Org Hierarchy |
| 5 | Locations (Stores/WH) | Depends on Org Hierarchy |
| 6 | Items | Depends on Merch Hierarchy, Suppliers |
| 7 | Item-Locations | Depends on Items, Locations |
| 8 | Pricing | Depends on Items, Locations |
| 9 | Purchase Orders | Depends on Items, Suppliers, Locations |
| 10 | Inventory (SOH) | Depends on Items, Locations |
The Cutover Weekend
The cutover weekend is the most intense period of the entire upgrade project. Here is a typical timeline:
Cutover Schedule
Friday 6:00 PM — Business Freeze:
- All stores complete end-of-day processing in legacy RMS
- Legacy RMS is set to read-only mode
- All batch processing halted
- Final backup of legacy database
Friday 9:00 PM — Dynamic Data Extraction:
- Extract current inventory positions (ITEM_LOC_SOH)
- Extract open Purchase Orders (ORDHEAD, ORDSKU)
- Extract in-transit shipments (SHIPMENT, SHIPSKU)
- Extract pending transfers (TSFHEAD, TSFDETAIL)
Saturday 2:00 AM — Data Load:
- Load dynamic data into target database via DCA
- Run validation programs
- Fix any data errors
Saturday 10:00 AM — Integration Cutover:
- Point Xstore (POS) → new Xcenter → new RMS
- Point RIB adapters to new RMS database
- Point RPCS (pricing) to new RMS
- Point ReIM (invoicing) to new RMS
- Point RPAS (planning) to new RMS data feeds
Saturday 2:00 PM — Smoke Testing:
- Create a test item in new RMS
- Create a test PO in new RMS
- Verify item flows to Xstore (appears on register)
- Process a test transaction at a test store
- Verify TLOG flows from Xstore → ReSA → new RMS
Sunday 8:00 AM — Extended Testing:
- Run a full batch cycle (nightly batch)
- Verify all integration points
- Test critical business processes with business users
Sunday 6:00 PM — Go / No-Go Decision:
- If all tests pass: GO — the system is live Monday morning
- If critical issues: NO-GO — revert to legacy (see rollback strategy below)
Rollback Strategies
Every upgrade must have a tested rollback plan:
Short-Term Rollback (In-Place Patches)
- Restore the RMAN database backup taken before the patch
- Redeploy the previous application version
- Rollback window: Must be executed within the maintenance window (before business operations resume)
Long-Term Rollback (Lift and Shift)
- Keep the legacy environment running in parallel for 2-4 weeks after go-live
- If critical issues are discovered, revert all integration endpoints back to the legacy system
- Any transactions processed in the new system during the parallel period must be reconciled
- Rollback window: 2-4 weeks post go-live
The Point of No Return
After the parallel run period, the legacy environment is decommissioned. Any issues discovered after this point must be resolved in the new environment — there is no going back. This makes the parallel run period extremely critical for catching edge cases.
Integration Testing
Integration testing for an RMS upgrade must cover every data flow between RMS and downstream systems:
| Integration | Test |
|---|---|
| RMS → RPCS | Create a price change in RMS; verify it appears in RPCS |
| RMS → Xstore | Range an item to a store; verify it appears on the register |
| Xstore → ReSA → RMS | Process a sale; verify TLOG reaches ReSA and sales update RMS SOH |
| RMS → ReIM | Create and receive a PO; verify the invoice matching data is available |
| RMS → RPAS | Verify sales history and inventory data feed to the planning system |
| RMS → Allocation | Create an allocation; verify transfer documents are generated |
Upgrade Best Practices
Important Gotchas
- !Perform at least 3 full dress rehearsals of the cutover weekend before the actual go-live. Each rehearsal should follow the exact cutover timeline with real data volumes.
- !Never skip the parallel run period. Two weeks of parallel operation costs far less than a failed production cutover with no rollback option.
- !Data cleansing should happen BEFORE migration, not during. Trying to fix data quality issues during the cutover weekend adds risk and extends the downtime window.
- !Identify your top 20 most critical business processes and build automated regression tests for each. These tests run after every patch and after cutover to verify the system is functional.
- !Cutover weekends fail most often because of integration issues, not database migration issues. Invest heavily in integration testing — every RIB adapter, every REST API endpoint, every batch feed.
Key Takeaways
- Minor upgrades are done in-place via database scripts with 2-6 hours of downtime.
- Major upgrades (v14 → v16, v16 → v19+) require Lift and Shift data migration using DCA.
- DCA migrates data in a specific entity order respecting foreign key dependencies.
- Cutover weekends require intense orchestration — from business freeze Friday through go/no-go decision Sunday.
- Every upgrade must have a tested rollback plan. Parallel run periods provide a safety net for 2-4 weeks post go-live.
- Integration testing is the most critical testing phase — more upgrades fail at integration points than at the database level.
