If your company's reports still run on SQL Server, 2027 forces a decision. SQL Server 2017 leaves support in October 2027, SQL Server 2016 already did in July 2026, and Microsoft has stopped building new versions of SSRS. You will spend money on your reporting platform either way. Moving SQL Server reporting to Snowflake is, for most mid-sized companies, the upgrade that pays back instead of just buying more time.
I have built and maintained SQL Server reporting for most of my 18 years in IT, and I like the product. This isn't a "SQL Server is dead" post. Your transactional systems can stay exactly where they are. The argument is narrower: the reporting workload, the nightly ETL, the warehouse tables and the dashboards on top, is the part that has outgrown a single server, and 2027 is the cheapest moment to move it.
Key takeaways
- The clock is real. SQL Server 2016 extended support ended on 14 July 2026. SQL Server 2017 ends on 12 October 2027. After that, security fixes cost extra or stop.
- SSRS is frozen. Microsoft is not releasing a new SSRS for SQL Server 2025. Power BI Report Server is now the default on-premises reporting product.
- Move reporting, not everything. Keep your OLTP databases on SQL Server. Move the analytical copy, the ETL and the reports.
- You pay for reporting only while it runs. Snowflake bills compute per second and charges nothing while a warehouse is suspended, which suits reporting's bursty usage.
- The migration tooling is free. Snowflake's SnowConvert converts SQL Server schemas and T-SQL code and migrates and validates the data.
The 2027 deadline: what actually ends
Microsoft's lifecycle pages leave little room for interpretation:
| Version | Extended support ends | After that |
|---|---|---|
| SQL Server 2016 | 14 July 2026 (already over) | Paid Extended Security Updates until July 2029 |
| SQL Server 2017 | 12 October 2027 | No Extended Security Updates schedule published |
| SQL Server 2019 | January 2030 |
Sources: SQL Server 2016 lifecycle, SQL Server 2017 lifecycle.
Plenty of reporting servers were installed in the 2016–2018 era and never touched again, because they "just work". Those are exactly the machines this deadline hits. Every option in front of you costs money and project time: an in-place upgrade, a new server, extended security updates, or a migration. When you have to spend the effort anyway, the question becomes which destination gives you something back.
SSRS has no new version, so the stack is changing anyway
The second push comes from Microsoft itself. In June 2025 the SQL Server team wrote that "Power BI Report Server will now be the default reporting solution for SQL Server 2025" and that "we will not be releasing a new version of SSRS for SQL Server 2025". Existing SSRS installations stay supported, and any customer with a paid SQL Server licence now gets access to Power BI Report Server.
That is a sensible move by Microsoft, but notice what it means for you. Even if you stay 100% on-premises, your reporting front end is changing from SSRS to Power BI. Your report authors will learn Power BI either way. Once that is true, the database behind the reports is a free choice, and Power BI connects to Snowflake as easily as to SQL Server.
Why reporting is the workload to move
SQL Server is excellent at what it was designed for: many small, fast transactions. Reporting asks something different. It runs large scans and aggregations, it peaks at month-end and Monday morning, and it sits idle most of the night. On a single SQL Server box that creates three familiar problems:
- Contention. Heavy reports compete with the application or the ETL for the same CPU, memory and I/O. You either throttle the reports or buy a bigger server.
- Sizing for the peak. You license and pay for the cores you need on the busiest day of the quarter, every day of the year.
- Copies everywhere. To protect production, teams build a reporting replica, then a data mart, then exports to Excel. Every copy is another job to maintain and another version of the truth.
Snowflake separates storage from compute. The data lives once, and each group (finance, operations, the dashboards) gets its own virtual warehouse that you start, resize or stop independently. A heavy month-end close no longer slows the sales dashboard, because they don't share hardware.
What Snowflake changes in cost and risk
The billing model is the part decision makers should look at first. According to Snowflake's documentation:
- Compute is billed per second, with a one-minute minimum each time a warehouse starts or resumes.
- A suspended warehouse uses no credits. Reports that run for 20 minutes a day cost 20 minutes a day, not a server that runs all month.
- Each warehouse size up roughly doubles both power and price (for example Small uses 2 credits per hour, Medium 4), so you can make a slow month-end job faster for exactly the hours it runs.
For reporting, which is bursty by nature, that model usually beats paying for a server sized for the peak. It also changes the risk picture: no operating system to patch, no SQL Server version to fall out of support, and no hardware refresh in four years.
The honest caveat: Snowflake can get expensive if nobody watches it. A warehouse left running, or a dashboard refreshing every minute, burns credits around the clock. Set auto-suspend on every warehouse, put resource monitors with budgets in place from day one, and review the top queries monthly. That is a governance job, not a technology problem, but someone has to own it.
Moving SQL Server reporting to Snowflake in practice
A reporting migration is far smaller than a full database migration, because the source systems stay where they are. In my experience it follows four steps:
- Inventory. List the reports, who actually opens them and which tables they touch. Most estates have a long tail of reports nobody has opened in a year. Don't migrate those.
- Convert the warehouse and the code. Snowflake's free SnowConvert tool supports SQL Server as a source and covers schema and T-SQL conversion, data migration and validation in one workflow. Expect to hand-fix the trickiest stored procedures. Automation handles the bulk, not everything.
- Move the data pipelines. Replace the nightly SSIS packages or scheduled jobs that fill the warehouse with loads into Snowflake. Many teams use this step to switch from full nightly reloads to incremental loads.
- Repoint the reports. Power BI's Snowflake connector supports both Import and DirectQuery. Run old and new reports side by side for a full month-end close, compare the numbers, and only then switch users over.
The parallel run is the step teams are tempted to skip, and the one that saves the project. Finance will forgive a late migration. They won't forgive a revenue figure that changed by 2% overnight.
When you should not move to Snowflake
"Most companies" is not "all companies". Stay on SQL Server, or upgrade to SQL Server 2025 with Power BI Report Server, if:
- Your reporting data is small (a few gigabytes) and the server isn't under pressure. A modern SQL Server handles that comfortably, and a migration project costs more than it saves.
- Your data must stay on-premises for regulatory or contractual reasons, and no cloud region meets those requirements.
- Your reports are mostly pixel-perfect paginated documents (invoices, statutory forms) with little analysis behind them. Power BI Report Server is the natural successor for those.
- Nobody will own cloud cost governance. Without that owner, the per-second advantage turns into a surprise bill.
If none of these apply, and your reporting server is a 2016 or 2017 install, you are in the group this article is about.
A realistic timeline for 2027
October 2027 sounds far away. For a reporting migration that includes a month-end parallel run, it isn't. A workable plan:
- Q4 2026: inventory reports and data sources, choose the target, run a proof of concept with your two heaviest reports.
- Q1 2027: convert the warehouse schema and code, build the new data loads.
- Q2 2027: repoint the reports, parallel run through a quarter-end close.
- Q3 2027: switch users over and keep the old server read-only as a fallback until support ends in October.
Starting now leaves room for one surprise. Starting in summer 2027 leaves room for none.
If you are weighing the same kind of platform decision on the application side, my comparison of .NET 11 vs .NET 10 covers the support timelines there. More articles are on the blog.
Frequently asked questions
When does SQL Server 2017 support end?
SQL Server 2017 extended support ends on 12 October 2027, according to Microsoft's lifecycle page. Mainstream support already ended in October 2022, and Microsoft has not published an Extended Security Updates schedule for this version. After that date, the database keeps running, but newly discovered security vulnerabilities are no longer patched, which is a compliance and audit risk for most companies.
Is SSRS being discontinued?
Not immediately. Microsoft is not releasing a new SSRS version with SQL Server 2025, and Power BI Report Server is now the default on-premises reporting product. Existing SSRS installations remain supported for SQL Server 2025 and all in-market versions. In practice SSRS is frozen: it gets support but no new features, so new reporting work should target Power BI.
Do I have to move my whole SQL Server to Snowflake?
No. The strongest case is for the reporting workload only: the data warehouse, the ETL that fills it and the reports on top. Your transactional application databases can stay on SQL Server. Data is copied or streamed from them into Snowflake, which keeps heavy reports from slowing down the applications your business runs on.
Can Power BI report on Snowflake data?
Yes. Power BI has a built-in Snowflake connector that supports Import mode, where data is loaded into Power BI's in-memory model on a refresh schedule, and DirectQuery, where every visual queries Snowflake live. Single sign-on with Microsoft Entra ID works with DirectQuery. Most teams use Import for speed and DirectQuery for very large or frequently changing tables.
Is Snowflake more expensive than SQL Server?
It depends on how you use it. Snowflake bills compute per second and nothing while a warehouse is suspended, so bursty reporting often costs less than a server licensed for peak load. Costs rise when warehouses run idle or dashboards refresh constantly. Auto-suspend, resource monitors and a named cost owner keep the bill predictable.
