Fabric Data Factory Pricing - On Premises SQL Server to Lakehouse Real Numbers

Most Australian businesses I work with still have at least one core system running SQL Server on a box in a server room. Sometimes that box is a clustered pair in a Sydney data centre. Sometimes it is a single VM running a 12-year-old line of business app that nobody wants to touch. Either way, when these businesses come to us at Team 400 asking about Microsoft Fabric, the first technical question is almost always the same. How much will it cost to move this data into the Lakehouse and keep it in sync?

Microsoft published a pricing example for exactly this scenario. It's worth reading the original Microsoft Fabric Data Factory pricing example for the raw numbers, but the calculation alone doesn't tell you what's going to land on the invoice at the end of the month. That's what I want to unpack here.

The Scenario That Mirrors Most Australian Migrations

The example Microsoft walks through is a 500 GB on-premises SQL Server database being copied into a Fabric Lakehouse table. They use a Copy job with the on-premises data gateway, do a full initial load, and then daily incremental loads of around 5 GB.

If you're looking at moving an ERP, a finance system, an HR database, or a legacy operational data store, this is the pattern. 500 GB is small for a large enterprise but it's representative of the bulk of mid-market Australian companies I see. A typical ServiceNow instance, an NAV or Business Central database, a Dynamics GP install, a custom .NET app sitting on SQL Server. All of these tend to fall in the 100 GB to 2 TB range.

The thing that throws most teams is that the on-premises data gateway itself doesn't cost anything. There's no per-node or per-VM charge for installing the gateway on your own infrastructure. All the billing happens through Fabric capacity consumption against the Data Factory workload meters. That sounds obvious but it changes how you think about sizing.

The Two Meters You Need to Understand

A Copy job hits two billing meters depending on what it's doing.

The first is Data Movement. This is what gets consumed during a full load. Each unit of intelligent throughput optimisation consumes 1.5 CU hours per actual hour the job runs. In the Microsoft example, the full 500 GB copy ran with throughput optimisation set to 128 and took about 9 minutes. The maths works out to roughly 28.8 CU hours for the initial load.

The second is Data Movement - Incremental copy. This kicks in for delta runs. Each unit of throughput optimisation here consumes 3 CU hours per actual hour. So the rate is double the full copy rate, but you're running much shorter jobs over much less data. The example incremental run pulled 5 GB in about 1 minute at throughput optimisation 4, costing 0.2 CU hours.

If you add it up over the first day of running, you get 29 CU hours total. At Microsoft's hypothetical $0.18 per CU hour, that works out to $5.22. The number is small because most of the cost is the one-time initial load, and incremental runs are cheap.

But here is where you need to be careful. That $0.18 figure is hypothetical and global. Australian pricing on F-SKUs differs and the actual cost depends on what capacity tier you're sitting on. We typically see Australian enterprises buying F-series capacity that prices closer to $0.20 to $0.24 per CU hour when you factor in the regional uplift and any commitment tier discount.

So a more realistic Australian estimate for the same job is roughly $5.80 to $7.00 for the first day, then a daily incremental cost of about $0.04 to $0.05 per day. Over a year you'd spend maybe $15 to $20 on the incremental loads themselves. The capacity you bought to run those loads, however, is a much bigger number.

Why the Capacity Choice Matters More Than the Job Cost

This is the bit that catches teams out. The CU hours consumed by your Copy job are pulled from the Fabric capacity you've already purchased. If you've bought an F2 capacity (the smallest production-grade SKU), you have a fixed amount of CU available. The Copy job is sharing that capacity with every other Data Factory pipeline, every Power BI report query, every notebook run, every SQL endpoint hit.

The actual question isn't "what does this Copy job cost". It's "do I have enough headroom on my Fabric capacity for this Copy job plus everything else?"

