OACadvanced
Migrating from On-Premise OBIEE to OAC
Explain the technical and organizational considerations involved in migrating an existing OBIEE/OAS deployment to Oracle Analytics Cloud.
Most organisations asking about this are mid-journey, so the useful answer is about what carries across and what does not.
It's like relocating a well-organized physical office to a new building: most of the furniture and file cabinets (RPD, catalog) move over largely intact, but you still need new keys and badges for the new building's security system (identity federation), and anything hardwired into the old building's specific electrical setup (custom extensions) needs an electrician's review before it works the same way in the new space.
Key Concepts
1
The technical path is a lift of the RPD and the catalog.
export the RPD and the web catalog as a BAR file
| upload to OAC
v
subject areas, dashboards, analyses, agents -- largely preserved2
It is a migration, not a rebuild. That is the first thing to say, because people assume otherwise.
3
The Baseline Validation Tool is how you prove it. Run the same reports before and after and compare the
results, automatically, across hundreds of objects.
4
Without it, validation is a person opening reports and looking — which does not scale past a few dozen and
does not catch a number that is subtly different.
5
What needs real work is everything around the model.Connectivity. Sources that were on the same network are now across the internet. Each needs a cloud
connection or the Remote Data Gateway, and the aggregation pushdown that makes that acceptable.
6
Identity. Authentication moves from WebLogic's realm to IDCS or OCI IAM, and group-to-role mappings are
rebuilt there.
7
Anything customised. Custom skins, custom JavaScript, custom login pages, and anything done by editing
configuration files on the server. In OAC there is no server to edit.
8
Scheduling and delivery. Agents carry across; the mail configuration and any file delivery destinations
do not.
9
The organisational half, which is usually underestimated. You stop controlling when upgrades happen.
10
on-premise patch when you are ready, test first, defer
OAC Oracle updates on a cadence11
So the regression testing that used to precede a patch becomes a continuing activity — the same shift as
EBS to Fusion, for the same reason.
12
The opportunity worth naming. A migration is the moment to retire what is unused. Usage tracking shows
which of four hundred analyses actually ran this year, and migrating sixty rather than four hundred makes
the validation tractable.
13
Lifting everything because it is easier to lift everything is how an organisation carries a decade of
abandoned reports into a new platform and pays to validate them.
14
What the interviewer is probing.1. "What is the migration path?" Probing: the process. Stalls: "Rebuild." Moves up: lift
the RPD and catalog with the migration tooling, remap security to identity cloud service, then test
and retire unused content.
15
2. "What usually does not carry across?" Probing: the realistic view. Stalls: "Everything
carries." Moves up: custom scripts, filesystem dependencies, some connection types, and anything
relying on direct server access.
16
3. "How do you scope the testing?" Probing: the method. Stalls: "Test everything." *Moves
up:* usage tracking to find the content that is actually run, then a regression set with known
expected numbers for those.
17
4. "What is the opportunity people miss?" Probing: the judgement. Stalls: "None." *Moves
up:* retiring content — a migration is the one moment the business will agree to delete the hundreds
of unused reports.