Part 2 - Oracle Utilities in the Cloud: Architectural Priorities for a Successful Cloud Migration

A major cloud transformation for Oracle Utilities is a big move—financially, strategically, and operationally. Whether you're starting fresh or migrating existing applications, your architecture choices early on can make or break long-term success. In this multi-part series, I’ll walk through several critical areas you should focus on when standing up Oracle Utilities applications in Oracle Cloud Infrastructure (OCI).

In Part 1, we covered Tenancy Organization. Follow that link if you want to catch up. In this part, we’ll address some important topics related to Identity and Access Management (IAM) as it relates to Oracle Cloud. So let’s get going…

Rethinking IAM in Oracle Cloud and What You Need to Know

Before we dive in, let’s clarify one key assumption: the OCI tenancy we're referencing uses IAM with Identity Domains — the current standard for all new cloud accounts. Oracle has consolidated Identity Cloud Service (IDCS) into OCI IAM, and new tenancies no longer feature IDCS as a separate service. Oracle describes the native IAM experience as offering “improved performance and scale, immediate availability in more global regions, and a new cross-region disaster recovery feature.”

This distinction is important because many existing tenancies — especially in the utilities space — still rely on IDCS. It may be integrated with Active Directory or already serving as the identity provider for existing Oracle Utilities Cloud Services (OUCS) applications.

Here are three scenarios to consider:

1. Adding New OUCS Apps to an Existing IDCS-Based Setup You’re running an OUCS app like Customer Cloud Service (CCS) in production using IDCS, and you plan to implement another — such as Work & Asset Cloud Service (WACS). In this case, engage Oracle to assess all available options and map out the pros, cons, risks, and dependencies. Don’t default to assumptions — make informed decisions.
2. Migrating from an OCI-Based OU App to OUCS You’re operating an OCI-hosted utility application (e.g., Customer to Meter – C2M) in production with IDCS and plan to migrate to its OUCS equivalent (e.g., CCS). First, confirm that your tenancy supports Identity Domains. Then, build a path to fully adopt OCI IAM and plan to deprecate IDCS once your legacy app is decommissioned.
3. Starting Fresh in OUCS You’re venturing into Oracle Utilities Cloud for the first time and don’t yet have a cloud account. Good news — your tenancy will be provisioned with OCI IAM using Identity Domains by default. You’re starting in the right place.

So what is an Identity Domain? It is the control plane for access management in Oracle Cloud. It's a container used for provisioning and managing users, assigning roles, enabling secure Single Sign-On (SSO), and acting as an identity provider (IdP) using standards like SAML and OAuth.

Identity Domains handle identity lifecycle management for OCI and can also serve as the IdP for other Oracle or non-Oracle applications — whether cloud-hosted, SaaS-based, or on-premises. IAM integrates with external identity providers and directories as well, such as Active Directory.

A Few Key Concepts Worth Calling Out

There’s enough depth in IAM to justify its own article, and anyone familiar with traditional identity stores and security groups will find OCI IAM relatively intuitive. That said, a few OCI-specific elements are worth highlighting:

Dynamic Groups & Instance Principals

A Dynamic Group allows you to assign resource access based on rules you define. Group membership is determined dynamically, based on attributes like resource IDs. For example, you can grant access to Object Storage only when a resource (like an Autonomous Database) matches a specific rule. This is known as using an Instance Principal, which replaces older, risk-prone service accounts that often go unmanaged.

Shared Responsibility Model

IAM in OCI follows a shared responsibility model. You, as the customer, are responsible for:

• Understanding how OCI IAM components and policies work
• Creating and managing your own users, groups, policies, and configurations
• Avoiding the use of example values from documentation — always use your own

When your tenancy is provisioned, Oracle creates a default Administrators group and a corresponding admin user. This group can’t be deleted and must always have at least one user. As part of your tenancy plan, once your other compartments, groups, and admin users are in place, secure the original admin credentials under privileged access control.

Identity Domains & Disaster Recovery

Finally, don’t overlook Identity Domains in your disaster recovery (DR) planning. Replication is automatically enabled for the default Identity Domain across all subscribed regions. However, if you create additional Identity Domains, they are confined to your home region unless you explicitly enable replication. Be sure to account for this in your DR strategy.

In the next post, we’ll name some fundamental elements using a Conceptual Architecture diagram—and connecting your on-premises domain to OCI and OU Cloud Services.

When it comes to most things Oracle, one size seldom fits all so your experiences may be different. I would enjoy hearing about them in the comments.