Every mid-market technology or data leader is being sold the same vision: migrate to Snowflake, wire it up with Fivetran, layer dbt on top, and your organization becomes a modern, AI-ready data powerhouse. The pitch is compelling. The logos on the case studies are impressive.
And, the implicit message is hard to ignore: if you’re not there yet, you’re behind. The FOMO gets real, real fast.
Well, I’m not there yet. And I want to explain why that’s a strategic decision, not a gap.
This isn’t a contrarian take on modern data platforms. Snowflake and Databricks are excellent products. Fivetran solves real problems. dbt has earned its place in the stack.
I want to use them. But, I also have to properly steward the data and technology spend. Far less exciting things like value and ROI still matter.
What I’m skeptical of here isn’t the technology – it’s the reflexive adoption of it.
This hesitation didn’t start with a spreadsheet. It started with an intuition that the ROI math on the modern data stack doesn’t automatically math, at least not in our mid-market environment.
We’re now putting harder numbers on that intuition, and I want to share the framework for others who may be feeling the same pressure.
Fair warning upfront: Platform pricing changes frequently and sometimes dramatically, as recent Fivetran pricing changes reminded the market. Treat the figures here as directional, and sanity-check current rates directly before making decisions.
What the Modern Stack Actually Assumes
Snowflake is often the center of this conversation, so I’m going to use it as our example.
And the ROI case for Snowflake + Fivetran + dbt is real – but it rests on a specific set of conditions that aren’t universal:
- You have data at scale across multiple heterogeneous sources that need harmonization
- Your analytics consumers need self-service access at volume and concurrency
- Your source data is complex, semi-structured, or arriving in real time
- You have – or can hire – the data engineering depth to optimize and operate it
When those conditions are met, you go full send without looking back. When they aren’t, you may be purchasing infrastructure for a problem you don’t have.
What It Actually Costs
Let’s put real numbers to the “modern stack” decision, because vendor presentations tend to skip this part.
Snowflake on AWS runs roughly $2/credit on-demand for Standard, or around $3/credit for Enterprise – the tier many production workloads require. A mid-market team running moderate analytics workloads can expect $1,500-$8,000/month just in compute and storage, with larger or less-optimized deployments pushing $25,000-$40,000/month.
Costs are notoriously variable and hard to forecast before you actually run your workloads.
Fivetran is its own line item on top of that. And, while I am not joining the chatter about Fivetran’s recent pricing changes, I want to point out they do highlight the need for leaders to model usage patterns before committing. A modest mid-market setup – 10 to 20 connectors moving 50M+ rows monthly – can now represent a meaningful monthly expense before analytics value is even realized.
Add dbt Cloud, a BI layer, and the data engineering headcount to operate it all, and you’re looking at a fully loaded cost that can easily reach $150,000-$300,000+ annually before you’ve produced a single business insight.
Again – that spend is justified when the problem calls for it. The question is whether your problem calls for it.
The Overlooked Case for Legacy ERP Environments
Our environment is built around a heavily customized Microsoft Dynamics GP implementation, which uses Microsoft SQL Server as its backend. Like many mid-market companies, we’ve accumulated years of structured, relational data that reflects how our business actually runs.
It’s not glamorous by modern data-platform standards, but it’s clean, it’s known, and it’s ours.
The conventional wisdom says this is a liability – legacy ERP is the thing you migrate away from. And at some point in the roadmap, that must happen. Until then, I’d argue the data architecture of a legacy ERP like Dynamics GP can actually be an asset – one that often gets undervalued because the migration conversation tends to overshadow what the existing stack can already do.
Here’s what structured, well-understood relational data in SQL Server actually enables, right now, without a six-figure platform migration: MCP on SQL Server.
MCP on SQL Server: The Solution Many Leaders Overlook
Model Context Protocol, or MCP, is an open standard that defines how AI agents discover and interact with external tools and data sources.
Microsoft’s SQL MCP Server – built on open-source Data API Builder – gives AI agents a controlled way to interact with SQL databases through MCP tools, configured entities, stored procedures, and role-based permissions.
The natural language experience happens at the agent layer. The database interaction remains appropriately governed in the RDBMS layer.
The architecture is straightforward: configure entities, expose the appropriate data and operations through the MCP server, and allow an AI agent to query, summarize, and reason over operational data directly – without moving it somewhere else first.
And, for an organization with structured ERP data already in SQL Server on Azure, this may be the right first architecture.
The total incremental cost to implement MCP on an existing SQL Server on Azure is primarily engineering time for configuration, permission design, testing, and security review.
No new platform contracts. No per-connector billing surprises. No six-figure annual commitment before you understand your usage shape.
When the Migration Does Make Sense
I want to be clear:
This is not an argument against Snowflake, Databricks, Fivetran, dbt, or modern data platforms categorically.
There are organizations for which those platforms are clearly the right answer, right now:
- Multi-source environments where data from Salesforce, Marketo, a data warehouse, and external feeds genuinely need to be unified and served at scale
- Organizations with analytics teams large enough to require true self-service concurrency
- Businesses where ML/AI use cases demand the kind of unstructured or semi-structured data processing that SQL Server wasn’t designed for
- Companies that have genuinely outgrown their RDBMS – large data volumes, complex transformations, and the engineering team to operate a modern lakehouse
If those conditions describe your organization, build the business case and make the investment. The platforms are excellent – and the ROI case obvious – when the problem calls for them.
The Mid-Market Takeaway
The most expensive technology decision a mid-market technology or data leader can make is adopting a platform because the market has consensus around it. The second most expensive is not adopting one when the business actually needs it.
ROI discipline means knowing which situation you’re in – and being willing to defend that answer to your executives, your board, and your team, even when the vendor community is pointing in a different direction.
To be clear, SQL Server in the estate does not automatically disqualify Snowflake, Databricks, or any other modern data platform. There are plenty of legacy SQL Server environments where those platforms are exactly the right next move.
But in many mid-market companies, the presence of mature, structured operational data changes the starting point.
The question is not, “How fast can we migrate?”
The better question is, “What business problem are we solving, and does migration create value we cannot reasonably achieve from the stack we already have?”
Sometimes the sophisticated move is buying the platform.
Other times, it is recognizing that the data stack you already have may be more valuable, and more capable, than the market narrative gives it credit for.
— Scott
