liveBook · Manning

Parallel run pattern

As explained in First-Party Data Activation

An implementation approach in which legacy and replacement systems operate simultaneously for comparison, validation, or continuity.

Replacing a working data platform is like changing the engine while a business still needs to drive. A parallel run keeps the legacy system and its replacement operating side by side. In a brownfield migration from a warehouse to a lakehouse, teams compare their outputs before moving daily marketing work to the new environment. section 5.4.2

A practical off-ramp has three stages:

  • Plan the overlap. Inventory existing feeds and scripts, budget for two environments, and set goals, a timeline, and exit criteria. section 5.4.1 section 5.4.3
  • Run and reconcile. Migrate historical records in passes, then compare critical measures—such as orders, average cart value, campaign ROI, or email clicks—between old and new systems. Investigate discrepancies, including undocumented reporting scripts. section 5.4.2 section 5.4.3
  • Cut over gradually. Shift marketing work once the lakehouse meets accuracy and performance targets; retire legacy infrastructure after the new environment is stable. section 5.4.4

Retail warehouse migration

An apparel retailer has historical sales in an on-premises warehouse and email activity in a separate SaaS platform. As it pilots a cloud lakehouse for fresher campaign data, its data architect runs the same queries against both warehouses for weeks or months. Matching order and cart-value figures supports a gradual switch; a mismatch may reveal a legacy SQL script that must be rebuilt. section 5.4.1 section 5.4.3

Table 5.3 Summarizing key challenges

Aspect

Brownfield

Greenfield

Parallel runs

Often crucial to compare new versus old metrics; doubles costs temporarily

Usually not required unless you’re connecting multiple SaaS tools at once

Legacy scripts

Must be reverse-engineered or retired

Minimal or no legacy code, but risk of hidden logic in SaaS tools

Scalability

Must migrate data gradually to avoid disruption

Can scale from day one, but must define naming conventions early

AI readiness

Potentially delayed if old system can’t handle large ML demands

Easier to integrate AI if the architecture is planned for it

Compare brownfield and greenfield challenges: parallel runs are often crucial when retiring a legacy system, but usually unnecessary when there is no old system to compare. section 5.4.6

The reassurance comes at a price: temporary duplicate storage and operating costs, possible legacy-script rework, and a longer rollout. A greenfield team can often skip the pattern, though it still needs to validate incoming SaaS feeds and avoid new silos. For a brownfield team, define when comparison ends rather than letting two platforms become a permanent expense. Decommissioning the old warehouse can then become a measurable cost saving. section 5.4.3 section 5.4.6

How First-Party Data Activation covers it

How deep it goes
Outlines planning, metric comparison, reconciliation, exit criteria, and decommissioning without specifying query-level implementation.
Examples
Uses an apparel retailer comparing warehouse and lakehouse queries for orders and cart value over weeks or months.
What it assumes
Assumes an existing system to replace; contrasts that brownfield situation with greenfield builds that generally lack a legacy comparison.
What you can do after
Practice/perform a controlled legacy-system off-ramp by reconciling outputs and retiring the old environment after validation.
How it connects
Connects brownfield migration, data lakehouses, data quality, legacy-script migration, and gradual cutover.

Also explained in

Compare how 2 books explain parallel run pattern →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of First-Party Data Activation. The section links point to the parts of the book it draws on.