SSRS to Power BI migration services
A Microsoft-to-Microsoft move, not a rip-and-replace: senior US-based engineers republish your RDL files as pixel-perfect paginated reports, refactor stored-procedure report logic into a star-schema model with DAX measures, rebuild data-driven subscriptions in Power Automate, and remap folder security to row-level security — so the report server can be switched off on a date instead of a hunch. One written price, typical delivery in 2–4 weeks, 30 days of hypercare included.
Representative dashboard — sample data
What you get
Reports are the visible part. Subscriptions, folder permissions, and the stored procedures underneath them are what actually keep people from letting go of the old server.
Your invoices, statements, and compliance packs keep their exact layout. Each definition is opened, tested, and published to a Power BI workspace, with the ones that rely on retired features flagged before anything moves.
Report logic buried in T-SQL becomes a star-schema semantic model with DAX measures defined once and reused, so two reports asking the same question stop returning two different answers.
The nightly run that mails a different regional PDF to forty managers is re-expressed as a flow: recipient list from your data, export per recipient, delivery to email or SharePoint, with failures visible instead of silent.
Permissions that lived on report server folders are re-expressed as workspace roles, app audiences, and row-level security in the model — then tested with real accounts, not assumed to have carried across.
Your SQL Server instances and warehouses stay put. We connect through a data gateway rather than moving databases, so the old server and the new workspace can run side by side while reports are checked.
A written inventory of what moved, what was deliberately retired, what still points at the report server, and what its databases and licensing cost you — so shutting it down becomes a scheduled task.
How it works
A free consultation plus a look at the report server's execution log tells us what is opened, what is subscribed to, and what nobody has run in two years. You get a written scope, one fixed price, and a delivery date.
Paginated reports republish first. Analytical reports are rebuilt on a semantic model, subscriptions become flows, and security is remapped — each batch checked against the live report server output before sign-off.
Users move to the new workspace with access rules applied and a walkthrough of what changed. Once the outstanding list is empty, you get the decommission plan and 30 days of hypercare.
Leaving Reporting Services is a different job from leaving a competitor's BI tool. Nothing is being torn out and replaced: the report definition format follows you. Microsoft's own guidance for migrating .rdl reports to Power BI (opens in new tab) is explicit that an RDL report simply becomes a paginated report once it lands, that instances from SQL Server Reporting Services 2012 through 2022 are covered, and that you can complete the move without downtime because the old environment stays in place until you are ready to retire it. That is the shape of this engagement.
It also means the honest scope is narrower than a vendor migration and deeper in one specific place. Layout survives; the awkward part is everything the report server did around the reports — subscriptions, folder permissions, shared datasets, and the stored procedures that quietly became your business logic. If you are moving off a competing platform instead, our Tableau to Power BI migration service covers that rip-and-replace case, where the visuals cannot travel and the semantic model has to be reconstructed from scratch first. And if the legacy platform is SAP Crystal Reports rather than Reporting Services, our Crystal Reports to Power BI migration service is the page you want: nothing about a .rpt file travels, Crystal's formula language has to be re-derived into DAX, and subreports — which Reporting Services does not share — have no equivalent object waiting for them. If it is QlikView, our QlikView to Power BI migration service covers the case where the load script, the data model and the sheets all live inside one .qvw file and the associative engine has to be re-expressed as explicit relationships. And if the platform you are leaving is IBM Cognos, our Cognos to Power BI migration service starts a step earlier again: a Framework Manager package already holds the modeling layer, so it has to be read as a specification and re-expressed before any Report Studio output can be rebuilt.
The first real decision is sorting the catalog in two. Operational documents — invoices, statements, packing lists, regulatory filings, anything designed to print or export to PDF at a fixed size — stay paginated. They move nearly intact, and turning them into dashboards would destroy the thing that makes them useful.
Everything people actually explore is a different case. Those reports usually run on a stored procedure that encodes the business rules, filters, and totals in T-SQL, which means the logic is invisible to the report and impossible to reuse. We re-derive those rules into a semantic model built on star schema principles (opens in new tab), with fact and dimension tables and DAX measures written once. It is slower than republishing an RDL file and it is where the value of the project sits: it is the moment a definition of "net revenue" that three procedures disagreed about finally gets settled. If you want new reporting built on that model afterwards rather than migrated onto it, that is our fixed-fee Power BI dashboard development service.
Most report server estates decompose into the same eight pieces. The table below is the mapping we work from, and the inventory in your scope is a filled-in version of it.
| On the report server | Where it lands in Power BI | What the work involves |
|---|---|---|
| Pixel-perfect RDL report | Paginated report in a Power BI workspace | Opened in Power BI Report Builder, embedded datasets verified, published and rendered-tested against the original PDF output |
| Analytical report people slice and filter | Power BI report on a shared semantic model | Rebuilt rather than republished, so filters, drill-through, and totals come from the model instead of report-level SQL |
| Shared data sources and shared datasets | Embedded datasets or a governed semantic model | Shared items do not migrate as shared; each is embedded or, better, consolidated into one model several reports connect to |
| Stored procedures carrying report logic | Star-schema tables plus DAX measures | Business rules re-derived from the procedure, agreed with the report owner, and expressed as reusable measures |
| Standard subscription (same file, fixed list) | Power BI report subscription | Recreated as a scheduled subscription, with the delivery time and recipient list checked against the old schedule |
| Data-driven subscription (recipient list from a query) | Power Automate flow | Flow reads the recipient query, calls the Power BI export action per recipient, and delivers to email or SharePoint with run history you can audit |
| Folder-level roles and permissions | Workspace roles, app audiences, row-level security | Each folder rule mapped to its Power BI equivalent, then tested per role; reports relying on the UserID field are revised for UPN format |
| The report server and its databases | Nothing — this is what you switch off | Written decommission plan: outstanding dependencies, database and licensing footprint, and a shutdown date you choose |
Two things reliably keep an old report server alive long after the reports have moved. The first is the data-driven subscription: one schedule that queries a recipient list, renders a personalized copy per row, and mails each one out. Power BI's built-in subscriptions do not work that way, so we rebuild the pattern in Power Automate using the documented export-and-email flow actions (opens in new tab). The result is a flow with visible run history, which is already an improvement on a subscription that fails quietly at 3am. If distribution is a bigger theme for you than reporting, our Power Automate consulting service covers the wider set of scheduled and approval flows.
The second is security. Report server permissions hang off folders (opens in new tab): put a report in the Finance folder and the Finance group can see it. Power BI has no equivalent, because it secures the data in the model rather than the file in a tree. Every folder rule therefore has to be re-expressed as some combination of workspace role, app audience, and row-level security, and each one is tested with a real account before the corresponding folder is retired. Reports that identified users through the built-in UserID field need attention too — in the service it returns a user principal name rather than a domain account, so the underlying dataset logic gets revised and retested.
It fits organizations that already run Microsoft 365 and are maintaining a report server for reasons nobody can fully articulate: a Windows box someone has to patch, a SQL Server license attached to it, a scheduled job estate no one wants to touch, and a set of reports that still matter. Reporting Services is not being taken away from you — it is still shipped and supported — so this is a consolidation decision, made because running two reporting platforms costs more attention than it is worth.
It is scoped for small and mid-size organizations: one fixed-fee project with a stated end date, not a multi-quarter program. If you want the reasoning behind fixed fees before you talk to anyone, our breakdown of what a Power BI dashboard actually costs explains how scope drives the number, and how our fixed-fee process works covers scoping, delivery, and what happens after handover. Licensing usually comes up early too — publishing content to a workspace needs a Power BI license per author, and the small-business licensing guide sets out the options without the jargon.
The table shows scope and typical timeline rather than prices, because an honest number requires seeing your report inventory and subscription list first.
| Phase | Scope | Typical timeline | Fee |
|---|---|---|---|
| Phase 1 — inventory and paginated reports | Execution-log review to find live and dead reports, gateway and workspace setup, and the pixel-perfect RDL set republished as paginated reports and render-tested | About the first week | Fixed fee — scoped after your free consultation |
| Phase 2 — model, analytical reports, security | Stored-procedure logic refactored into a star-schema semantic model with DAX measures, analytical reports rebuilt on it, and folder permissions remapped to workspace roles and row-level security | Weeks 2–3 | Fixed fee — scoped after your free consultation |
| Phase 3 — subscriptions and decommission | Standard subscriptions recreated, data-driven subscriptions rebuilt as Power Automate flows and run in parallel, plus the written decommission plan for the report server and its databases | Week 4 and close-out | Fixed fee — scoped after your free consultation |
Everything produced is yours from the first day: the report files, the semantic model, every measure, the flows, and the workspace configuration all live in your own Microsoft tenant, never in ours.
Related services
Fixed-fee development for the reports you want built new, once your estate has landed on Power BI.
Scheduled distribution, approvals, and integrations — including the flows that replace report server subscriptions.
Migration and cost optimization for the SQL Server and data platform sitting underneath your reporting layer.
Pro vs Premium Per User vs Fabric, explained for small business budgets.
The symptoms that show manual reporting is now costing more than it saves.
What to ask, what to check, and the answers that should make you walk away.
FAQ
In Power BI, an RDL report is called a paginated report, so most files open in Power BI Report Builder and republish with their pixel-perfect layout intact. We test each one, fix what the service rejects — custom code assemblies, unsupported data sources, shared resources — and agree with you which reports deserve a rebuild instead.
No. Operational documents such as invoices, statements, and compliance packs stay paginated, because they are built to print and export cleanly. Reports people actually explore become modeled Power BI reports. We sort your catalog into those two groups first, since rebuilding a 40-page statement as a dashboard helps nobody.
Power BI has scheduled subscriptions, but nothing that matches an SSRS data-driven subscription row for row. We rebuild that distribution logic in Power Automate: a flow reads the recipient list from your data, exports the report per recipient using the Power BI export actions, and delivers it by email or to SharePoint.
Folder-level roles do not carry across, because Power BI secures data inside the semantic model rather than reports inside a folder tree. We map each folder rule onto workspace roles, app audiences, and row-level security, then test every role with real accounts before anyone loses access they still need.
That is the point of the project. We track every report, subscription, and downstream dependency until the outstanding list is empty, then hand over a written decommission plan covering the server, its databases, and the licensing attached to it. You choose the shutdown date; nothing is switched off silently.
Typical delivery is two to four weeks from kickoff, with dates stated in your written scope. The fee is fixed and reflects how many reports move, how much stored-procedure logic needs remodeling, and how many subscriptions have to be rebuilt in Power Automate. Nothing starts until you approve the scope.
Book a free consultation
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.