One Tenancy or Many? What Oracle Told Us About Tenancies, Identity Domains, and Fusion

 One Tenancy or Many? What Oracle Told Us About Tenancies, Identity Domains, and Fusion

A tenancy is a hard boundary by design. Once that clicks, most of the other decisions get easier.

If your organization has been on Oracle Cloud for a while, there is a good chance your footprint did not arrive all at once. Fusion pods came first, or PaaS services did. A new module showed up with its own activation email. Somebody made a reasonable call at the time, and a few years later you are looking at several tenancies, a growing list of identity domains, and a question nobody can answer in one sentence: where should the next thing go?

That is where our team is. We recently sat down with Oracle's OCI identity team to talk less about how we got here and more about where Oracle is heading, and how a customer should think about tenancies and identity going forward. I want to write down what I took away from it.

Start with the vocabulary

Oracle Cloud identity runs on OCI IAM with identity domains. If you have been around long enough to remember IDCS, identity domains are where that capability lives now.

When you get a tenancy, you get one identity domain automatically, the Default domain. It exists so you can sign in to the tenancy, manage it, and do everything else an administrator does there. You can create additional domains for other purposes.

When you buy Fusion, things get more interesting.

Why every Fusion pod has its own identity domain

Buy three Fusion pods for development, test, and production, and you get three identity domains, one pre-wired to each pod, in addition to the tenancy's Default domain.

That surprises people at first. It seems like a lot of identity. The reasoning is sound, and the example Oracle used made it click for me.

Picture a developer configuring a timesheet approval flow. To prove it works, they need to sign in as the employee who submits the timesheet, then the manager who approves it, then the director above that. In a development environment that usually means a set of test users the developer controls. You cannot wire that environment to your production corporate identity provider, because those test personas do not, and should not, exist there.

So each pod is its own island of identity. Development gets test identities. Pre-production connects to your pre-production identity system. Production connects to production. Not every customer works that way, but it is a very common pattern and Oracle has to support the customers who do.

The greenfield picture

This is the part I found most clarifying. If you provision PaaS services to support a Fusion environment, such as Visual Builder, Integration, Analytics Cloud, Fusion Data Intelligence (formerly Fusion Analytics Warehouse), or Autonomous Database, you provision them in the same tenancy using the same identity domain as the pod they support.

Do that, and they are pre-integrated. No extra trust to set up, and no federation to maintain between services that are supposed to behave as one environment.

The picture Oracle described for a customer starting today looks like this:

·        One tenancy, with compartments per environment.

·        A development compartment holding the dev Fusion pod and the dev instances of Integration, Visual Builder, and whatever else supports it, all sharing the dev identity domain.

·        A pre-production compartment that mirrors it, and a production compartment that mirrors that.

·        Integrations, extensions, and configuration promoted through those environments the way you would expect.

Oracle was candid that most long-standing customers, us included, do not look like this, because services were provisioned at different times for reasons that made sense then. It is a target state, not a judgment on anyone's current state. Getting from here to there is its own conversation, and one Oracle offered to work through with us.

Everything Oracle runs is on OCI

One comment reframed things for a few people in the room. We tend to talk about moving PaaS "into the same OCI as Fusion" as if Fusion recently arrived there. It did not. Fusion has run on OCI for a long time, as does essentially everything Oracle offers, homegrown or acquired.

What has changed is visibility. Services are progressively surfacing in the Oracle Cloud console at cloud.oracle.com, which is the console for all of Oracle Cloud rather than only infrastructure. When people say "OCI" they usually mean compute, storage, and networking. The console is that, plus PaaS, plus SaaS, and Oracle's direction is that everything you subscribe to shows up there.

It also explains how so many of us ended up with split tenancies. Fusion pods originally existed without any tenancy at all. You signed a contract and consumed your environments from their URLs. When tenancies were introduced a few years ago to give customers a way to manage everything, Fusion pods were attached to one, and PaaS services bought earlier often lived in another.

A tenancy is a box, on purpose

The question our team was most eager to ask: could we simply move things between tenancies to consolidate?

The short answer is no, and the reason is a good one. When a tenancy is created, keys and certificates are generated for it and held in hardware security modules. Tenancies are a hard partition, and Oracle has intentionally not built tooling to move resources from one to another. A compute instance, a block volume, an Integration instance, a Fusion pod: whatever is created in a tenancy stays in that tenancy.

