Platform, Engineering or Operating Model? A Data Platform Assessment Before You Re-Platform
Every executive in the room is being asked to fund a re-platforming programme on the strength of symptoms.
In this article
The quarterly review has three slides. Platform run cost is up again. The sales dashboard still refreshes after the 10 a.m. meeting starts. And engineering has a replacement proposal ready, with a vendor’s migration estimate attached.
Every executive in the room is being asked to fund a re-platforming programme on the strength of symptoms. A data platform assessment exists to ask the earlier question: is the platform actually the cause?
1The short answer
Re-platform when the best-built, clearly owned workload still cannot meet a stated business requirement on your current platform.
If weak pipelines, duplicated logic or unclear ownership explain the symptom, a new platform inherits the cause along with the data. Causes often coexist, so the defensible decision is frequently a sequence of interventions rather than a single choice.
This is Logesys’s professional view, not an industry standard.
2Why symptoms alone do not justify re-platforming
One late dashboard has several possible causes: a slow query, a weak data model, an upstream pipeline that finished late, saturated capacity, or a metric nobody is accountable for. Replacing the platform addresses only one of them.
Vendor documentation shows why the cause has to be established first. A note in Microsoft’s Fabric throttling guidance says that, within Fabric, slow performance is often due to an item’s design and only sometimes to capacity throttling. Databricks and Snowflake both document query profiles that expose exploding joins, full scans, spilling and poor pruning, which are faults in queries and data layout. AWS’s large-migration guidance lists seven migration strategies, including retain and retire, to be chosen workload by workload. For large programmes it advises against refactoring during the move and suggests modernizing afterwards. Our reading: a workload moved without redesign arrives with its existing logic intact.
The functions in the room also read one symptom differently.
- Finance sees run cost
- The business sees lateness
- Engineering sees a backlog
- The CDO sees eroding trust
A diagnosis has to reconcile all four.
3A symptom-to-root-cause framework
Ask one question per lens before approving funding:
- PlatformDoes a well-engineered workload still miss a stated requirement, such as concurrency, latency, data types, residency or vendor support?
- EngineeringIs the failure concentrated in specific pipelines, models or queries that can be fixed individually?
- Operating modelCan someone name who owns each disputed metric, failing pipeline and line of run cost, and do they act on it?
The evidence column below is the point. A cause without evidence is an opinion.
| Observed symptom | Possible root causes | Evidence to examine | Decision implication |
|---|---|---|---|
| Reports late or slow | Query design or data model; late upstream pipelines; contended capacity; no agreed freshness requirement | Query profiles for the slowest reports; pipeline finish times against refresh times; utilisation and queueing; the written requirement | Tuning or modelling: optimise. Late upstream: repair pipelines. Saturation that persists after tuning: evaluate capacity or platform. No requirement: operating model |
| Same metric, different numbers | Duplicated transformation logic; competing definitions; no metric owner | Number of pipelines producing the metric; definition documents; who approved each version | Consolidate logic and assign an owner. A new platform does not settle definitions |
| Pipelines fail or need manual repair | No tests, alerts or retries; unannounced upstream schema changes; genuine platform limits | Failures by cause; time to detect and recover | Repair and add observability. Platform only where failures trace to limits it cannot meet |
| Run cost outpaces usage | Inefficient workloads; idle or duplicated compute; pricing model mismatched to workload; no cost owner | Cost by workload and team; utilisation; unused jobs and tables; who reviews the bill | Optimise and assign accountability first. A mismatch shown on a representative workload justifies evaluation |
| New use cases take months | Rebuilt ingestion; approval queues; scarce skills; architectural block | Lead time split into waiting, building and rework; reuse of existing pipelines; list of blocked requirements | Change delivery process and ownership. Migrate only if blocked requirements are architectural |
| Platform delivered, little used | Low trust; no business owner; wrong fit for users | Usage by team; support tickets; an owner for each data product | Product ownership and operating model. Re-platforming does not create adoption |
Scroll the table sideways to see all columns
If you cannot produce the evidence column for your two most escalated symptoms, that gap is the first finding. A data engineering assessment of those two symptoms is a sensible first spend.
4Evidence that separates platform problems from operating-model problems
Platform problems appear under controlled conditions
Test the worst workload tuned and well modelled, under the conditions that matter in production: representative data volume, peak concurrency, recovery scenarios and run-cost limits. Passing weakens the case for replacement on that requirement; one clean run proves little. A failure is a prompt to investigate the mechanism (capacity, engine limits, cost per query, a missing capability, or a remaining design fault) before concluding the platform must go.
Operating-model problems survive any platform
The same metric differs between teams, fixes regress because no one owns the pipeline, data products ship without a business owner, and costs have no accountable reviewer. The FinOps Foundation describes shared accountability among engineering, finance and business teams, and extends it to data cloud platforms. A data operating model assessment tests whether that accountability exists in practice rather than on an organisation chart.
Engineering problems sit between the two
They are concentrated, fixable and measurable: failures cluster in a few pipelines, repairing them moves the metric, and duplicated ingestion explains much of the load. Our piece on the Fragmentation Ceiling describes how duplicated pipelines accumulate.
Causes coexist more often than a vendor proposal admits. Take an illustrative mixed case: capacity is genuinely saturated, but duplicated pipelines are generating much of the load. Resizing or migrating first would hide the duplication, lock it into a new contract, and leave the CIO explaining a second programme a year later. Removing the duplication first may show how much capacity was really needed, and that sequencing decision is where an independent view earns its cost.
5From evidence to investment
| If the evidence shows | Fund |
|---|---|
| Failures concentrated in queries, models or schedules | Optimisation of the existing platform |
| Fragile or duplicated pipelines | Repair or rebuild of selected pipelines and data products, with observability |
| Disputed ownership, definitions or cost accountability | Redesign of decision rights, governance and operating processes |
| A tuned, owned workload that still misses a requirement; ending vendor support; a cost model a representative test shows does not fit | Re-platforming evaluation for those workloads |
| Several of the above | A sequence: ownership and repairs first, then migration of what the evidence still justifies |
Migration is the right answer when a tuned, well-owned workload still fails a stated requirement, when support for the current platform is ending, or when residency or regulatory needs cannot be met. Wrong funding costs twice: the programme budget, and the months before the real cause is found. Migrate only the scope the evidence justifies, and decide asset by asset what to carry. Our Data Estate Triage article sets out how. If the target is a lakehouse, the relevant context is Databricks or Microsoft Fabric.
Logesys partners with both vendors, so expect an assessment from us to show its working on why a migration is or is not warranted.
6What a structured assessment should clarify
It should establish whether the dominant constraint is technical, engineering or organisational; which evidence supports that diagnosis; which interventions deserve priority and in what order; and whether optimisation, targeted modernisation or migration merits further evaluation. It should end with a decision a CFO can defend: what to fund, what to defer, and what new evidence would change the answer.
A suggested scope to agree with any provider, Logesys included:
- A symptom-to-root-cause map
- A list of evidence gaps
- Prioritised remediation options
- A written rationale for each decision to optimise, redesign or evaluate replacement
7Where Logesys can help
Logesys’s data engineering team works on the pipelines, governance and observability that produce this evidence, and on migration when it is justified. One published case study describes handling duplicate files and inconsistent naming at the point of ingestion; results there are as reported by Logesys.
Before the replacement proposal reaches approval, talk to the team about assessing it. Bring:
- The two or three symptoms leadership is escalating
- Recent platform cost and utilisation reports
- A list of the pipelines that fail most often
- The names of whoever owns the metrics in dispute
What the conversation is for
The aim of the conversation is to help leadership decide what to fix now, what to defer, and whether the evidence supports evaluating replacement. We can agree what an assessment of your estate would cover; no outcome is guaranteed, and the evidence may well say the platform should stay.
8FAQs
What is a data platform assessment?
A data platform assessment tests whether your platform, your engineering or your operating model explains the problems you are seeing. It links each symptom to possible causes, the evidence that would confirm or weaken each one, and the investment that follows.
How do I decide whether to replace a data warehouse or fix it?
Replace when a tuned, well-modelled, clearly owned workload still misses a stated requirement, when vendor support is ending, or when residency or regulatory needs cannot be met. Otherwise, optimising workloads, repairing pipelines or fixing ownership usually addresses the cause first.
How does a data platform health check differ from a data platform maturity assessment and a data operating model assessment?
A health check usually reviews configuration, performance, cost and risk. A maturity assessment scores capabilities against a scale. A data operating model assessment examines ownership, decision rights and accountability. A diagnostic of the kind described here starts from a symptom and asks which of these explains it.
What evidence should I ask for before approving a migration?
Ask for results from the worst workloads after tuning, failures grouped by cause, cost by workload and owner, the written business requirement each workload misses, and the named owner of every disputed metric.
Can the platform and the operating model both be the problem?
Yes. Technical and organisational causes often coexist, which is why the decision is frequently a sequence: fix ownership and pipelines first, then migrate what the evidence still justifies.
What should I bring to an assessment conversation?
The symptoms leadership is escalating, recent cost and utilisation reports, the pipelines that fail most often, and who owns the metrics in dispute.
How long does an assessment take and what does it cost?
That depends on how many platforms, workloads and teams are in scope, so treat any fixed figure given without seeing your estate with caution. Logesys would scope it in a conversation; no timeline or price is stated here.
Before the replacement proposal reaches approval
Talk to Logesys’s data engineering team about assessing it.
Or write to connect@logesys.com