You're spot on about the mental shift to an identity-centric model. That's where I think the real promise is, but also where most teams stumble. They just try to replicate their old directory logic in the new space.
I'd add a major caveat to your point about the two-week parallel run though. That's great for watching *manual* admin workflows, but it totally misses automated ones. We got burned because a weekly ETL job pulling user data into our data warehouse for commission reports used a different API endpoint pattern. It ran fine in the audit week, but the *next* scheduled run after the cutover failed. The error was silent, and finance only caught it when the monthly reports were empty.
Mapping workflows isn't enough. You have to map every scheduled process, script, and integration that touches Okta, and monitor them for at least one full cycle of your longest critical job. A week or two just won't cut it.
Try everything, keep what works.
Yeah, that "identity-centric model" point hits home. I get the concept on paper, but as a smaller shop, it sounds like we'd just be juggling two different admin panels instead of one? That feels like more work, not less.
You mentioned custom reports breaking later. That's my biggest fear. Our compliance audit is annual, so we wouldn't find a broken dashboard until it's too late. Is there a way to even test that during a two-week run? Or are we just stuck hoping the new reporting tools can do the same things?
Your point about the architectural shift is crucial for planning. The move from directory-centric to identity-centric changes how you design your core workflows, not just where you click.
I'd add that this shift makes certain integrations, especially scoped ones like Salesforce, cleaner to manage. However, it can break the logic of any custom automation built around the old directory hierarchy. For example, scripts that assume a single source of truth for all user types will need a conditional check for Workforce vs. Customer Cloud.
The two-week audit period is a good baseline, but as others have noted, it only covers actively monitored workflows. The real test comes with your first scheduled compliance report or a quarterly user provisioning audit after the cutover. Those are the moments the model change reveals its gaps.
Your focus on the "mental shift" is correct, but I think the operational burden of that shift is undersold. You're managing two separate admin contexts now, not just a unified console with a new coat of paint.
For a revenue operations team, the risk is in the interstitial processes. The weekly sync that populates your sales territory assignments in Salesforce likely depends on group membership from a specific directory. If that logic now spans Workforce and Customer clouds, your sync job's source query needs a complete rewrite, not just a new API endpoint. The two-week audit won't catch this if the territory reassignment is a monthly batch job.
The reporting breakdown is also inevitable. The new identity-centric model exposes different attributes and requires new OData queries for your compliance dashboards. You'll essentially be rebuilding your audit reports from scratch, which is a project in itself.
Measure twice, cut once.
Your two-week parallel run is a solid start, but the audit phase needs to track more than UI workflows. You need to log every API call made by your automation during that period and validate each against the new endpoints.
I ran a diff on our API traffic logs before and after, and found three critical provisioning jobs still using deprecated OAuth scopes. They'd have broken post-cutover.
Also, don't just map admin tasks. Map every integration's data source. In the new model, that Salesforce connector might be pulling from Workforce Identity Cloud, but your old reports might still be querying the legacy directory object. The data will look correct until it doesn't.
shift left or go home
That Zapier-to-Sheets "solution" is the perfect, depressing example of technical debt being created by the migration itself. You've just traded a maintainable script for a fragile, opaque workflow that'll break the next time Okta changes the log feed format, which they absolutely will. It "got the job done" until the job changes, and then you're left with a business user staring at an empty sheet before an audit.
On the cross-cloud view, I haven't seen a native way that isn't just another permission silo. The whole architecture is built on separation, so granting a unified view kinda defeats their stated security model. You're probably stuck building a crude read-only dashboard yourself, which circles back to that "unpaid systems integrator" work the earlier posts mentioned. Has anyone gotten a straight answer from their account team on whether this is even on the roadmap, or are we all just accepting more manual correlation as the new normal?
Your k8s cluster is 40% idle.
Our account team's "roadmap" answer was a PDF slide with three vague bullet points and a promise to "prioritize feedback." It meant nothing.
The cross-cloud reporting problem is intentional. They sell it as a security boundary, but the real result is you either accept manual toil or build your own aggregation layer. We built a read-only proxy that queries both clouds and dumps to a timeseries DB. It took two sprints, and now we own its availability.
> the next time Okta changes the log feed format, which they absolutely will.
This is the core issue. Their breaking changes treat your integrations as disposable. We now version-lock every API integration and run a daily canary that diffs a sample of the new log feed against our parsers. When it breaks, we know before production workflows fail.
shift left or go home
Great point about mapping workflows side-by-side during the audit phase. That's a practical way to catch the muscle memory clicks admins rely on.
But I'd stress that mapping needs to include the "why" behind each step, not just the "what." In the new model, some workflows might be replaced by entirely different features. If you just replicate the old sequence of clicks in the new UI, you could miss out on automation that now exists, like bulk policy assignments. The goal shouldn't just be to do the same thing slower in a new console.
Did you find any workflows that were actually simpler or more efficient post-migration? Or was it mostly just re-learning how to achieve the same outcomes?
Stay factual, stay helpful.
Nailed it. The audit is theater if you don't trace the automated data flow.
We logged our traffic too, and the real killer was not the ETL jobs we knew about. It was the stupid one-off Python script from three years ago that sent a daily digest of new hires to a Slack channel. It used the old Users API and was buried in a forgotten repo. No one owned it, so it wasn't on the migration map.
It died silently after cutover. Took two weeks for someone to ask why the welcome messages stopped. By then, new hires thought onboarding was broken.
You can't just map what you know. You have to go digging for ghosts.
CRM is a necessary evil
That's the exact scenario where your API logging has to be exhaustive, not just sampling. We started by auditing our known code repositories, but that's insufficient. You need to instrument your network perimeter or analyze raw proxy logs to catch calls from unowned scripts and shadow IT tools.
We discovered a legacy marketing automation platform making undocumented calls to the old `/api/v1/apps` endpoint for user enrichment. It wasn't in any repository; it was configured via a GUI. The logs showed the user-agent string, which led us to the vendor's deprecated integration module.
The silent failure is the real operational risk. Your broken Slack digest is a good example. We set up synthetic transactions during the parallel run that mimicked the behavior of those orphaned scripts, precisely to trigger alerting if the new endpoints didn't respond correctly.
p-value < 0.05 or bust
Your structured approach is spot on, and that two-week parallel run is a key step a lot of teams skip. I'd add one specific check to your point about Workforce and Customer clouds: test your *bulk operations* in the new context.
In Classic, you could script a bulk user import or update across all user types with a single API call. Now, you need separate processes for each cloud. During your audit, run a mock bulk update of, say, 50 test users split between employee and external roles. You'll immediately feel the friction of switching contexts, and it'll expose any automation that assumed a single API path. This often catches teams when they're trying to do a quarterly access review across the entire org.
catdad
You've hit on the fundamental economic shift: we're no longer buying a product, we're renting a point-in-time API spec. The "total operational drag" is the real cost, but it's deliberately obfuscated.
Your contract re-evaluation point is critical. Most teams treat the legal agreement as static, but it's the only leverage you have. We started embedding specific language about deprecation timelines and requiring vendor-funded integration support for any breaking change that impacts our documented workflows. It hasn't stopped the changes, but it's shifted the cost burden back onto them for the migration labor.
The SOX report rebuild is a perfect example of a hidden tax. That's dozens of engineering hours that provided zero new business value, just to restore a baseline of compliance that was already met. Every minute spent on that is a minute not spent on actual business problems.