Migration configuration
Read time: 12 minutes
Last edited: Oct 21, 2024
Overview
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.
Prerequisites
Before you configure your SDK to manage a migration, you must complete the following prerequisites:
- Create a migration feature flag. This is a temporary flag used to migrate data or systems while keeping your application available and disruption free. Migration flags break up the switch from an old to a new implementation into a series of recommended stages where movement from one stage to the next is done in incremental steps.
- Determine how many stages your migration will have. You can select from the following options as part of creating a migration feature flag:
- Two stages: For migrations where you cannot run the new system and old system at the same time
- Four stages: For migrations that can run both the new and old systems at the same time
- Six stages: For migrations where you need to migrate
READSandWRITESseparately
To learn more, read Migration flags.
Migration configuration options
There are two categories of migration options that you can configure for each LaunchDarkly SDK:
- Options for reading and writing data: You can define how to read from and write to both the old system and the new system. You can also define a method to check whether the two reads are a match, and whether the migration should execute serially or concurrently. To learn how these options apply to each migration stage, read Use SDKs to manage a migration.
- Options for tracking metrics: You can configure whether the SDK should track latency and errors, so that you can monitor the performance of your application during the migration.
Details about each SDK's configuration are available in the SDK-specific sections below:
Server-side SDKs
This feature is available in the following server-side SDKs:
.NET (server-side)
Expand .NET (server-side) code sample
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.
Go
Expand Go code sample
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.
Java
Expand Java code sample
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.
Node.js (server-side)
Expand Node.js (server-side) code sample
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.
PHP
Expand PHP code sample
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.
Python
Expand Python code sample
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.
Ruby
Expand Ruby code sample
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.
Rust
Expand Rust code sample
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.
Edge SDKs
This feature is available in the following edge SDKs:
Akamai
Expand Akamai code sample
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.
Cloudflare
Expand Cloudflare code sample
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.
Vercel
Expand Vercel code sample
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.