Every SSRS migration we have seen quoted was quoted per report. Count the RDL files, multiply by a day rate, present a number. Then the project runs for three times the estimate and nobody can point to the moment it went wrong.
The estimate was not wrong about the conversion. Converting a report is genuinely quick. It was wrong about everything around it.
Nobody knows which reports are still used
A ten year old SSRS estate accumulates reports the way a garage accumulates cardboard. Somebody built a variant for one month end in 2019 and it was never deleted. The finance team has four reports that differ only in a hardcoded date range. There is a folder called Archive that is not archived.
Before you migrate anything, query the execution log. SSRS has been recording
every render since the day it was installed, in the ExecutionLog3
view in the ReportServer database. It tells you what ran, when, who
ran it, how long it took and whether it came from a subscription or a person.
The shape of that data is consistent enough to be boring. A rough third of a typical estate has not been opened in a year. Another chunk runs only as an email subscription that lands in a mailbox nobody reads. What is left, the genuinely used set, is usually far smaller than the file count suggests, and it is the only part worth paying to rebuild.
This is also the least popular finding you will deliver, because somebody has to go and ask the owners of the unused reports whether they can be retired. That conversation is the real critical path. Start it in week one, not after the build.
Interactive and paginated are different products
Power BI is often sold as the replacement for SSRS, which is only half true. A dashboard someone explores and a document someone prints, signs and files are different things, and trying to make one do the other is where migrations acquire their reputation for disappointing people.
The test is simple. If the output ends up on paper, in a PDF sent to a regulator, or in an email at 6am every day, it wants Power BI paginated reports. If somebody slices, filters and asks follow-up questions, it wants an interactive report over a semantic model. Sort the surviving reports into those two buckets before you design anything.
Teams that skip this end up rebuilding a fourteen column invoice register as an interactive visual, discovering it will not export cleanly to a fixed width PDF, and concluding that Power BI is not ready. Power BI was ready. The report was sorted into the wrong bucket.
The numbers have to agree, and somebody will check
This is the part that decides whether the project is trusted. On the day you switch a report over, someone in finance will run the old one and the new one and compare them line by line. If a total is out by a rounding difference on one row, confidence in the entire migration is gone, and no amount of explaining floating point will get it back.
So do that comparison first, automatically, and keep doing it. Run both systems in parallel for a full reporting cycle. Write the output of each to a table. Compare row counts, key totals, and a hash of the full result set. Alert on any difference. When the business asks whether the new report is correct, the answer should be a link to a test that has passed every night for a month, not an opinion.
The differences you find are usually real, and usually old. A filter that excluded cancelled orders in one report and included them in another. A join that quietly dropped rows with a null customer. Reconciliation does not only de-risk the migration, it finds bugs that have been misreporting the business for years.
What this means for the plan
A migration plan built around report count says: convert reports, then test. A plan built around what actually causes delay says something different.
Start with usage telemetry so the scope shrinks to what is real. Get retirement decisions moving early, because they depend on people, not on you. Sort the survivors into interactive and paginated before designing. Build the reconciliation harness before the first report, so every rebuild is proven the day it lands. Then convert, which is the fast part, and the part your original estimate was actually about.
The conversion was never the problem. It just happens to be the only part that is easy to count.