Migrating to the cloud is not a data strategy

Why moving your data to Databricks, Snowflake, or any cloud platform doesn't answer your business questions, and what layer is still missing after you migrate

Your company migrated to the cloud a year ago. Can anyone tell you today, without opening a side spreadsheet, who your most profitable customer was last month?

If the answer is no, the problem isn’t the cloud. It’s that two decisions that look like one got treated as one: where your data lives and gets processed, and what that data actually means for your business.

A recent dbt Labs article put it precisely: “your compute platform and your transformation logic are two separate decisions. Most executives approve them as one.” That line describes exactly what we see in mid-sized companies that migrated to Databricks, Snowflake, or any cloud platform expecting the migration itself to answer their business questions — and a year later are still answering those questions in a side spreadsheet.

The two decisions getting confused

Decision one: where data lives and gets processed. This is infrastructure — compute capacity, storage, processing speed, security, compliance. It’s a real problem, and there are excellent vendors solving it: Databricks, Snowflake, BigQuery, and on the open-source side, combinations like DuckDB or ClickHouse over cloud storage. This decision gets settled with a contract, a technical architecture, and a monthly bill.

Decision two: what that data means for the business. This is business semantics — what exactly is an “active customer” (bought in the last 30 days? 90? has an active subscription?), how is a product’s real margin calculated (does it include logistics costs? commissions?), which report is the source of truth when sales and finance report different numbers for the same month. Nobody sells this bundled with the cloud platform. It gets built — or it doesn’t, and that’s where the problem starts.

This confusion isn’t exclusive to SMBs without a technical team. It happens in companies with large budgets and solid engineering teams, because cloud platforms are sold to sound like they solve everything: “upload your data here and you’ll be able to answer any question.” Technically that’s true — the platform can run any query. What it doesn’t solve is which query is the correct one, or what the results actually mean.

What this looks like in practice

Picture a mid-sized company — say, a distributor with 150 employees — that moved its ERP and sales data to the cloud a year ago. The migration went well: the data is there, accessible, with dashboards connected. But these things happen, all at once:

• The sales team calculates “monthly sales” by summing invoiced orders. The finance team calculates “monthly sales” by summing collected payments. Neither is wrong — they’re measuring different things with the same name.
• A manager asks for “the top 10 most profitable customers” and gets three different answers from three different people, because each one defines “profitable” differently (gross margin, net margin, margin after logistics).
• The cloud dashboard shows real-time numbers, but nobody fully trusts them, so a “backup” spreadsheet keeps getting maintained — and in practice, that’s the one actually used to decide.

None of these problems get solved with more compute power or a more modern platform. They get solved by defining, once, in one place, what each business metric means — and making every report in the company query that same definition instead of recalculating it its own way.

Compute vs. semantics: the table that makes the difference clear

	Compute platform (cloud)	Semantic layer (business definition)
What it solves	Where data gets processed and stored	What the data means for the business
Who sells it	Databricks, Snowflake, AWS, GCP, Azure, and open-source vendors	Nobody sells it bundled — it gets built to order
How you measure success	Speed, uptime, compute cost	Whether two different teams get the same number for the same question
What happens if it’s missing	The company can’t handle data volume or speed	The company has fast data but still can’t trust it
What it gets mistaken for	”We migrated, so we have a data strategy”	Technical documentation nobody on the business side reads

The left column is almost always prioritized first, because it’s the one a vendor can sell with a clear business case (“cut your infrastructure cost 30%”). The right column rarely has anyone pushing it — and yet it’s the one that determines whether the cloud investment actually changes how the company operates.

When does this apply, and when doesn’t it?

It applies directly if your company already migrated to the cloud (or is about to) and business questions still don’t have clear answers — if different teams report different numbers for the same thing, if reports take longer to review and correct than to generate, or if the “backup spreadsheet” is still the one actually used to decide.

It doesn’t apply, at least not as an immediate priority, if your company doesn’t have its data centralized anywhere yet — in that case, the compute platform decision is still the first one to solve, because you can’t build a semantic layer on top of data scattered across fifteen disconnected spreadsheets. Order matters: centralize first, define meaning second.

There’s also a third, simpler scenario: small companies with few business metrics, where a well-maintained spreadsheet with clear definitions (documented, even if just in a paragraph) can be enough for now. The semantic layer doesn’t always require a tool — sometimes it just requires someone writing down, once, what each number means and why it’s calculated that way.

How to start building the semantic layer

If reading this far made you recognize that your company has the infrastructure but not the meaning layer, there’s a way to start without buying a new platform or stopping the operation.

First, identify the 5-10 metrics that actually drive decisions. No need to document every piece of data in the company — just the metrics that come up in board or management meetings: monthly sales, margin per product, active customers, customer acquisition cost, whatever gets used to decide. In most 50-to-500-employee companies, that list has fewer than 15 metrics, even though it feels like there are hundreds.

Second, for each metric, write the exact definition in one sentence anyone on the business side can understand. Not a technical formula in a notebook only engineering reads — a clear sentence: “an active customer is someone who bought in the last 90 days,” “net margin is sale price minus product cost minus logistics cost.” This sounds obvious until you actually do the exercise and three different versions of the same definition turn up floating around the company.

Third, make every report using that metric query the same definition, instead of each one recalculating it. This is where technology comes in — a centralized metrics layer, a dbt model, or even a well-documented intermediate table — but only after the business definition is already agreed on. Bringing in the tool before agreeing on the definition repeats the same original mistake: solving the technical part before the business part.

This order doesn’t require a large data team or months of work. It requires someone from the business side — not just technology — sitting down to define, in writing, what each number the company uses to decide actually means.

This week’s takeaway

Before evaluating the next data infrastructure investment, ask yourself a different question than the one your cloud vendor is probably asking: if two people in your company calculate the same metric right now, do they get the same number? If the answer is no, the problem doesn’t get solved with more compute — it gets solved by writing down, in one place, what each number that matters for deciding actually means.

FAQ

Do I need to buy a special tool for the semantic layer?

Not necessarily at first. Specific tools exist for this (dbt, metrics layers, data catalogs), but the real first step is documenting business definitions somewhere accessible to everyone — the tool helps keep that consistent at scale, it doesn’t replace the business decision itself.

Does this only apply to companies that already migrated to the cloud?

It applies especially to those, since they already spent the infrastructure budget and still aren’t seeing the business result they expected. But the principle — separating “where data lives” from “what data means” — applies from day one of any data project, migrated or not.

How do I know if my company has this problem?

The clearest signal: if you ask two people from different teams for the same number (monthly sales, active customers, margin) and get different answers, with neither one technically “wrong,” you have exactly this problem.

How long does it take to build the semantic layer?

It depends on how many critical business metrics you have, but for the 5-10 metrics that actually drive decisions, weeks of focused work is usually enough — it’s not a months-long project if it’s scoped tightly from the start.

---

Want to dig deeper into whether your current data infrastructure has this gap? You can also check our article on vendor lock-in vs. open stack to learn what questions to ask any cloud vendor before committing to a platform.