We had a client in Brisbane running their core financial reporting on an F4 capacity. They added a 200 GB nightly extract from an on-premises Dynamics database. The Copy job itself was fast and cheap. But it ran at 2am, which was the same window their finance team had scheduled a heavy semantic model refresh and a couple of Spark notebooks doing reconciliation work. The capacity went into throttle for about 45 minutes. Nothing failed, but their CFO got an email at 7am saying the dashboards weren't updated yet.

The fix wasn't more spend on the data movement. It was rearranging the schedule and bumping the capacity for two hours overnight using autoscale. The lesson is that you need to plan for the peak combined consumption, not the sum of average jobs.

What the Pricing Example Doesn't Tell You

There are a few things the Microsoft pricing example glosses over that matter in practice.

Network throughput from your data centre to Azure is the real bottleneck most of the time, not the capacity. If you're running an Express Route from a Sydney or Melbourne facility, you'll see throughput numbers close to what Microsoft quotes. If you're running over a standard internet connection from a regional office, that 9 minute full load can easily become 90 minutes. The Copy job will still bill at the per-CU rate, but the wall-clock time changes and you may need a bigger throughput optimisation setting to avoid timeouts, which then costs more per minute.

Gateway sizing matters for performance, not for billing. Microsoft is explicit that the gateway itself is free. But if you stick it on a tiny 2 vCPU box because it's free, you'll bottleneck the whole pipeline. We recommend at least 4 vCPU and 16 GB of memory for any production gateway moving more than 50 GB at a time. If you're moving hundreds of gigabytes, go to 8 vCPU and 32 GB. The cost of the underlying VM is real and not part of the Fabric bill.

Authentication setup can stall a project for a week or two. SQL Server authentication from a gateway needs either SQL auth credentials, Windows auth with a service account, or a managed identity setup that often doesn't work cleanly on older SQL Server versions. We've seen teams underestimate this and find themselves stuck waiting for AD changes for longer than the actual development work took.

Putting Together a Realistic First-Year Budget

If you're estimating a first-year cost for a single on-premises SQL Server to Lakehouse migration of this size in Australia, here's the rough shape:

The Copy job itself, at the volumes in the Microsoft example with daily incrementals, comes to roughly $20 to $40 for the year in capacity consumption.

The Fabric capacity you need to run it, sized appropriately for an organisation with maybe 50 to 100 report consumers, runs $1,000 to $4,000 per month depending on SKU. So $12,000 to $48,000 yearly for capacity.

The gateway VM, if you're running it on Azure or your own infrastructure, is a few thousand dollars yearly at most.

The implementation work, which is where most of the real cost sits, runs $25,000 to $80,000 for a clean single-source migration of this kind. We've covered the broader cost picture in our Microsoft Fabric consultants page if you want a deeper look at engagement scopes.

So the headline pricing example showing a few dollars per day for data movement is technically accurate. But the bill that actually shows up combines capacity, implementation, gateway infrastructure, and the operational changes around running these jobs. Plan for all of it, not just the meter.

When This Pattern Is the Right Choice

The on-premises gateway plus Copy job pattern works well when you have a stable on-premises SQL Server, you need the data in the Lakehouse for analytics, and you're happy with batch loads rather than real-time. It's the most common Fabric onboarding pattern we see across Australian mid-market and we've used it successfully for clients across financial services, manufacturing, and professional services.

It's not the right choice if you need sub-minute latency (look at change data capture or event-based options), if you're hitting tens of terabytes per load (look at Azure Data Box for the initial seed), or if your SQL Server is on a network that can't reliably maintain throughput to Azure (you'll need to fix the network first).

For most teams sitting on a 500 GB to 2 TB SQL Server database wanting Fabric Lakehouse storage and Power BI on top, this is the pattern, and the costs are manageable once you size the capacity properly. If you'd like a hand sizing this for your specific situation, our Microsoft Data Factory consultants team can usually scope it in a single workshop.

The pricing meters are public and the maths is straightforward. What takes experience is knowing how the meters interact with the rest of your Fabric workload and how to avoid the unhappy surprises in month two.

For the full Microsoft documentation on this pricing scenario, see the original article on Microsoft Learn.