---
source_url: "https://developer.pingidentity.com/orchsdks/journey/migration.html"
title: "Migrating from ForgeRock SDKs to the Orchestration SDK | Orchestration SDKs"
mirrored_at: 2026-08-16T03:38:14.233Z
host: developer.pingidentity.com
cited_in_42a: true
mirror_canonical: "https://index.42a.ai/developer.pingidentity.com/orchsdks/journey/migration.html"
---

> **Original source:** https://developer.pingidentity.com/orchsdks/journey/migration.html

The migration to the new Orchestration SDK introduces a unified, modern architectural approach across Android, iOS, and JavaScript platforms.

While the legacy ForgeRock SDKs relied on traditional callback-based listeners for asynchronous operations, the new Orchestration SDKs fully embrace modern concurrency models native to each platform.

This consistent architectural approach ensures that while the language-specific implementation details differ, the core concepts for handling authentication journeys, managing sessions, and processing callbacks are aligned across all platforms.

Key architectural changes common to all platforms include:

Modern Asynchronous Programming

A fundamental shift from traditional callback listeners to modern, sequential-style asynchronous programming.

This is implemented using `async/await` for iOS and JavaScript, and Kotlin Coroutines for Android, resulting in cleaner and more readable code.

Modular and Instance-Based Design

The Orchestration SDKs are now broken down into smaller, specialized modules.

Configuration and API calls are instance-based rather than global or static, promoting better encapsulation and flexibility.

Workflow-Centric Design

Authentication and orchestration flows are modeled using a clear workflow pattern, involving "nodes", such as `ContinueNode`, `SuccessNode`, `FailureNode`, and `ErrorNode`.

These provide explicit control and visibility over the user journey.

Enhanced Type Safety and Explicit Error Handling

The new Orchestration SDKs emphasize stronger type safety and more explicit error handling.

This means moving away from generic value handling in callbacks to specific, strongly-typed properties, and providing clear structures for reporting failures and errors.

Declarative Configuration

Initialization is now handled declaratively, through builder patterns or factory functions with configuration objects, offering a more flexible and readable setup.