Data Warehouse to Federated TRE: Migration Playbook
Quick answer. Organisations migrate from centralised data warehouses to federated Trusted Research Environments (TREs) because warehouses concentrate raw patient records in one extract, creating a single regulatory, residency, and breach surface. A federated TRE inverts that pattern — data never leaves the source — and migration proceeds in five disciplined phases: assess the warehouse estate, partition cohorts by custodian and jurisdiction, federate compute through approved query nodes, retire the central copy, and validate that every output still passes governance.
Why warehouses are being retired in 2026
For two decades, the default architecture for population-scale health research has been the centralised data warehouse: extract de-identified records, pipe them into a single analytic store, and grant approved researchers query access. The pattern worked when cohorts were thousands of rows and consent terms were uniform. It no longer scales. Modern biobanks hold multi-omic, imaging, and longitudinal electronic health record (EHR) data across millions of participants, governed by overlapping jurisdictions — General Data Protection Regulation (GDPR) Article 25’s data protection by design, the European Health Data Space (EHDS) secondary-use rules, the United States Health Insurance Portability and Accountability Act (HIPAA), and the Federal Risk and Authorization Management Program (FedRAMP) baseline for federal genomics. A warehouse cannot satisfy all four simultaneously.
The May 2026 UK Biobank incident sharpened the case. Approved researchers walked derived data out through a centralised Software-as-a-Service (SaaS) TRE’s normal workflow — no breach, no malicious actor, just policy operating as designed. Regulators have since asked the same question: if every approved user can be a leak, what architecture removes the warehouse-shaped risk entirely? The answer is a federated Trusted Research Environment, where compute travels to data sitting under each custodian’s existing controls.
The five-phase migration playbook
Warehouse-to-federated TRE migration is a governance programme as much as a technical one. Treating it purely as a lift-and-shift project misses the point: the operating model changes, not just the storage tier. The playbook below assumes a sponsor — typically a chief data officer or research director — with authority over both custodian relationships and the warehouse contract.
Phase 1 — Assess the warehouse estate
Inventory every dataset currently held in the warehouse. For each, record the data custodian, the legal basis for transfer, the consent vintage, the residency jurisdiction, and the retention clock. Most warehouses have accumulated dark cohorts whose original transfer authority has lapsed or whose custodian has since adopted stricter terms. Assessment usually surfaces 15 to 40 per cent of the estate that should never have been centralised — that subset becomes the first migration wave.
Phase 2 — Partition cohorts by custodian and jurisdiction
Group datasets by where they should physically reside under a federated model. A national biobank’s whole-genome sequences belong on infrastructure controlled by the biobank itself, under that country’s residency law. Hospital EHR extracts belong inside the hospital’s security perimeter. Partitioning is the moment when residency rationale moves from policy slide to engineering ticket: each partition becomes a target federation node, and each node inherits the regulatory regime of its host.
Phase 3 — Federate compute through approved query nodes
Deploy the federated TRE stack at each custodian site. Each node exposes a standard query interface, runs containerised analyses inside an isolated execution environment, and routes every result through an automated airlock. Researchers submit a single analysis plan; the federation orchestrator splits it across nodes, executes locally, and aggregates only the summary statistics the airlock has cleared. The warehouse remains operational during this phase — workloads migrate one cohort at a time so ongoing studies are not disrupted.
Phase 4 — Retire the central warehouse copy
Once a cohort has been live on the federation for a defined dual-running period — typically 60 to 90 days — the warehouse copy is decommissioned. Decommissioning means cryptographic deletion of the warehouse partition, a signed attestation of destruction to the custodian, and an update to the data flow register filed under GDPR Article 30. This is the irreversible step regulators care about most; skipping it leaves the original concentration risk in place.
Phase 5 — Validate that governance still holds
Validation is not “did the queries return the same numbers” — that is regression testing, and it should pass by construction. Validation is whether the new operating model satisfies the Five Safes (safe data, safe projects, safe people, safe settings, safe outputs) at least as well as the warehouse did. Sample twenty recent project approvals from the legacy system, replay them against the federated environment, and document where the controls now sit. Most programmes find that safe outputs strengthen significantly because the airlock is automated rather than manual.
Migration risk comparison
The risk profile of a warehouse migration differs sharply depending on the destination architecture. A warehouse-to-warehouse migration (for example, an on-premise warehouse to a cloud warehouse) preserves the centralisation pattern and therefore preserves most of the residency and breach risk. A warehouse-to-federated TRE migration restructures the risk surface entirely.
| Risk dimension | Warehouse-to-warehouse migration | Warehouse-to-federated TRE migration |
|---|---|---|
| Residency exposure during cutover | High — single bulk transfer creates a second copy until decommission | Low — records remain at custodian throughout; only query interfaces are added |
| Re-consent burden | Often required because the new processor changes the legal basis | Usually unchanged because the custodian remains the controller |
| Project-approval continuity | Approvals frequently re-issued under the new processor agreement | Existing approvals carry forward; airlock layer is additive |
| GDPR Article 25 alignment | Weak — concentration risk persists | Strong — minimisation enforced by architecture |
| EHDS secondary-use readiness | Requires bespoke data access body integration | Native — federation maps directly to EHDS node model |
| Rollback path if migration stalls | Limited — partial extracts are hard to reverse cleanly | Clean — federation runs in parallel; warehouse remains until Phase 4 |
| Breach blast radius post-migration | One credentialed account can exfiltrate the full estate | Bounded to a single custodian’s records, and only post-airlock outputs |
Data residency: the rationale that ends the warehouse debate
Residency was once a policy preference. Under EHDS and the wave of national health data acts that followed it through 2025 and 2026, residency is a hard architectural requirement: secondary-use health data must remain under the custodian’s jurisdiction, and cross-border processing must be authorised through a recognised data access body. A centralised warehouse can comply only by maintaining a separate physical instance per jurisdiction — which is, in effect, federation done badly. The federated TRE pattern collapses this complexity. Each custodian retains physical possession; researchers see a single logical query surface; the federation layer handles authorisation, audit, and the airlock. Residency stops being a deployment headache and becomes the default.
GDPR Article 25’s principle of data protection by design and by default reinforces the same conclusion. A warehouse extract, however well-secured, is a deliberate concentration of personal data that the controller chose to create. Article 25 expects controllers to choose the architecture that minimises that concentration in the first place. A federated TRE is that architecture in its cleanest form: only derived, airlock-approved outputs are ever centralised, and the underlying records remain where they were collected.
Compliance benefits the migration unlocks
Beyond residency, federated TRE migration delivers compliance gains that warehouses cannot match.
- EHDS Article 50 alignment. The European Health Data Space requires secondary-use access through a network of recognised health data access bodies. A federated TRE deployed at each custodian maps one-to-one onto this model; a warehouse requires bespoke gateways.
- Five Safes embedded by architecture. Office for National Statistics (ONS) Five Safes guidance treats safe outputs as a process control. Federation makes it a code control, executed by the airlock on every result.
- Audit trail per custodian. Every query, every approval, and every airlock decision is logged at the node level, satisfying both GDPR Article 30 records-of-processing and HIPAA audit-control requirements without bespoke reconciliation work.
- FedRAMP and sovereign baselines reusable. Because each node inherits the host environment’s accreditation, a custodian already certified under FedRAMP Moderate or a national equivalent does not need to re-accredit the entire research stack.
- Reduced data processing agreement (DPA) surface. Custodians remain controllers; the federation operator is a processor for the federation layer only, not for the underlying records.
Practical next steps
For programmes planning a 2026 or 2027 migration, sequencing matters more than tooling. Start with a single high-value cohort — typically one where residency pressure is already forcing change — and run Phases 1 through 3 as a contained pilot before extending across the estate. Budget for a longer Phase 5 than feels necessary; validation is where regulators and ethics committees spend their attention, and a confident validation report is what unlocks Phase 4 sign-off.
Frequently asked questions
How long does a warehouse-to-federated TRE migration typically take?
End-to-end, between 12 and 24 months for a national-scale estate. The first cohort can be live on the federation within 90 days; the long tail is Phase 4 (warehouse retirement) and Phase 5 (governance validation), which run in parallel across remaining cohorts.
Do existing research projects have to be re-approved?
Usually not. Because the custodian remains the data controller and the legal basis is unchanged, existing approvals carry forward. What changes is where the analysis physically runs, which is a processor-layer change rather than a controller-layer change.
What happens to the warehouse during the migration?
It stays operational. Federation runs alongside the warehouse for a dual-running period of 60 to 90 days per cohort, so ongoing studies are not disrupted. The warehouse is only decommissioned after a cohort has been validated on the federation.
Can researchers still run cross-cohort analyses once data is federated?
Yes — that is the federation layer’s primary job. A query is split across the relevant nodes, executed locally at each custodian, and only summary statistics or aggregated results are returned through the airlock. Researchers see a single logical cohort even though no records have moved.
How does federated TRE migration interact with EHDS?
It aligns natively. EHDS requires secondary-use access through a network of recognised health data access bodies, each operating in its own jurisdiction. A federated TRE deployed at each custodian fits this network model directly, where a centralised warehouse would require bespoke residency engineering for each EHDS-aligned country.
What is the biggest risk in the migration?
Skipping Phase 4. Programmes that federate compute but leave the warehouse running indefinitely retain the original concentration risk and undermine the regulatory case for migrating in the first place. Decommissioning the central copy is the step that converts federation from a layer into an architecture.
Does federation slow down analysis compared with a warehouse?
For most population-scale workloads, no. Queries run in parallel across nodes, so wall-clock time scales with the slowest node rather than total estate size. Complex cross-cohort joins can require an extra orchestration round-trip, but the governance saving typically outweighs the marginal latency.