As SAML and OpendID Connect(OIDC) are fundamentally different methods
of handling authentication/SSO, is it possible for them to live
side-by-side in the same application?
Protocol, they are different. But they serve the same purpose, fulfilling Authentication and Authorisation. Now when you say application, we tend to think about end user application. For example a web application, standalone desktop application or a mobile app. From such application, I don't see the need to support multiple protocols. Implementation and maintainability wise, its easy for such application to support one authN & authZ protocol.
But if you think about a server end, specially your APIs exposing data and services, then you will have to support multiple authN & authZ protocols. For example, your service may consumed by applications which use SAML and some applications which use OpenID Connect. So those applications will come either with SAML assertions or OpenID Connect tokens, which you will have to validate. In this case its not a migration, but adding support for multiple authN & authZ methods.
Said that, usually Identity Providers does support multiple protocols. For example Azure AD support SAML 2.0 and OpenID Connect. So when your application comes to your back-end APIs/services, requests might come with either SAML or OpenID Connect. You will have to do ideal validations through a filtering layer to detect, verify and validate requests.
Major providers of ID management like Okta have a lot of docs on how to implement SAML or OIDC but I could not find anyone or any docs mentioning what level of effort is involved in migrating from one to the other. Has anyone done it? What was involved?
When designing applications, its good to isolate authN & authZ related things from core logic. That way, you get the ability to change the method/protocol easily. At the end of the day, you want to identify the end user who use application and get permissions defined on him/her. So a change of protocol to revive identification is not that difficult. But keep in mind that there will be some work, for example OpenID Connect token validations, token expiration handling sort of things. Use libraries to make life easy
It's a good idea to move into OpenID Connect for new applications. But you might find it difficult to migrate all your applications (depending on their complexity). So having support for both in back-end is ideal. Also, try to always store and retrieve identity details from an identity provider. That way, change of protocol is easy as they (identity providers) comes with support for multiple protocols.
