SSRS to .NET Core: Your 3 Migration Options Compared

The ReportViewer Problem

The Microsoft ReportViewer control has fundamental limitations that block modern .NET adoption:

Microsoft's direction is stated: no new version of SSRS after 2022, and Power BI Report Server as the on-premises report server from SQL Server 2025. Both are report servers that run on Windows and query the data themselves; neither is a library that renders an .rdlc from your application's own data.

The simplest option is to change nothing. This only makes sense if your reports aren't business-critical, you have no plans to move to modern .NET, and your application has a defined end-of-life.

The upside is zero migration effort. The downside is accumulating technical debt, no path to Linux containers, and the end of SSRS 2022's support in January 2033.

Microsoft's cloud path uses the same RDL format: an .rdlc becomes an .rdl whose datasets query sources Power BI can reach. This makes sense if you're already invested in the Microsoft 365/Azure ecosystem, have a small number of report consumers, and running reports in Microsoft's cloud is acceptable.

Pricing Model

Paginated reports are part of Power BI Pro, at USD 14 per user per month (USD 168 a year, Microsoft's price on 1 October 2026). Everyone who shares or views a report needs a licence, unless the workspace runs on a Microsoft Fabric capacity (F64 or higher), which is priced by capacity.

The third option is replacing ReportViewer with a cross-platform .NET library that renders RDLC reports natively on any platform. This makes sense when you need Linux, Docker, or Kubernetes support, you're migrating to .NET 10 (or to .NET 8 or 9), data must stay within your infrastructure, and you want predictable non-per-user pricing.

The Hidden Cost: Most Libraries Convert Your Reports

Most third-party reporting libraries (FastReport, Stimulsoft, DevExpress, Telerik) have their own report formats. Some import RDLC, but a conversion is not a migration. FastReport's guide says scripts, formulas and expressions are not converted and that "full conversion is impossible"; DevExpress's importer does not convert charts, subreports or lists; Telerik has no RDLC importer. For an organization with 50+ RDLC files built over years, that's weeks or months of rework — and the risk of introducing bugs in battle-tested reports.

Evaluation Checklist

Self-Hosted Options Compared

A Migration Plan

An example plan for a mid-market company with 80 RDLC reports built over years, migrating from Windows Server / .NET Framework 4.8 to Kubernetes:

Key Validation Steps

• Report inventory — Document all reports, their complexity, and usage frequency
• Compatibility testing — Render each report and compare output to existing ReportViewer output
• Performance benchmarking — Measure render times for high-volume reports
• Export validation — Verify PDF, Excel, and Word exports match expected output
• Integration testing — Test parameter passing, data source binding, and subreports

Common Issues to Check

• Fonts — SSRS2 bundles the widths of Arial, Times New Roman, Courier New, Calibri, Segoe UI, Cambria, Tahoma, Verdana, Trebuchet MS, Georgia, Consolas, Aptos and Aptos Narrow; register other fonts' files with ReportFonts.AddFontFile
• Image paths — May need adjustment for new file system
• Expression compatibility — Test complex expressions thoroughly
• Subreport references — Verify paths resolve correctly

5-Year Cost Comparison

For a company with 75 report users:

SSRS2 Licensing

One licence per company, USD 799 a year, with every feature included — every export format, every chart type, every supported platform. No per-user seats, no per-report metering and no phone-home: the licence key is validated offline, and it keeps working forever with every version released while the licence runs.

Evaluate the whole engine first: install the package and run your own RDLC files; output carries a trial watermark until a key is in place. Buy online and the key arrives by email within a minute.

Quick Start: 5 Lines of Code

using SSRS2.Reporting.NETCore;

var report = new LocalReport();
report.ReportPath = "Invoice.rdlc";
report.DataSources.Add(new ReportDataSource("InvoiceData", invoiceList));
byte[] pdf = report.Render("PDF");
File.WriteAllBytes("invoice.pdf", pdf);
// Works on Linux, macOS, Windows, Docker — same code everywhere

Install: dotnet add package SSRS2.NETCore

Docker Deployment

FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS base
RUN apt-get update && apt-get install -y --no-install-recommends libfontconfig1 && rm -rf /var/lib/apt/lists/*

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
COPY . /src
RUN dotnet publish /src -c Release -o /app

FROM base
COPY --from=build /app .
ENTRYPOINT ["dotnet", "MyReportApp.dll"]
# RDLC reports render natively on Linux — no GDI+, no libgdiplus

Frequently Asked Questions

Conclusion

SSRS and the ReportViewer control served the .NET ecosystem well for two decades. But the platform has moved on. You have three paths forward:

1. Stay on SSRS — Acceptable for legacy applications with a defined sunset
2. Power BI Paginated Reports — Works if you're small, cloud-first, and Microsoft-committed
3. Self-hosted library — The practical choice for modern .NET applications at scale

The good news: you don't have to rewrite your reports. Your RDLC files are portable. The right migration tool lets you keep your existing reports and run them anywhere.