Every report, with its execution history
The report server already knows which items are run, by whom, and how often. We use that log to separate the reports the business depends on from the ones that have quietly run to nobody for three years.
Leaving Reporting Services
An SSRS to Power BI migration built around the RDL reports people still run
We inventory the report server, price each report in hours before it is built, then rebuild it where it belongs — paginated in Power BI Report Builder, or interactive in Power BI Desktop — with shared datasets, subscriptions, and gateway connections handled properly.
Representative dashboard — sample data
Why teams move
The report server outlived the people who configured it
Most Reporting Services estates are not broken. They are unowned. Someone built a folder structure years ago, subscriptions fire at 6am into inboxes and file shares, the datasets point at a database nobody wants to touch, and the one person who knew how the security worked has moved on. Then the server the whole thing runs on comes up for renewal, or a Fabric licence lands, and the question turns from "should we?" into "how, and what does it cost per report?"
The good news is that this is the friendliest legacy migration there is: Power BI paginated reports are built on the same RDL technology, so a report definition is a genuinely portable artefact rather than a proprietary black box. The work that costs money is everything around the file — the shared datasets, the delivery, the permissions, and the honest triage of what should not be rebuilt at all.
What the migration covers
- RDL inventory & usage
- Report Builder vs Desktop calls
- Shared datasets embedded
- Data sources & gateway
- Subscriptions rebuilt
- Workspaces & permissions
- Expression fixes
- Parallel run & cutover
Try us risk-free for 4 hours
Start with a block of prepaid Flex hours and, if you're unhappy within the first 4 hours, we refund you in full — no questions asked. The report inventory is the natural first task: it turns a folder tree nobody has audited in years into a costed list you can approve line by line.
How we approach it
Triage first, tooling second, delivery last
Publishing an RDL file into a workspace takes seconds. Deciding which reports deserve that treatment, and what replaces the plumbing around them, is the actual project.
Report Builder or Desktop, per report
Fixed-layout output stays RDL and is authored in Power BI Report Builder. Reports people slice, filter, and argue about are rebuilt in Power BI Desktop on a shared model. The call is made and recorded report by report.
Shared datasets have to land somewhere
The service does not take SSRS shared datasets or shared data sources, so they become embedded definitions. Where a dataset was genuinely shared, we replace that reuse with a semantic model instead of copying the query into ten reports.
Subscriptions and delivery, redesigned
Standing email subscriptions map across cleanly. Data-driven subscriptions and file-share drops do not, so those are redesigned deliberately — and often shrink, because half the recipients only need access to the report.
Folders and roles become workspaces
Report server folder permissions rarely translate one-for-one. We map them to workspaces, apps, and roles, then check the expressions that depended on the old identity model — the ones that silently change behaviour in the cloud.
Nothing is switched off in a hurry
Reports are published alongside a live report server, run in parallel for a full reporting cycle, and reconciled. The old environment is decommissioned only when the replacements have survived a real month-end.
Which report server objects move, and which get rebuilt?
An RDL file is portable; almost everything around it in the report server catalogue is not. Microsoft's own guidance for migrating .rdl reports (opens in new tab) lists the item types that cannot come across, and it is worth reading before anyone promises a like-for-like lift. The table below is the working map we plan from.
| In SQL Server Reporting Services | In Power BI | What changes in practice |
|---|---|---|
| .rdl report definition | Paginated report in a workspace | Same RDL technology; authored going forward in Power BI Report Builder |
| Shared data source (.rds) | Embedded data source plus a gateway connection | Not supported in the service; converted to embedded and re-credentialed |
| Shared dataset (.rsd) | Embedded dataset, or a Power BI semantic model | Reuse moves up into the model layer instead of the report catalogue |
| Report server folders and permissions | Workspaces, apps, and workspace roles | Access is redesigned, not copied — the two security models differ |
| Standard email subscription | Power BI subscription with the report attached | Supported for paginated reports; schedules and recipients are re-created |
| Data-driven subscription | No like-for-like feature in the service | Redesigned — usually access plus automation rather than a burst of emails |
| Linked reports | Ordinary paginated reports | The link is lost; each arrives as its own report definition |
| KPIs and mobile reports | Power BI report visuals | Do not migrate; rebuilt in Power BI Desktop where still wanted |
| Report parts and report models | Deprecated by Microsoft | Replaced by shared semantic models and reusable measures |
| Catalogue resources (images, files) | Embedded in the report or hosted elsewhere | Logos and assets are re-attached rather than migrated |
| Custom assembly referenced in expressions | Embedded code, or logic pushed upstream | Referencing custom DLL files is not supported; the logic is rewritten |
| Native database connection | Gateway connection on a schedule your DBA agrees to | Credentials and refresh become a governed, auditable configuration |
Two tools do the moving. SQL Server 2022 Reporting Services and Power BI Report Server carry a built-in option to publish .rdl files straight to a workspace (opens in new tab), and Microsoft publishes an RDL Migration Tool on GitHub for earlier versions, which converts shared resources to embedded ones and flags anything unsupported. Neither tool tells you which of your reports is worth the licence it will consume — that is the part we do with you.
Report Builder or Power BI Desktop for each report?
This is the decision that shapes the budget, and it is made per report rather than per estate. Paginated reports keep exact page control and print every row; Power BI reports are built for filtering and exploration. Microsoft frames the split the same way in its paginated reports FAQ (opens in new tab), which is also where the current list of unsupported RDL features lives.
| Decision point | Power BI Report Builder (paginated) | Power BI Desktop (interactive) |
|---|---|---|
| Report format | RDL — the same definition SSRS used | PBIX report over a semantic model |
| Best for | Statements, invoices, remittances, audit packs | Analysis people filter, compare, and drill into |
| Layout control | Exact page breaks, repeating headers, full row printing | Responsive canvas designed for the screen |
| Data access | Embedded datasets, native queries, stored procedures | Power Query and a modelled star schema with DAX |
| User input | Report parameters, cascading where needed | Slicers, filters, and cross-highlighting |
| Typical migration effort | Lower — publish, re-point, verify | Higher — the model is built once and reused many times |
In most estates the answer is both. The operational output that has to print keeps its RDL lineage, while the dozen "show me sales by region and let me change the date" reports collapse into one or two Power BI reports on a shared model — which is the data modeling and DAX half of the job, and where the long-term maintenance saving actually comes from. If those queries run against SQL Server, our SQL Server Power BI dashboard page covers the Import versus DirectQuery and gateway decisions in more depth.
What actually breaks after the upload?
Reports usually publish successfully and then behave subtly differently, which is worse than failing outright. The differences are documented and small in number, so they are checkable rather than mysterious — we work through them as a standing list during reconciliation.
The two that catch teams most often are identity and time. In the Power BI service the UserID built-in field returns a User Principal Name rather than a domain account, so any dataset that filtered on a domain-qualified account name needs revising along with the underlying source data. ExecutionTime returns UTC, which shifts default parameter values and the "run at" line in report footers. Microsoft also documents current globalization limits on DateTime parameters, notes that cascading parameters evaluate sequentially, and warns that SQL Server spatial types behind map visuals are not supported through the gateway. Each of these is a small fix; each is expensive when it is found by a user instead of by us.
When does the report server actually get switched off?
Later than most plans assume, and that is deliberate. Microsoft's migration guidance is explicit that reports can be published without downtime and without removing anything, and that the existing environment can stay in place until you are ready to retire it. So the sequence is publish, run in parallel, reconcile, then decommission — not a weekend cutover.
The pressure to pick a date usually comes from somewhere else: the support lifecycle of the SQL Server version the report server runs on, an operating system upgrade, or a hardware refresh. Check your exact version and edition against Microsoft's product lifecycle listings (opens in new tab) before setting an internal deadline, because those dates — not Power BI — are what makes the migration urgent. We sequence the work backwards from whichever date is real for you, and licensing for paginated reports should be confirmed against Microsoft's current documentation as part of that plan.
What does the migration cost?
Work runs on prepaid Flex hours that never expire: Starter 20 hours ($2,500), Growth 40 hours ($4,600), or Power 80 hours ($8,000), with hourly work from $100/hour. The inventory and classification task is the one to buy first — it converts an unknown number of report items into a costed list, and it is usually the cheapest hours you will spend on the whole project.
After that, every report is estimated in hours and approved before it is built, so the price of each line is fixed before the work starts and you only pay for what you approve. A parameter-driven listing with two totals is a very different job from a statement pack with nested groups and a data-driven distribution list. Unused hours stay banked for the next thing. See Flex pricing.
Who this is for
IT, finance, and operations teams carrying a Reporting Services estate that has become nobody's job: a server due for renewal, an unclear subscription list, reports pointed straight at production, or a Fabric capacity already paid for and barely used. It is a poor fit for a team that wants every item republished untouched — that spends real money recreating the exact clutter you are trying to leave behind.
What you get
- A full RDL inventory with owners and run history
- A paginated / interactive / retire call per report
- Shared datasets resolved into embedded or modelled logic
- Gateway, credentials, and refresh configured
- Subscriptions and delivery re-established
- Reconciliation against the report server, then handover
3–5
business days per report
Phased
not big-bang
You
own everything
Buy the inventory first and decide the rest once the real scope is visible. If your legacy stack is broader than one server, the migration to Power BI service covers the other routes.
How it works
From a report server catalogue to a workspace people trust
- 1
Inventory and classify
We catalogue every report item with its owner, execution history, data source, subscriptions, and complexity, then tag each one paginated, rebuild interactive, merge, or retire. You approve the list and the hours behind it before anything is built.
- 2
Publish, rebuild, and re-plumb
Fixed-layout reports are published and verified in Report Builder; the interactive set is rebuilt on a governed model. Shared datasets, gateway connections, workspace permissions, and expression differences are resolved as part of each task.
- 3
Run in parallel, then retire
Both environments run side by side for a full reporting cycle, outputs are reconciled, subscriptions are re-pointed, and users are walked through the new home. The report server is decommissioned once, on your schedule.
Representative perspective
The execution log settled the argument. Two thirds of the catalogue had not been opened in a year, and the list of reports we actually had to fund fitted on one page.IT director, multi-site healthcare group
Representative perspective
Our concern was the 6am subscriptions. Once those were landing from the new environment and the totals tied out, nobody minded where the reports lived.Finance systems manager, distribution
Find out what your report catalogue really contains
Tell us roughly how many report items you have, which SQL Server version hosts them, and which subscriptions month-end depends on. We'll scope the inventory task in hours so you can see the real project before committing a budget.
FAQ
Questions teams ask before they commit
The files can. Microsoft documents a built-in publish option in SQL Server 2022 Reporting Services and Power BI Report Server, and an RDL Migration Tool on GitHub for earlier versions. Both check for unsupported features and upload what passes. Neither decides which reports still deserve to exist.
Microsoft does not support SSRS-style shared data sources or shared datasets in the Power BI service, so the migration tooling converts them into embedded definitions inside each report. Reuse then moves up a layer: a shared semantic model becomes the single place a query and its business logic live.
Email subscriptions are supported for paginated reports in the Power BI service, with the rendered report attached. Data-driven subscriptions, which read a query to decide recipients and parameters, have no like-for-like feature there, so that delivery pattern is redesigned rather than moved.
Microsoft's guidance splits them by purpose: paginated reports are optimised for printing and PDF output, Power BI reports for exploration and interactivity. Statements, invoices, and audit packs stay RDL in Report Builder. Reports people filter and re-run all day are usually better rebuilt in Power BI Desktop.
No. Microsoft's migration guidance is explicit that reports can be published without downtime and the existing environment stays in place until you choose to retire it. The real deadline usually comes from your SQL Server version's support lifecycle, not from the migration itself.
Work runs on prepaid Flex hours: Starter 20 hours ($2,500), Growth 40 hours ($4,600), Power 80 hours ($8,000), or hourly from $100. Each report is estimated in hours and approved before it is built, so the price of every line is agreed up front and unused hours stay banked.
Related work
This page covers the Reporting Services path specifically. If your legacy reporting spans several tools, the broader migration to Power BI service sequences them together, and teams whose fixed-layout output lives in a different legacy report writer should read the Crystal Reports to Power BI migration page, which handles that estate's own conversion problems. Moving off an IBM stack has its own Cognos to Power BI migration path, and Tableau to Power BI migration covers the renewal-driven case. Because most report server queries point at a relational database, SQL Server Power BI dashboards is the natural next read for connectivity and refresh decisions, while Power BI report design makes the rebuilt reports clearer than the originals rather than merely equivalent. Every task is scoped and approved before work begins from your prepaid block of senior-led hours.
Book a free demo
Get senior Power BI help, on demand
Tell us the task. We scope it, you approve, and a senior consultant delivers — typically in 3–5 business days. Prepaid hours that never expire.
- Prepaid hours from $100/hour — and they never expire
- Senior-led delivery — 20+ years on the Microsoft platform
- Typical 3–5 business day turnaround
- Full refund if you’re unhappy in your first 4 hours
The fastest way to reach us is the form — tell us the task and we'll reply within one business day.