What you can do is rebuild and migrate:

·        Export and import configuration, such as Integration projects, users and groups, and API gateway definitions.

·        Use Terraform to recreate infrastructure and the PaaS service instances themselves.

·        Use the standard environment migration and refresh tooling where it applies.

Plan for the fact that a rebuilt instance is a new instance. It will have a new URL, and anything that pointed at the old one needs to change.

I appreciated the framing. A tenancy is a box that things can come into and go out of, but cannot slide sideways between. Once you accept that, "move" stops being the right word, and the real questions become whether a rebuild is worth it and where the new thing should be born.

Where new subscriptions land

That leads to the most practical takeaway I would pass to anyone buying something new from Oracle.

When you subscribe to a new Fusion service, the person who placed the order receives an activation email. It asks where you want the service to go: an existing tenancy, or a new one.

Expanding an existing subscription is different. If you have three pods and add two more, the new ones are provisioned alongside the existing ones in the same tenancy.

Oracle's direction is that SaaS services live in a tenancy. For a specific product, confirm how activation works before you assume. Oracle sells a lot of SaaS, and not every service follows exactly the same path today.

My advice is to treat that activation click as an architecture decision, not an administrative step. Decide where a new service belongs before the email arrives. We have made that call deliberately in the past, including once choosing a new, isolated tenancy on purpose, and I was glad we had talked it through first.

So, one tenancy or many?

Oracle's position was balanced. You can put everything in one tenancy, and for a smaller organization a single tenancy is ideal. There are also legitimate reasons larger enterprises do not:

·        Business units that operate independently, or could be divested someday. Separating a tenancy after the fact is hard, so if a unit might leave, it probably belongs in its own.

·        Administrative separation, where different groups need clearly distinct control.

The counterpoint Oracle offered is the one I keep coming back to. If it is your HR system and everything that supports it, and you are buying it from Oracle, it makes sense to keep it together unless you have a specific reason not to. The same applies to ERP.

A separate tenancy also comes with work. A few things our team noted you take on:

·        Network connectivity. A new tenancy does not automatically share your existing FastConnect. Remote peering or a hub-and-spoke design can bridge it, but it has to be designed.

·        Identity wiring. Inside one tenancy, the same identity flows naturally across Fusion, Integration, analytics, and the rest of an environment. Across tenancies, you build and maintain that federation yourself. This matters more every release, especially as capabilities like AI Agent Studio span product families and benefit from a common identity.

·        Commercial alignment. Subscriptions and credits are associated with a tenancy, so how you consume services in a new one is a conversation for your account team.

A word on identity domain types

One more piece helps explain the design. The Default domain in a tenancy is a Free domain type intended for managing the tenancy, and its user limit reflects that purpose. The identity domain delivered with a Fusion pod is an Oracle Apps domain type, provided as part of the Fusion subscription. It covers what your users need to access Fusion and the services supporting it in the same tenancy.

If you still carry bring-your-own licensing assumptions from older IDCS or on-premises identity deployments, it is worth revisiting them. For the Fusion use case you may not need them. If you plan to use a Fusion identity domain well beyond supporting Fusion, have that licensing conversation with your account team up front.

What I am taking away

·        Design toward the target state: one tenancy per logical platform, compartments per environment, and supporting PaaS provisioned against the same identity domain as the Fusion pod it supports.

·        Stop saying "move." Resources do not move between tenancies. Plan rebuilds with export, import, and Terraform, and plan for new URLs.

·        Decide where new services land before the activation email arrives.

·        Create a new tenancy when there is a genuine boundary, such as an independent or divestible business unit, and budget for the networking, identity, and commercial work that comes with it.

·        Keep identity consistent within each environment. The more your Oracle products work together, the more that pays off.

We closed the session with a standing offer from Oracle to go deeper on specifics once we have worked out what we want our architecture to achieve. That is the next step on our side, and I will share what we learn.

Based on a working session between our team and Oracle's OCI identity team in September 2026, combined with Oracle's public documentation. Product behavior, limits, and licensing change over time. Confirm specifics against your own environment and your Oracle account team. Views are my own.