This article defines the stages of the identity architecture journey from a hybrid Active Directory setup to a fully cloud-based identity platform, and explains the trade-offs at each stage. It is written for IT managers in Norwegian municipalities who are planning or discussing this transition with Identum.
Why this matters
Microsoft is steadily moving investment away from on-premises Active Directory (AD) and Exchange, and towards Microsoft Entra ID and Exchange Online. Norwegian municipalities are at very different points on this journey: most run a hybrid setup with Entra ID Connect, some have started managing selected resources directly against Entra ID (Hybrid+), and a growing number have moved to cloud-first or cloud-only.
The terms "hybrid", "cloud-first" and "cloud-only" are used inconsistently across the industry, which makes it difficult to compare notes with other municipalities or to scope a migration project accurately. This article gives Identum and its municipal customers a shared vocabulary for these stages, so that conversations about migration, cost, and risk start from the same definitions.
The stages
|
Stage |
Source of Authority (SOA) |
Typical characteristics |
|---|---|---|
|
Hybrid |
On-premises Active Directory |
AD remains the master. Microsoft Entra ID Connect (or Entra Cloud Sync) synchronises users, groups and passwords to Entra ID. Mailboxes are typically in Exchange Online as remote mailboxes. All changes must be made on-premises; Entra ID holds read-only copies. |
|
Hybrid+ |
On-premises Active Directory |
Still hybrid in the strict sense: AD remains the SOA and Entra ID Connect is still running. The difference is that eADM has started managing some resources, typically Microsoft 365 group membership, directly against Entra ID in parallel with the existing AD sync. This is a preparatory step, not a change of SOA. |
|
Cloud-first |
Microsoft Entra ID |
Entra ID Connect is decommissioned. Entra ID becomes the primary, authoritative identity provider for all users and devices, eADM provisions all users direct to Entra ID. A local AD is still kept, but only to provide exception-based accounts for specific legacy applications that cannot yet work with Entra ID alone. There is no synchronisation between the two directories: eADM provisions each one independently and handles the password sync. |
|
Cloud-only |
Microsoft Entra ID |
No local Active Directory exists. Entra ID is the only directory, eADM provisions all users, groups and memberships direct to Entra ID. All applications either support Entra ID natively or are reached through cloud-based access solutions. This is the simplest end state to operate, but it requires that legacy application dependencies have been fully resolved or retired. |
Hybrid
Hybrid is still the most common stage among Identum's municipal customers today. On-premises AD is the source of authority, and Entra ID Connect (or Entra Cloud Sync) mirrors users, groups and password hashes to Entra ID. eADM writes to AD; for mailboxes hosted in Exchange Online, eADM also runs a script against the on-premises Exchange environment to create the remote mailbox object that links the AD user to the cloud mailbox.
Hybrid+
Hybrid+ is a named intermediate step within the hybrid stage, not a change in Source of Authority. AD is still the SOA and Entra ID Connect is still running, but eADM has started to extend what it manages directly against Entra ID, typically Microsoft 365 group membership, in parallel with the existing user and group sync to AD.
This lets an IT department start managing cloud-only resources from eADM, and build familiarity with direct Entra ID provisioning via Microsoft Graph, before committing to the larger step of decommissioning Entra ID Connect and moving to cloud-first. Hybrid+ is a useful label for a municipality that has clearly outgrown plain hybrid but has not yet transferred its Source of Authority to the cloud.
Cloud-first
In the cloud-first model, Entra ID Connect is switched off and the Source of Authority for users, groups and mailboxes is formally transferred to the cloud, typically using Microsoft's Managed SOA Transfer feature. Entra ID becomes the single, authoritative identity provider, and end-user devices move to being purely Entra ID Joined.
A local AD is not eliminated at this stage: it is kept in a reduced, exception-based form. eADM provisions the great majority of users (in practice, close to 100%) directly to Entra ID. Only users who need access to specific legacy, locally installed applications also receive a separate, non-synced account in the on-premises AD, provisioned by eADM as a distinct workflow rather than through directory synchronisation. When that legacy application permission is revoked, eADM de-provisions the on-premises account.
This model gives municipalities the operational simplicity of a single, modern cloud identity for almost everyone, while preserving a controlled, audited path for the legacy applications that are usually the hardest part of any cloud migration to solve.
Note: this is often as much a device- and application-access project as it is an identity project. Moving end-user devices from Hybrid Entra ID Joined to pure Entra ID Joined typically requires a full wipe-and-reload of the device fleet, and every legacy on-premises application needs a supported access path (for example Entra Application Proxy or Remote Desktop Services) before the transition can be completed safely
Example: a cloud-first account flow (eADM and eFeide)
.jpg?cb=3756b033047d8f4643f6d2d3b0a4b09b)
This is a concrete illustration of the exception-based AD account principle described above under Cloud-first: an AD account is only created where a specific application need exists, not by default for every user.
Cloud-only
Cloud-only goes one step further than cloud-first: the on-premises Active Directory is retired entirely, including the exception-based accounts used for legacy applications. This is only realistic once every remaining application either supports Entra ID natively or has been migrated, replaced, or retired. eADM manages the full user and group lifecycle directly in Entra ID via Microsoft Graph, with no on-premises component at all.
Comparing the stages
|
|
Hybrid |
Hybrid+ |
Cloud-first |
Cloud-only |
|---|---|---|---|---|
|
Source of Authority |
On-premises AD |
On-premises AD |
Microsoft Entra ID |
Microsoft Entra ID |
|
On-premises AD required |
Yes, full |
Yes, full |
Yes, exception-based only |
No |
|
Entra ID Connect / Cloud Sync |
Required |
Required |
Decommissioned |
Not applicable |
|
eADM writes directly to Entra ID |
No |
Yes, for selected resources (for example M365 groups) |
Yes, for almost all users and groups |
Yes, for everything |
|
Device join type |
Hybrid Entra ID joined |
Hybrid Entra ID joined |
Entra ID joined |
Entra ID joined |
|
Legacy application access |
Native, on-premises |
Native, on-premises |
Via exception-based AD account and a gateway (RDS, Application Proxy) |
Must already be resolved |
|
Typical driver to move on |
Wanting to manage cloud-only resources without a full SOA transfer |
Cost and complexity of maintaining Entra ID Connect and on-premises Exchange |
Remaining legacy application dependencies |
Already at target state |
Choosing your path
There is no single correct end state for every municipality, and cloud-only is not automatically the right goal for everyone. The right stage to aim for, and the right pace to get there, depends on a few practical questions:
-
How many applications still require a direct, on-premises AD account, and how difficult would each be to replace or front with a cloud-compatible access solution?
-
Is the current device fleet already Entra ID capable (join type, OS version, Intune enrolment), or does the migration also require a hardware refresh?
-
How much value would the IT department get from retiring Entra ID Connect and on-premises Exchange, in terms of both licensing cost and administrative time?
-
Does the organisation want to reach a single, simplified cloud-only environment eventually, or is a stable cloud-first model with a small, well-governed legacy exception list an acceptable long-term state?
Many municipalities treat cloud-first as a deliberate, stable end state rather than a stepping stone: the exception-based legacy access model is far simpler to operate than a full hybrid sync, even if a handful of on-premises accounts remain indefinitely. Hybrid+ is a useful staging point for municipalities that want to test direct Entra ID management on a small scope before deciding whether, and when, to transfer the full Source of Authority.
This article defines and compares the stages of Microsoft identity architecture relevant to eADM customers: hybrid, hybrid+, cloud-first and cloud-only. It covers where the Source of Authority sits at each stage, the role of Entra ID Connect, device join type, and how legacy application access is handled, including a worked example of a cloud-first account flow across eADM and eFeide. Hybrid+ describes municipalities that have begun managing some resources, such as Microsoft 365 group membership, directly against Entra ID while remaining hybrid. The intended audience is IT managers at Norwegian municipalities evaluating or planning a move away from a hybrid Active Directory model. It complements the detailed cloud-first migration run-plan and the Mailbox Provisioning in eADM article.