Planning a Successful Redwood Migration: What to Decide Before You Start

When Oracle announced that all Supply Chain Management pages will move to Redwood UX by Release 27A, the conversation shifted instantly. 

Redwood was no longer optional. But more importantly, it was no longer something that could be approached casually. 

From delivery experience, one thing is consistent: Successful Redwood migrations are decided before they are built. 

This post outlines what organizations should consider early and a practical way to plan Redwood SCM adoption without unnecessary disruption.  

Why 27A Changes the Way Migration Should Be Planned 

• UI readiness becomes release-critical
• Partial adoption increases confusion and support effort 
• Change management must be planned, not reactive  

Redwood is no longer a UX experiment. It is part of core SCM operations.  

Decisions That Matter Early 

Teams that struggle during migration usually miss a few key early decisions: 

• Which personalizations still deliver business value 
• Where Classic workflows conflict with Redwood interaction patterns 
• How much standardization is acceptable across teams 
• How users will be guided through the change 
• Whether Redwood is being aligned with future AI plans  

Answering these upfront reduces rework and accelerates stabilization.  

A Five-Phase, Field-Tested Approach to Redwood SCM Adoption 

Across 20+ Redwood SCM migrations, a consistent adoption pattern has emerged—not as a rigid template, but as a practical framework. 

1. Fit–Gap Analysis

This phase establishes clarity. 

Existing UI personalizations, extensions, workflows, roles, and navigation are assessed to understand real impact. Oracle’s Redwood Helper Tool helps identify affected pages and required actions. 

The goal is not to move everything—only what still matters.  

2. Build & Migrate

Here, decisions turn into execution. 

Typical activities include: 

• Enabling Redwood UI 
• Updating Visual Builder / VBCS extensions 
• Redesigning workflows to align with Redwood behavior 
• Building upgrade-safe, Redwood-compatible components  

This phase focuses on simplification, not replication.  

3. Test & Validate

Redwood testing focuses on end-to-end experience, not just screens. 

Key areas include: 

• Cross-module SCM flows 
• Role-based scenarios 
• Early resolution of usability and process gaps 
• Alignment with Oracle recommendations  

This is often where additional process improvements emerge.  

4. Training & Adoption

Redwood reduces training effort—but adoption still needs structure. 

Successful programs emphasize: 

• Role-based training 
• UAT and KUT support aligned to daily tasks 
• Clear communication on what changed and why  

Good design supports users; good change management builds confidence.  

5. Go-Live, Hypercare & Adoption Support

The final phase ensures stability and trust. 

This includes: 

• Early-life support
• Quick issue resolution 
• Process stabilization 
• Monitoring adoption patterns   

The objective is sustained usage—not just a clean go-live.  

A Practical Observation from the Field 

Organizations that align Redwood migration with Oracle’s AI roadmap gain more than compliance. Redwood is increasingly the foundation for AI-driven SCM capabilities. 

Planning for this early avoids future rework and enables faster value realization.  

Closing Thought 

Redwood SCM migration is no longer about meeting a release requirement. 

It is about making deliberate choices that shape how Supply Chain teams work going forward. 

With 27A, the transition is certain. 

The quality of preparation determines the outcome.