If you’re still running OIC Gen2 integrations, you’ll need to migrate to Gen3 eventually. Here’s a clear-eyed comparison of what changed, what’s better, and where you need to be careful during migration.
The headline changes
New runtime architecture — Gen3 moved to a Kubernetes-based runtime, which means better horizontal scaling and more consistent performance under load. For high-volume scheduled integrations, this is a genuine improvement.
Unified console — Gen3 merges Process Automation, Integration, and Visual Builder into a single platform console. Navigation changed significantly, which trips up teams familiar with the Gen2 UI.
Event-driven integrations — Gen3 has stronger native support for event-based patterns, including Kafka-compatible event streams. If you’re building near-real-time integrations, this is worth exploring.
Mapper improvements — the XSLT mapper in Gen3 has better expression building, improved function search, and faster rendering on complex mappings. Day-to-day development feels noticeably smoother.
What migrates cleanly
- Adapter connections (REST, SOAP, FTP, DB) — most migrate with minor reconfiguration
- Lookup tables — export/import works reliably
- Simple request-reply integrations — clean migration in most cases
What needs redesigning
- Orchestration integrations with complex fault handling — fault scope structure changed enough that a direct migration often requires rework
- Any integration using deprecated Gen2-specific features — check Oracle’s deprecation list before starting migration
- Custom XSLT functions — some Gen2 custom functions don’t map directly; test thoroughly
Migration approach that works
Don’t do a bulk “lift and shift.” Prioritise:
- Map your integrations by complexity and traffic volume
- Start with low-traffic, simple integrations to build familiarity
- Rebuild (not migrate) your most complex, business-critical flows from scratch in Gen3
- Run Gen2 and Gen3 in parallel during transition — most tenants get both environments during migration