Snowflake where it fits,
and the honest answer where it does not.
We are Microsoft-first — Microsoft Fabric, Power BI and Azure — and we build on Snowflake when your estate requires it: an existing Snowflake investment, a multi-cloud mandate, or a workload where it fits. We read your estate and tell you which platform is the right call, then land your SAP and Dynamics 365 data and report on it in Power BI.
Snowflake Data Cloud
Governed estate · one warehouse
Sources · change data capture
Warehouses
Auto-suspend onRAW_ERP
48 tables
CONFORMED
31 tables
FINANCE
19 tables
REPORTING
12 views
Query compute · sized to workload
Resource monitor caps the monthly spend
Power BI · governed model
One reconciled figureWho this is for
Snowflake consulting built around your role
Snowflake implementation, cost control and migration for data, IT, finance and operations leaders — the question each one owns, answered without vendor spin.
Head of Data / Analytics
The problem
You inherited a Snowflake estate that grew without a plan, and now warehouses, roles and pipelines are undocumented, so every change carries the risk of breaking something nobody can trace.
What we build
A read of the estate, a governed model over your ERP sources, and documented change-data-capture pipelines on Snowflake — with a straight view of which workloads belong on Snowflake and which on Microsoft Fabric.
An estate you can reason about, not just keep running
IT Head / Architect
The problem
You are being asked to standardise the platform, but the Snowflake vendor recommends Snowflake and the Microsoft partner recommends Fabric, and neither will tell you which fits your Microsoft-heavy estate.
What we build
A workload-by-workload map of where Snowflake fits a multi-cloud or data-sharing case and where Microsoft Fabric and OneLake are the lower-friction call — written for the board, not a sales deck.
A platform decision made on evidence, not vendor incentive
CFO / Finance
The problem
The Snowflake consumption bill climbs every month with no breakdown, and you are paying for Power BI and Snowflake compute against the same data without a view of what is driving the spend.
What we build
A cost read that sizes warehouses to the workload, moves heavy reporting off live compute, and sets resource monitors — so consumption becomes a managed number rather than a monthly surprise.
A consumption bill finance can predict and control
Operations Director
The problem
The same stock and order figure differs across the ERP, Snowflake and the planner spreadsheet, so the operations review argues about which number to trust before it can act.
What we build
SAP and Dynamics 365 landed into a conformed model with change-data-capture, reported through Power BI, so orders, inventory and despatch reconcile to one figure across every source.
One reconciled operational number across every system
The Problem
Patterns we see in Snowflake estates
Most Snowflake work that reaches us is not a greenfield build. It is a running estate with a climbing bill, an ownership gap, or a platform decision that no vendor will answer straight.
The Snowflake bill climbs and nobody can explain it.
Warehouses that never auto-suspend, dashboards firing large scans on every refresh, un-clustered tables scanning far more than they return. The monthly consumption line goes up and the finance team has no view of what is driving it.
You inherited a Snowflake estate with no owner.
A previous team or contractor stood it up, then left. Roles, warehouses and pipelines were never documented, and every schema change quietly breaks a downstream job nobody can trace.
SAP and Dynamics data still does not land cleanly.
Getting ERP data into Snowflake is where most integrations stall — full nightly dumps that hammer the source, brittle scripts, and a warehouse that is perpetually a step behind the ERP.
Nobody will tell you Snowflake vs Microsoft Fabric straight.
Your Snowflake vendor sells Snowflake. Your Microsoft partner sells Fabric. For a mid-market industrial operation already on Microsoft 365 and Power BI, the honest answer depends on your estate — and you have not had anyone give it to you.
What we build
What we build
Six pieces of work on a Snowflake estate. Each one starts by reading what you have, and none of them assumes a migration you do not need.
Snowflake estate and cost read
Replaces
The consumption bill that climbs every month with no breakdown of what is driving it.
- A read of warehouse sizing, auto-suspend settings and idle compute
- The queries and dashboards driving the largest scans, ranked
- Resource monitors and budgets so the bill stops surprising finance
- Storage and clustering review to cut scan volume on the heavy tables
Snowflake consumption becomes a managed number, not a monthly surprise.
Where Snowflake fits vs Microsoft Fabric
Replaces
The vendor pitch that only ever recommends the platform the vendor sells.
- An honest map of which workloads belong on Snowflake and which on Microsoft Fabric
- The multi-cloud and data-sharing cases where Snowflake is the right call
- The Microsoft-estate cases where Fabric and OneLake are lower-friction and lower-cost
- A written recommendation you can take to the board — not a sales deck
You make the platform decision on evidence about your estate, not on who is selling.
ERP integration into Snowflake
Replaces
Full nightly dumps and brittle scripts that leave the warehouse a step behind the ERP.
- SAP S/4HANA, SAP ByDesign and Microsoft Dynamics 365 landed with change-data-capture
- Incremental loads via Azure Data Factory, Fivetran or dbt-managed pipelines
- A conformed model so orders, inventory and finance reconcile to one figure
- Monitoring and runbooks so pipelines are owned, not orphaned
ERP data lands current and governed, and your team can support the pipelines.
Power BI reporting on Snowflake
Replaces
Live Power BI queries that fire heavy Snowflake compute on every refresh.
- The right mix of import, DirectQuery and aggregation for each report
- Heavy queries moved off live Snowflake compute where they do not need it
- A governed semantic model so every figure traces back to source
- Refresh and cost tuned together, not one at the expense of the other
Reporting stays fast and the Snowflake compute behind it stays affordable.
Governance and access review
Replaces
Roles, warehouses and grants stood up once and never revisited.
- A review of role hierarchy, warehouse access and grants
- Sensitivity handling and row-level access on the tables that need it
- Lineage from source system through to the Power BI report
- Documentation and a runbook the incoming team can actually use
You know who can see what, and where every number came from.
Migration planning — either direction
Replaces
A rip-and-replace migration proposed before anyone has read the estate.
- A workload-by-workload assessment before any migration is committed
- Snowflake-to-Fabric planning where the Microsoft estate makes the case
- Legacy-warehouse-to-Snowflake planning where a multi-cloud mandate applies
- A phased plan that moves the high-value workloads first, not everything at once
Migration happens only where the estate justifies it, and in the right order.
What works vs what gets sold
Snowflake or Microsoft Fabric — we tell you which
We are Microsoft-first, so the honest position matters. Here is where each platform is the right call for a mid-market industrial operation.
Where Snowflake is the right call
- You already have a Snowflake investment and a team that runs it
- A multi-cloud mandate rules out a single-vendor platform
- Heavy concurrent SQL, or data sharing with external partners
- A cross-cloud footprint where standardising on Azure is not on the table
Where Microsoft Fabric is the better call
- Your estate already runs on Microsoft 365, Azure and Power BI
- You want Direct Lake reporting without paying compute twice
- A mid-market operation that values fewer moving parts over multi-cloud
- OneLake and Fabric consolidate integration, storage and BI in one workspace
For a full side-by-side, see the modern data stack comparison, or read how we build on Microsoft Fabric.
How we work
From estate read to first working output in 6 weeks
We diagnose before we propose. The estate review comes first — because the recommendation to keep, tune or migrate Snowflake has to be earned by what the data shows.
01
Review — read the estate and the bill
Two weeks. Read the current Snowflake usage, warehouse sizing and consumption pattern. Map where Snowflake fits your estate and where Microsoft Fabric is the better call. You leave with a straight recommendation, not a pitch.
02
Prototype — first working output
Two weeks. Build the priority workload — a governed reporting model on Snowflake, a change-data-capture pipeline from your ERP, or a cost-tuning pass — and validate it against real data before it goes wider.
03
Deploy — govern and hand over
Three to five weeks. Extend across sources, wire governance and resource monitors, and hand over documented, monitored pipelines with runbooks so your team owns what we built.
Why MyData Insights
Why choose MDI for Snowflake consulting
Microsoft-first, honest about Snowflake
We build primarily on Microsoft Fabric, Power BI and Azure, and we build on Snowflake where the estate requires it — an existing investment, a multi-cloud mandate, or a workload that fits. We are not a single-platform reseller, so the recommendation follows your estate.
We tell you where Fabric is the better call
For a mid-market industrial operation already on Microsoft 365 and Power BI, Fabric and OneLake are often lower-friction and lower-cost. We name where that is true and where Snowflake is the right choice — before anyone commits to a migration.
Consumption cost is a first-order concern
We size warehouses to the workload, set resource monitors, and move heavy reporting off live compute, so the Snowflake bill stays a number the CFO can predict rather than one that climbs unexplained.
ERP integration is our core work
Production experience landing SAP S/4HANA, SAP ByDesign and Microsoft Dynamics 365 with change-data-capture, so the source stays light and the model stays current — not a generic connector demo adapted after the fact.
Power BI reporting done properly
We tune the reporting layer and the Snowflake compute behind it together, choosing import, DirectQuery or aggregation per report so dashboards stay fast without firing large scans on every refresh.
First working output in six weeks
A governed model, a change-data-capture pipeline, or a cost-tuning pass live in six weeks on a fixed scope — not a discovery deck to review.
Technology stack
Data Cloud
Microsoft Estate
Integration
ERP & Source
Modelling
Reporting
Common questions
What buyers ask us
We already run Snowflake. Should we move to Microsoft Fabric?
Not by default. If Snowflake is working, your team knows it, and the cost is under control, we leave it running and build reporting on top. We recommend a move to Microsoft Fabric only where the estate is Microsoft-heavy, the Power BI bill and the Snowflake compute bill are being paid twice for the same data, or a specific workload fits Fabric better. We tell you which case you are in before anyone signs off on a migration.
When is Snowflake the right call over Microsoft Fabric?
When you already have a Snowflake investment and a team that runs it, when a multi-cloud mandate rules out a single-vendor platform, or when a specific workload — heavy concurrent SQL, data sharing with external partners, a cross-cloud footprint — fits Snowflake better. For a mid-market industrial operation already on Microsoft 365, Azure and Power BI, Microsoft Fabric is usually the lower-friction and lower-cost call. We name which of these applies to your estate.
Our Snowflake bill keeps climbing. Can you bring it down?
Usually, yes. Most consumption creep comes from oversized warehouses that never auto-suspend, dashboards firing large scans on every refresh, and un-clustered tables scanning far more than they return. We read your usage, size warehouses to the workload, move heavy Power BI queries onto import or aggregation where they do not need live Snowflake compute, and set resource monitors so the bill stops surprising the CFO.
Can you get SAP and Dynamics data into Snowflake?
Yes. We land SAP S/4HANA, SAP ByDesign and Microsoft Dynamics 365 into Snowflake using Azure Data Factory, Fivetran or dbt-managed pipelines, with change-data-capture so the source stays light and the load is incremental, not a nightly full dump. The same conformed model then reports through Power BI, so operations, finance and planning read one reconciled number.
How much does a Snowflake engagement cost and how long does it take?
We work in fixed-scope, fixed-fee phases, never open-ended time and materials. The fee is quoted after a short estate review, once we have seen your Snowflake usage, your source systems and how reporting is built, because those are what move the number. What we commit to upfront is the cadence — first working output in 6 weeks, not a 50-slide roadmap. Snowflake consumption costs are yours and stay on your account; our fee is the delivery.
Engagement
Free Snowflake Estate Review
Thirty minutes with Amit on your actual Snowflake estate: what the consumption bill is doing, where Snowflake fits and where Microsoft Fabric would serve you better, and how your SAP and Dynamics 365 data reports through Power BI. No slides, no obligation.
What you get
- A read of your current Snowflake usage and consumption cost
- Where Snowflake fits your estate and where Microsoft Fabric is the better call
- A governance and Power BI reporting check on what you have
- A change-data-capture plan for your priority ERP source
- A 6-week first-value plan you keep
Ready to move
Tell us what your Snowflake estate is doing
30 minutes with Amit. No slides. No pitch deck. No obligation to proceed. We read your usage and the bill, and tell you straight whether to keep, tune or move — and where Microsoft Fabric would serve you better.