Background
When organizations modernize around an existing system of record rather than replacing it, a critical question rarely gets the attention it deserves: which system actually owns the data they both touch?
Just because a new system can create or modify a piece of business data does not mean it should. When ownership is not explicitly defined, the platform fills the gap on its own, and the consequences show up later as compliance exposure, data disputes, or operational corrections that are expensive to unwind.
The Problem: Capability Is Not Authority
It surfaces the same way on every project– a data point exists in two systems with no declared owner. A status has no confirmed authority behind it. Every new screen raises another version of the same question. The difference between catching it in design and discovering it after users have acted on it comes down to one question asked consistently and early: who owns this?
Define Data Ownership Before Modernization Begins
This was the case for a recent client who planned to expand into a new product line backed by a partner platform that handled core processing, approvals, and financial records their operation depended on. They engaged 27Global to design and build a modern administration hub around the partner platform, the Azure cloud infrastructure beneath it, and a greenfield data warehouse connecting it all. We reduced every one of those conversations to four questions:
Does the new platform own this data? Read it? Derive it? Or, is it prohibited from creating it at all?
Every data point gets an answer before development begins, and the answer determines the data model, the API contract, and what the interface is allowed to do.
Consider the last category– some data can only be created in the upstream system because business agreements, compliance requirements, or financial processes depend on it having a single authoritative source. Allowing the new platform to create it, even once, can trigger enrollment corrections, financial disputes, or regulatory exposure that far outweighs the cost of asking the question in a design review.
The ownership decisions do not live only in documentation. They are enforced via the data platform rather than the application layer so the rules hold regardless of what any individual developer builds on top. Data the hub owns lives in its own database. Data that belongs to the upstream system is surfaced read-only through the warehouse. There is no path for the hub to create data it was never authorized to create.
When records fail validation they surface in an exception workflow inside the hub, giving the right people visibility before anything downstream is affected. Every ownership decision is documented in Azure DevOps, linked to the design discussion that produced it, so the reasoning stays in the project record long after the team has moved on.
Before Launch
Defining ownership before development begins is what separates a clean build from one that accumulates corrections. On this project, the decisions that typically surface as late-stage rework or production incidents were made in design reviews instead, before any code existed to undo.
Most modernization plans are thorough about what the new platform will do. The question of what it is authorized to own rarely gets the same rigor. That gap tends to stay invisible until a screen gets built, a button gets clicked, or data gets created that had no business being created there. By then the cost of answering it is significantly higher than it would have been in a design conversation.
The framework is simple. The discipline to apply it consistently is where the work is.
If you’re considering modernizing legacy systems but need assistance with your data ownership strategy, contact us!
