Almost every data platform assessment we are asked to review opens with the same section, which is an inventory of source systems and a target architecture diagram. It is competent work and it answers a question nobody was stuck on.
Microsoft’s own framework for this puts something else first, and the ordering is deliberate. The four steps are organisational readiness, then architecture, then governance and security baselines, then operational standards. Architecture is second. What comes before it is deciding who owns which data.
An assessment that skips step one produces a design that is technically sound and organisationally homeless. That is the failure mode this piece is about.
What step one actually asks
Organisational readiness is defined narrowly enough to be actionable: define your data strategy, establish data ownership and domains, clarify how data creates business value, and clarify who is accountable for which data.
That last clause is the one that decides whether a platform programme lands. Not who maintains the pipeline, which is an IT question with an easy answer. Who is accountable for whether the numbers are right, which is a business question with an uncomfortable one.
In our engagements the question that stalls an assessment is never technical. It is asking a room of stakeholders to name the single owner of customer, or product, or revenue, and watching the conversation stop. That silence is the finding. A platform built without resolving it inherits the ambiguity and adds a technology layer on top, which is how organisations end up with three certified versions of the same measure and a governance forum to arbitrate between them.
The reason this belongs in an assessment rather than a later phase is sequencing cost. Ownership is cheap to establish on a whiteboard and expensive to retrofit into a platform that already serves reports to executives.
The architecture question is smaller than it used to be
The second reason assessments over-invest in architecture is that they are still scoped as though the answer were a migration. It usually is not.
Fabric connects to existing systems through virtualisation, using shortcuts, and selective replication, using mirroring. The stated benefit is minimal business disruption: teams unify access to data without interrupting current operations. That materially changes what an assessment should recommend, because the historic answer to a fragmented estate was to consolidate it, and consolidation is what made these programmes long and risky.
Microsoft is explicit that unifying a data platform is an investment in capability rather than a wholesale replacement of every system, and that the goal is to keep using existing data systems while building a shared foundation. Time to value follows from that: because unification does not depend on full migration, organisations can start with a small set of high-value data products and see value within weeks for initial analytics or AI scenarios.
So the useful architectural output of an assessment is not a target-state diagram. It is a shortlist of which sources to virtualise, which to mirror, and which genuinely need to move. Those are three different decisions with three different costs, and most assessments collapse them into one.
Costs an assessment should price, and usually does not
Worth listing, because assessments routinely produce a licence number and call it a budget.
| Component | What actually drives the cost |
| Fabric compute | The capacities you provision |
| OneLake storage | Volume stored |
| Mirroring | The replication you perform |
| Power BI | Either sufficient Fabric capacity that includes Power BI, or separate licences |
| Purview | Subscription licensing and consumption, by data volume and services governed |
| Azure | No charge for subscriptions, but integrated services such as Databricks or Machine Learning carry their own pricing |
Two of those are the ones that surprise people. Purview is billed on both a subscription and a consumption basis, so the cost scales with how much of the estate you actually govern rather than being a flat platform fee. And Power BI access is a licensing decision that depends on the capacity you bought, which is why it belongs in the assessment rather than in a later procurement conversation.
If capacity sizing is where your assessment is heading, Fabric capacity planning and chargeback is the harder half of that question and worth reading before committing to an F-number.
Ownership is not undocumented, it is unanswered
Worth being precise about this, because the two are different problems and only one of them is hard.
Undocumented ownership means someone knows and it was never written down. That is an afternoon’s work. Unanswered ownership means nobody has ever decided, and in the assessments we run that is the usual case: ownership is mostly ignored and unanswered rather than merely unrecorded.
There is a pattern to how it stays that way. Assessments tend to open on target architecture with a push to include everything, because breadth feels like thoroughness and nobody wants to be the person who left a system out. Then, as the assessment goes deep and the effort becomes real, scope stripping starts.
Notice what gets stripped. Not the architecture diagram, which is the visible deliverable everyone is expecting. What gets dropped is the uncomfortable, slow, political work, which is exactly the ownership conversation. So the assessment ends up with the artefact it started with and without the answer it most needed, and the sequence looks reasonable at every individual step.
The fix is not discipline, it is ordering. Put ownership first, while there is still appetite and budget, and let architecture absorb the scope reduction later if it has to. An architecture shortlist that covers three domains properly is more useful than one that covers twelve at the depth of a diagram.
Governance is a baseline, not a later phase
Step three in the framework is governance and security baselines, and the wording matters: built into the architecture from the start, using Purview for central visibility across the estate, wherever the data sits, whether that is OneLake, Azure, on-premises, third-party SaaS or another cloud.
The reason this is a step rather than a workstream is that governance applied afterwards is applied to a platform that people already depend on, which means every control is a negotiation with an existing consumer. Applied at the baseline, it is simply how the platform works.
There is a practical consequence for the assessment itself. If governance is a design input, the assessment has to establish classification and access requirements up front, which means it needs the ownership answers from step one. The framework is ordered the way it is because each step depends on the one before it, and that dependency is exactly what an assessment that opens with architecture breaks.
Operational standards are what stop it decaying
The fourth step is the one most likely to be cut, and it is the one that determines whether the platform is still trustworthy in two years: consistent processes for ingesting raw data, creating data products, and managing their lifecycle, plus how data products are published, secured and consumed.
The phrase to notice is data product, because it implies something with an owner, a consumer and a lifecycle, rather than a table someone built. An assessment that recommends a platform without defining what a data product is, and who publishes one, has recommended infrastructure rather than a capability.
Our position: the assessment is a decision document, not a survey
In our view a data platform assessment has failed if its main output is a description of the current estate. Everyone already knows the estate is fragmented. That is why they commissioned the assessment.
The output that earns its fee is a set of decisions: who owns which domain, which sources are virtualised rather than moved, what the first two or three data products are, and what governance baseline applies before anyone builds. We would not deliver an assessment whose recommendations could not be argued with, because a document nobody can disagree with is a document nobody has to act on.
The corollary is that assessments should be short. In our engagements the ones that produce change take weeks rather than months, because the value is in forcing the ownership conversation rather than in the completeness of the inventory. A long assessment usually means the difficult questions were deferred into more analysis.
So: weeks, not months. Our own record is two weeks, and the reason it was two weeks rather than eight is worth stating, because it is the method rather than the scope.
Run it as working sessions with the stakeholders. Not interviews followed by a written synthesis circulated for comment, which is how most assessments are structured and why most of them take a quarter. Sessions where the people who would have to agree are in the room together, deciding, with the output written as you go.
That format is what makes ownership resolvable at all. A question like who owns customer cannot be answered by interviewing three people separately and reconciling their answers afterwards, because what you get is three answers and a document that has to arbitrate. In a working session it is a decision, taken by people with the standing to take it, in the time it takes to have the argument.
Where this connects
Two things worth linking, because they are the questions that follow an assessment.
If the estate includes Synapse dedicated SQL pools, what a Synapse to Fabric migration does and does not move determines how much of your source list can be virtualised rather than rebuilt.
And once a platform exists, the operating question is capacity and who pays for it, which is where most programmes meet their first real governance test.
Where to start
Before commissioning an assessment, try to answer one question in a room: name the accountable owner for your three most contested data domains. If that takes ten minutes, an architectural assessment is the right next step. If it takes an hour and ends unresolved, you have found the thing the assessment should be about.
Then scope the assessment to produce decisions rather than description, and cap it at weeks.
Veratas runs data consulting engagements and builds platforms on Microsoft Fabric, including the ownership work that decides whether the platform holds.
If you have an assessment that produced a good diagram and no decisions, talk to our team. The second assessment is usually much shorter than the first.
Frequently asked questions
What should a data platform assessment cover? Microsoft’s framework orders it as organisational readiness, architecture, governance and security baselines, then operational standards. Readiness comes first and means data strategy, ownership and domains, and who is accountable for which data.
Do we have to migrate everything into Fabric? No. Fabric connects to existing systems using shortcuts for virtualisation and mirroring for selective replication, which is designed to unify access without interrupting operations. The useful assessment output is which sources to virtualise, which to mirror and which genuinely need to move.
How quickly can we expect value? Because unification does not depend on full migration, Microsoft’s guidance is that organisations starting with a small set of high-value data products often see value within weeks for initial analytics or AI scenarios.
What costs should we budget beyond licences? Fabric compute capacities, OneLake storage, mirroring replication and Power BI licensing, plus Purview on both a subscription and a consumption basis. Integrated Azure services such as Databricks or Machine Learning carry their own pricing.
When should governance be designed? At the baseline, not afterwards. Governance applied to a platform people already depend on becomes a negotiation with every existing consumer, which is why the framework places it before operational standards rather than after go-live.
How long should a data platform assessment take? Weeks rather than months. The method matters more than the scope: run it as working sessions with the stakeholders in the room deciding together, rather than separate interviews synthesised into a document afterwards. Our own record is two weeks.
Why do assessments so often skip data ownership? Because they open on target architecture with a push to include everything, and then strip scope as the effort becomes real. What gets stripped is the slow, political work rather than the visible deliverable, which means ownership is usually the first thing dropped and the thing most needed.
What is a data product? Something with a defined owner, consumers and a lifecycle, published and secured to a standard, rather than a table someone built. An assessment that does not define what a data product is has recommended infrastructure rather than a capability.
Azure and Business Intelligence Architect with 17+ years of experience delivering cloud data and analytics solutions. Focus areas include Azure data platforms, ETL and ELT architecture, and enterprise BI on Microsoft Azure.