Fortune-100 Retailer: engineering the data separation behind a cloud-native demerger
A Fortune-100 retailer separating from its parent needed its customer, product and supply chain data untangled before cutover. Unolabs designed the sovereign Azure Lakehouse, entitlement filtering and separation governance that carried the split. The new entity now runs on governed data products, with ≈$2.5M in migration savings validated with client finance.
A concise view of impact and engineering focus.
≈$2.5M migration savings
Sovereign AI Residency
Agentic-Ready Foundation
Why the demerger was a data engineering problem
A Fortune-100 retailer had to separate from its parent organisation without losing the structural integrity of its customer, product and supply chain intelligence. On paper that is a corporate event. In practice it is a data engineering problem.
Years of legacy architectural fragmentation had entangled customer records, product hierarchies and supply signals across shared systems. No clean line marked which assets belonged to which entity. Every dataset that could not be attributed, entitled and migrated cleanly was a direct risk to the cutover date, and disconnected ownership threatened the new entity's operational resilience well past it.
So the engagement did not begin with migration tooling. It began by treating the split as an architectural separation problem: map ownership, govern it, then execute against it with an audit trail that would survive scrutiny from both sides of the split. In a separation both sides hold a legitimate claim on overlapping records, and only one of them can keep each. Until that question is answered, neither risk retires.
Demergers fail on unmapped dependencies, not on migration tooling. Establishing which entity owns each dataset — before any data moves — is the single highest-leverage engineering activity in a separation programme.
How five disciplines turned the split into a repeatable pipeline
We engineered the separation as a governed architectural product rather than a sequence of ad-hoc migrations. Five disciplines ran as one programme: discovery, audit, target state architecture, migration sequencing and automated governance. Every enterprise asset and dependency was mapped before cutover rather than during it, which is the difference between a sequenced programme and a run of weekend emergencies.
Discovery and audit produced the dependency inventory. Target state design defined the sovereign Azure Lakehouse the new entity would land on. Migration sequencing ordered workloads so that upstream dependencies always moved before their consumers — the constraint that decides whether a wave lands cleanly or leaves a consumer querying a table that no longer exists.
Automated governance enforced the separation policies continuously rather than through manual review gates. Infrastructure-as-Code made each modernisation environment repeatable, which mattered because environments had to be rebuilt consistently across successive migration waves without configuration drift. What the programme produced was a separation machine, not a project plan.
- Sovereign cloud platform design using Azure Lakehouse architecture
- Infrastructure-as-Code for repeatable modernisation environments across waves
- Governed data pipelines for customer, product and operational intelligence
- Advanced RBAC and domain-scoped separation policies for the new entity
- Continuous governance enforcing auditable cutover controls in the pipeline
Automated governance replaced manual review gates: separation policies were enforced in the pipeline itself, so compliance checks scaled with migration volume instead of becoming the bottleneck.
Rebuilding access control from the entity boundary outward
The target state is a secure, domain-oriented intelligence platform serving both advisory and operational teams. Data ownership follows business domains, so the teams accountable for customer, product and supply chain outcomes also own the definitions and the quality of their data products.
Metadata standards were applied consistently across the estate, giving the new entity lineage it can show to an auditor and to an engineer without translating between the two. Security guardrails — advanced RBAC and domain-scoped separation policies — grant access along entity and domain boundaries rather than inheriting it from legacy parent-company structures.
That second decision is the expensive one. Inherited permissions do not announce themselves; they simply keep working after the legal split. Rebuilding entitlement from the entity boundary outward cost more up front than porting the existing model, and it is why the new retail entity launched with analytics it could trust from day one, on datasets clean enough to feed agentic workloads rather than dashboards alone.
Access control was rebuilt from entity boundaries outward rather than ported from the parent estate — inherited RBAC is one of the most common ways separated companies silently retain access to each other's data.
What the separation left behind
The engagement delivered a multi-terabyte cloud transformation on schedule, ≈$2.5M in migration savings validated with client finance, and a demerger-ready sovereign data foundation for the new entity.
Because the platform was built as governed data products rather than replicated legacy structures, it does more than reporting. It supports agentic reasoning loops for demand planning and provides decision-support for freight negotiation. The separation machinery — entitlement filtering, delta reconciliation and identity mapping — stayed in place afterwards as the governance backbone of the new estate rather than being decommissioned with the programme.
One thing to budget for. A separation of this scale is discovery-heavy: the dependency-mapping phase consumes real calendar time before any visible migration progress, and it is the first phase compressed when a steering committee wants movement. Teams planning similar programmes should treat that time as the work rather than as overhead, because it decides how much of everything after it is guesswork.
What we'd flag: freight negotiation runs as decision-support, with humans making the final commercial call — we would not describe any part of this stack as autonomously executing commercial decisions, and that distinction matters in diligence.
Technical blueprint of the solution
This diagram visualises the core architectural pattern, data flows, and security boundaries implemented during this engagement.
What to carry into the next sprint
Takeaway
Answer the ownership question for every dataset before any data moves.
Takeaway
Rebuild entitlement from the new entity's boundary instead of porting parent RBAC.
Takeaway
Budget dependency mapping as delivery work, not as pre-project overhead.
Frequently asked questions
- What should be fixed first when separating two entangled data estates?
- Ownership. Before any data moves, every dataset needs a defensible answer to which entity it belongs to and who is entitled to see it. In this Fortune-100 retail demerger, discovery and audit produced that dependency inventory first, and the migration sequence was derived from it. Estates that skip the step find the gaps at cutover, when the remaining options are all expensive.
- Why does dependency mapping feel like it produces no progress?
- Because it produces a map rather than a migrated system. A separation of this scale is discovery-heavy, and the mapping phase consumes real calendar time before any visible migration progress appears. It is also the phase most often compressed under delivery pressure. Compressing it does not remove the work; it moves the work to the cutover weekend, where it costs considerably more.
- Does the platform make commercial decisions on its own?
- No. Freight negotiation runs as decision-support, with a human making the final commercial call, and demand planning uses agentic reasoning loops rather than autonomous execution. We would not describe any part of this stack as autonomously committing the business to a price or a contract. That distinction is worth confirming explicitly in any diligence review of an agentic claim.
- Can a demerged entity simply inherit its parent's access model?
- It can, and that is precisely the risk. Inherited permissions keep working after the legal separation, which is how two separated companies quietly retain access to each other's data. Access control here was rebuilt from entity boundaries outward using advanced RBAC and domain-scoped separation policies, so rights are granted along entity and domain lines rather than carried across from the parent estate.
- What is the ≈$2.5M savings figure measured against?
- It is a migration savings figure validated with the client's own finance function during the programme, not an independently audited benchmark and not a recurring run-rate saving. Anyone reading it as a forecast for their own separation should note that savings of this kind scale with the size and the entanglement of the estate being split, both of which vary widely.
Map your separation dependencies before the date is fixed
We will walk your estate with you and identify which datasets have no defensible owner, which entitlements would be silently inherited at cutover, and where the real sequencing risk sits.
Book a Separation Review