This topic explains how to configure LaunchDarkly SDKs to manage migrations or modernizations. You might use this feature if you are optimizing queries, upgrading to new tech stacks, migrating from one database to another, or other similar technology changes. This feature is available for server-side and edge SDKs only.
Before you configure your SDK to manage a migration, you must complete the following prerequisites:
READS and WRITES separatelyTo learn more, read Migration flags.
There are two categories of migration options that you can configure for each LaunchDarkly SDK:
Details about each SDK’s configuration are available in the SDK-specific sections below:
This feature is available in the following server-side SDKs:
To define how to read from the old and new systems, define the Read function. You can also define how to check whether the two reads are a match, and whether the reads should take place concurrently or serially.
To define how to write to the old and new systems, define the Write function.
To configure the metrics for your migration, set the TrackLatency and TrackErrors options.
Here’s how:
To learn more, read MigrationBuilder.
You can use the Migration configuration to define the options for your migration.
To define how to read from the old and new systems, define the Read function. You can also define how to check whether the two reads are a match, and whether the reads should take place concurrently or serially.
To define how to write to the old and new systems, define the Write function.
To configure the metrics for your migration, set the TrackLatency and TrackErrors options.
Here’s how:
To learn more, read Migration.
You can use the MigrationBuilder to define the options for your migration.
To define how to read from the old and new systems, define the read function, including how to check whether the two reads are a match. You can also define whether the reads should take place concurrently or serially.
To define how to write to the old and new systems, define the write function.
To configure the metrics for your migration, set the trackLatency and trackErrors options.
Here’s how:
To learn more, read MigrationBuilder.
To define how to read from the old and new systems, define the readOld and readNew functions. You can also define how to check whether the two reads are a match, and whether the reads should take place concurrently or serially.
To define how to write to the old and new systems, define the writeOld and writeNew functions.
Each of the readOld, readNew, writeOld, and writeNew functions accept an optional argument, which is typically used to define what to read or write. They should return LDMigrationSuccess or LDMigrationError, or can throw an exception. The code sample below uses a mix to illustrate these possibilities.
To configure the metrics for your migration, set the latencyTracking and errorTracking options.
Here’s how to configure each of these options:
To learn more, read LDMigrationOptions.
To define how to read from the old and new systems, call the read method. You can also define how to check whether the two reads are a match, and whether the reads should take place serially or in a randomized execution order.
To define how to write to the old and new systems, call the write method.
Each of the read and write method accept new and old methods for how to read from or write to both the new and old systems. These new and old methods accept an optional payload parameter, which is typically used to define what to read or write. They should return an LaunchDarkly\Types\Result instance.
To configure the metrics for your migration, set the trackLatency and trackErrors options.
Here’s how to configure each of these options:
To learn more, read MigratorBuilder.
To define how to read from the old and new systems, call the read method. You can also define how to check whether the two reads are a match, and whether the reads should take place concurrently or serially.
To define how to write to the old and new systems, call the write method.
Each of the read and write method accept new and old methods for how to read from or write to both the new and old systems. These new and old methods accept an optional payload parameter, which is typically used to define what to read or write. They should return an ldclient.Result instance.
To configure the metrics for your migration, set the track_latency and track_errors options.
Here’s how to configure each of these options:
To learn more, read ldclient.migrations.
To define how to read from the old and new systems, define the read function. You can also define how to check whether the two reads are a match, and whether the reads should take place in serial or in parallel.
To define how to write to the old and new systems, define the write function.
To configure the metrics for your migration, set the track_latency and track_errors options.
Here’s how:
To learn more, read MigratorBuilder.
To define how to read from the old and new systems, define the read function. You can also define how to check whether the two reads are a match, and whether the reads should take place in serial or concurrently.
To define how to write to the old and new systems, define the write function.
To configure the metrics for your migration, set the track_latency and track_errors options.
Here’s how:
To learn more, read MigratorBuilder.
This feature is available in the following edge SDKs:
To define how to read from the old and new systems, define the readOld and readNew functions. You can also define how to check whether the two reads are a match, and whether the reads should take place concurrently or serially.
To define how to write to the old and new systems, define the writeOld and writeNew functions.
Each of the readOld, readNew, writeOld, and writeNew functions accept an optional argument, which is typically used to define what to read or write. They should return LDMigrationSuccess or LDMigrationError, or can throw an exception. The code sample below uses a mix to illustrate these possibilities.
Although the migration options latencyTracking and errorTracking default to true, the Akamai SDK does not track metrics for migrations, because the Akamai SDK does not send events back to LaunchDarkly.
Here’s how to configure each of these options:
To learn more, read LDMigrationOptions.
To define how to read from the old and new systems, define the readOld and readNew functions. You can also define how to check whether the two reads are a match, and whether the reads should take place concurrently or serially.
To define how to write to the old and new systems, define the writeOld and writeNew functions.
Each of the readOld, readNew, writeOld, and writeNew functions accept an optional argument, which is typically used to define what to read or write. They should return LDMigrationSuccess or LDMigrationError, or can throw an exception. The code sample below uses a mix to illustrate these possibilities.
To configure the metrics for your migration, set the latencyTracking and errorTracking options.
Here’s how to configure each of these options:
To learn more, read LDMigrationOptions.
To define how to read from the old and new systems, define the readOld and readNew functions. You can also define how to check whether the two reads are a match, and whether the reads should take place concurrently or serially.
To define how to write to the old and new systems, define the writeOld and writeNew functions.
Each of the readOld, readNew, writeOld, and writeNew functions accept an optional argument, which is typically used to define what to read or write. They should return LDMigrationSuccess or LDMigrationError, or can throw an exception. The code sample below uses a mix to illustrate these possibilities.
To configure the metrics for your migration, set the latencyTracking and errorTracking options.
Here’s how to configure each of these options:
To learn more, read LDMigrationOptions.