Modernizing Authorization Infrastructure for a Trusted Credit Assessment Company

Migrating from an outdated in-house authorization layer to a third-party service while preserving domain data control.

Quick Insights

Lower authorization maintenance

by replacing an outdated in-house authorization layer that required a growing custom development effort.

Okta migration with domain control

by moving core authorization to Okta while keeping project-specific user, organization, and admin data inside the client’s platform.

Controlled migration flow

through step-by-step validation and internal rollout before broader external adoption.

Protected user data consistency

by synchronizing updates across systems only when both sides could be updated successfully.

Client

The client is a trusted credit assessment company providing financial analysis, ratings-related insights, and data products to businesses, investors, and institutions. Its digital ecosystem includes several platforms with different user types, access rules, and administrative workflows.

Client Need

The client’s platforms relied on an access management system that controlled how users logged in and received access to the required products and features. One critical part of this system, the authorization layer, was still based on a custom in-house server.

Over time, this server became harder to maintain and adapt to new requirements. Every extension required additional custom development, increasing engineering effort, slowing down changes, and making the authorization layer harder to support safely as the platform evolved.

The client needed legacy migration services to replace the outdated authorization layer with a more maintainable solution while preserving existing access behavior, integration stability, and control over project-specific user and organization data.

Investigation

Before starting the migration, Expert Soft analyzed how the outdated authorization layer could be replaced without disrupting existing access behavior. The team evaluated two possible directions.

New in-house authorization server

This option was considered because authorization logic had historically been owned inside the project, and the platform already had a custom implementation. We assessed this path as a proof of concept: the team outlined the baseline capabilities required from a new authorization layer and tested them with minimal implementation.

External authorization service

The second option was to move core authorization responsibilities to a specialized third-party service. This approach could reduce custom development effort, limit long-term maintenance responsibility, and give the platform a more sustainable authorization foundation.
After evaluating both options, integration with an external authorization service was selected as the more practical long-term path. It reduced custom engineering effort, simplified future support, and helped avoid rebuilding authorization capabilities inside the project again.

00 / 00

Solution

Expert Soft provided legacy migration services to move the outdated in-house authorization layer to Okta. The selected service took over core authentication and authorization responsibilities, while project-specific user, organization, and administrative data remained inside the client’s platform.

Defining Responsibility Boundaries

The migration was designed around a clear split of responsibilities. Okta handled the core access functions that no longer needed to be maintained inside the custom authorization server.

The responsibility split included:

Moved to Okta
User login, credential validation, authorization token issuing, and access rights based on provided attributes.
Kept inside the client’s platform
Organization structures, user groups, extended user attributes, and administrative data used by the internal admin interface.

This separation reduced the need to maintain custom authorization infrastructure while preserving control over domain-specific user and organization data.

Controlled Migration and Enablement

The migration was executed step by step instead of as a single switch. During the discovery phase, the team clarified Okta’s capabilities and constraints, then mapped legacy authorization behavior to the new model.

Required scenarios were validated through targeted PoCs before moving further. Internal teams were migrated first, which helped test the setup in a controlled scope before preparing the rollout for external clients.

Migration-Specific Integration Work

Moving authorization to Okta was not only about replacing one server with another. The new authorization model had to be adopted by the surrounding services, libraries, and data flows that already depended on the legacy layer. Two areas were especially important for making the migration safe: token validation and cross-system data consistency.

Migration-Specific Integration Work

Updating Token Validation Across Services

One of the core migration tasks was adapting the platform to Okta’s token model. The legacy authorization server used a simpler validation approach, while Okta introduced a different token format and verification flow. Existing services could not process the new tokens correctly without changes. Instead of updating the token handling service by service, Expert Soft updated the shared authorization library used across the platform. This gave downstream services one common way to validate Okta tokens, reducing duplicated effort and making the migration easier to control.

Synchronizing User Data Across Systems

The migration created a synchronization challenge because part of the user-related data had to exist in both Okta and the project database. Okta stored data required for authentication and access control, while extended user attributes, organizations, and groups remained inside the client’s platform. To avoid scattered update logic, the update path was consolidated into one service before database persistence. Updates were first sent to Okta, and project-side data was stored only after a successful response. If Okta returned an error, nothing was saved locally. This helped prevent partial writes and long-term data divergence.

Results

Replacing outdated authorization layer

The client moved from a custom in-house server to Okta, reducing dependence on legacy authorization infrastructure.

Lower custom maintenance effort

Core login, credential validation, token issuing, and access checks shifted to a specialized authorization service.

Controlled migration path

Targeted PoCs, behavior mapping, and internal-user migration helped reduce rollout risk before external adoption.

Smoother adoption for internal services

Shared authorization library updates gave downstream services one common way to support the new token model.

Protected data consistency

The updated write flow helped prevent partial user data updates between Okta and the project database.

01 / 02

Technologies

Java, Okta, JavaScript, Microservices

Conclusion

Expert Soft helped the client replace an outdated in-house authorization layer with Okta through a controlled migration that preserved existing access behavior and platform stability.

By separating responsibilities between Okta and the client’s platform, updating shared token validation, and introducing a consistency-first data synchronization flow, the team reduced custom authorization maintenance while keeping project-specific user, organization, and administrative data under the client’s control.