Decommissioning on-premise Active Directory and going all the way to Okta as the sole identity provider is one of those projects that sounds clean in a meeting and gets complicated fast once you’re inside the actual environment.
The org had built everything on AD. Authentication, Group Policy, endpoint management, manual account provisioning. It worked well enough for a while. Then the company started growing and the cracks showed. Cloud apps were piling up. The workforce was increasingly distributed. Manual provisioning was eating time that nobody had. And defending an on-prem-anchored identity environment against threats that don’t care about your physical network perimeter gets harder the more distributed you become.
The call was to move to Okta as the sole IdP and decommission AD entirely. Not a hybrid. Not an indefinite sync situation. A full cutover.
Why all the way
Most organizations hedge this transition by keeping AD on-prem and syncing it to a cloud IdP. That’s the cautious path, and it’s also how you end up maintaining two directories, two sets of policies, and two points of failure for years. The security case for cloud-native identity weakens considerably when the on-prem anchor is still sitting there.
If you want a scalable cloud identity platform, halfway doesn’t get you there. Okta as the sole IdP meant one directory, one policy layer, and one authentication path for every application. The tradeoff was that getting there was more work upfront.
The migration
Applications went first. Everything authenticating against AD — LDAP, Kerberos, SAML — had to be rebuilt against Okta before we could touch the directory itself. Some of it was straightforward; Okta has solid integration documentation for common apps. Others needed custom SAML work that took a few rounds to get right.
Users came after. Mapping AD accounts to Okta profiles, deciding which group memberships were worth carrying over, and discarding the rest. AD environments that have been running for years tend to collect group policy and group memberships that exist mostly because they once existed. A migration is a reasonable time to stop recreating all of that.
The decommission was last, and confirming that every authentication dependency had actually moved was almost as involved as the migration itself. There’s always something that didn’t make the documentation. Finding it after the fact is slower than finding it before, so we were methodical about it.
RBAC from scratch
The permission model we replaced had accumulated exceptions over years. The new one was built around a simple question: what does someone in this department actually need access to on day one, and how do we provision that automatically.
The answer became department profiles in Okta. Add someone to the right group and applications, email groups, and resource access all follow from that assignment. New hire provisioning went from a manual checklist across multiple systems to a single profile assignment.
The timing mattered. The company grew from around 200 to 350 people within a calendar year. That pace of onboarding under the old model would have required proportionally more IT time. With the RBAC structure in place, it didn’t.
Endpoint management and device trust
Rebuilding identity was the right moment to deal with endpoint management too. The existing MDM was Ivanti, and it wasn’t handling macOS well — which had become the dominant platform in the environment.
We moved to Intune. It had gotten good at macOS management, and consolidating into the Microsoft ecosystem the org was already using made sense. We rebuilt policies rather than porting them, which meant starting with a cleaner baseline instead of carrying over whatever had built up in Ivanti.
Kolide went in as the device trust layer. It monitors endpoint health and passes posture signals to Okta, which uses them in authentication policy decisions. A device that’s out of compliance gets blocked at the IdP before it authenticates. For a distributed workforce that’s not all sitting on the same network, that’s the right place to enforce it.
Automating the lifecycle
The last piece was making sure provisioning and deprovisioning didn’t fall back on manual steps as the org kept growing.
Jira Service Desk handles request intake. BetterCloud is the execution layer — it handles Okta actions, app assignments, and SaaS operations that sit outside what Okta manages directly. New hire request comes in through Jira, BetterCloud runs the workflow. Offboarding runs in reverse: suspension, access revocation, data preservation, all automatic.
IT involvement in routine onboarding and offboarding is now exception handling. The standard cases run without a person in the loop.
What it took
Start to finish, roughly six months from the first application integration to the AD decommission. The complexity tracked with how long the environment had been running — older environments have more undocumented dependencies, and those take time to find.
What made it work: mapping every authentication dependency before touching anything, testing the RBAC model in staging before touching production users, and treating the endpoint migration as part of the identity project rather than a separate workstream. Device trust and identity are the same problem. If you solve them separately, you end up with a gap between them that has to be closed anyway.