Walkthrough: using a feature flag to send events to both CDPs during transition.

I've seen several teams treat a CDP migration as a "big bang" cutover, which inevitably leads to data discrepancies and frantic debugging. A more robust approach is to run both systems in parallel, using a feature flag to control event routing. This allows for real-time comparison and validation before the final switch. The core concept is simple: instrument your event emission logic to send to both the legacy and new CDP based on a flag, but the devil is in the implementation details.

Here's a representative Node.js/TypeScript example for an analytics event emitter. The flag is evaluated per event, allowing us to ramp up traffic gradually.

```typescript
interface CDPClient {
track(event: string, properties: Record): void;
}

class DualCDPEmitter {
constructor(
private legacyClient: CDPClient,
private newClient: CDPClient,
private featureFlags: FeatureFlagService
) {}

async track(
userId: string,
event: string,
properties: Record
) {
// Always send to the legacy CDP
this.legacyClient.track(event, properties);

// Conditionally send to the new CDP based on a feature flag
// Flag can be based on userId, event type, or percentage rollout
const sendToNewCDP = await this.featureFlags.evaluate(
'cdp-migration-rollout',
userId
);

if (sendToNewCDP) {
// Optional: Transform properties to match new CDP's schema here
const transformedProperties = this.transformProperties(properties);
this.newClient.track(event, transformedProperties);
}
}

private transformProperties(props: Record) {
// Schema translation logic
const transformed = { ...props };
if (transformed.oldPrice) {
transformed.itemPrice = transformed.oldPrice;
delete transformed.oldPrice;
}
return transformed;
}
}
```

Key considerations for this pattern:

* **Flag evaluation logic:** Use a deterministic flag (e.g., based on a user ID hash) to ensure a given user's events are consistently routed during the transition period. This prevents duplicates or gaps from non-deterministic routing.
* **Schema translation:** The new CDP often requires a different data shape. Centralize this transformation in the emitter, as shown in the `transformProperties` method, to avoid polluting your core application logic.
* **Performance impact:** The synchronous call to the legacy client plus the conditional call to the new client adds latency. Consider firing the non-primary CDP call asynchronously or delegating dual-write to a background queue if the volume is high.
* **Observability:** Instrument this layer heavily. Log comparison counts (`legacy_only`, `both`, `new_only`) and monitor for discrepancies in event volumes between the two systems. Alerts should fire if the delta exceeds a threshold (e.g., >1%).

The final step is backfilling historical data into the new CDP. Once you've validated that real-time events are matching for a 100% flagged population, you can stop writing to the legacy CDP and decommission the flag. This methodical, data-driven switch minimizes risk significantly.

benchmark or bust