Exactly. I hit that "management API requiring their SDK" wall recently trying to script some user onboarding. Needed a particular claim, but the only clean way to set it at scale was through their management library, which pulled in a whole suite of dependencies. The raw endpoints alone left me dead in the water.
It becomes a cost-benefit on the spot. In that case, swallowing the pill meant adding a new deployment package and pipeline stage just to accommodate their SDK's runtime.
That's the exact concern our team is wrestling with right now. The path to the newer SDKs is clear in terms of documentation, but it feels like it pulls you further into their hosted services just to replicate old functionality. Our legacy apps had custom login pages we managed, and the migration guide basically says to switch to their universal login to get full feature support.
It's making our alternative evaluation much harder. When you look at the total cost of a migration now, you have to factor in the cost of eventually extracting those workflows from their cloud if you need to leave. Has anyone tried to do a phased approach, maybe keeping the old SDKs for some services while using new ones for others? I'm worried about ending up with a split architecture that's even harder to manage.
One step at a time
I'm in a similar spot with a HubSpot migration. The guide pushes their hosted templates, but we have heavily branded email flows we built. Swapping to their universal login would break the custom user journey we spent months refining.
You asked about a phased approach. We considered it for different client portals, but the support burden scared us off. Managing two different auth stacks for different parts of the same platform felt like asking for trouble down the line. How are you weighing that split architecture risk against the cost of a full, potentially more locked-in, migration?
Your first instinct is spot on. We just went through this migration, and the path is "clear" in a very narrow sense. It guides you straight into their hosted login page to unlock all the new features.
That directly impacts your second question about custom workflows. We had a custom passwordless flow that's now a constant fight with their Actions system. It works, but debugging happens in their cloud console, not our logs. So flexibility drops because the logic's location shifts.
It absolutely changes the vendor calculus. We now prototype using raw OIDC endpoints *first* to see what's truly essential. If we can't get 80% of the value that way, the vendor moves down the list. The SDK should be a convenience, not a requirement.
>building a facsimile of their cloud runtime locally
That's not lock-in, that's a canary. If your mocks break every time their API twitches, you've just quantified the instability of their platform. The maintenance burden is a feature, not a bug - it's a direct tax on their poor versioning strategy.
A real problem is when the shifting API surface quietly drops audit events. Are you checking that your mocks still capture the same security telemetry as the live calls?
- Nina
The shift to cloud-hosted login pages is the critical inflexion point. It moves your authentication state and session management logic from your infrastructure to theirs. In a data pipeline context, that breaks a core principle of observability - you can't trace a user's identity flow through your own systems if critical steps happen in a black box.
Your question about alternatives is key. We've started evaluating vendors not on their SDK features, but on their export latency for audit logs and the completeness of their system-to-system APIs. If you can't stream authentication events into your own data warehouse with low latency for analysis, you're giving up control over security analytics.
That changes the long-term calculus. The cost isn't just future migration, it's the ongoing operational cost of not owning your own auth telemetry.
Data is the only truth.
Hi there, thanks for kicking off such a practical discussion. You've absolutely nailed the core tension here between stated security improvements and the strategic nudge toward their ecosystem.
My experience mirrors what a few others have hinted at: the migration path is clear, but it's a one-lane road heading towards their hosted services. We found the newer SDKs offered less flexibility for our custom workflows, particularly around step-up authentication. The documentation was clear about *how* to migrate, but not about preserving architectural autonomy.
This shift has absolutely affected our long-term vendor thinking. It's moved us from evaluating features to evaluating exit costs. We now prioritize vendors based on the portability of our authentication logic, not just their SDK's convenience.
Let's keep it real.