Crystal Reports to Power BI migration services
Built for the business with twenty or forty reports launched from inside an ERP, not an enterprise with hundreds: senior US-based engineers inventory what people actually run, re-derive Crystal formula fields and running totals into Power Query steps and DAX measures, rebuild subreports and cross-tabs that have no direct equivalent, keep print-fidelity invoices and statements paginated, and replace the report button inside your ERP. One written price, typical delivery in 2–4 weeks, 30 days of hypercare included.
Representative dashboard — sample data
What you get
The market sells automated converters aimed at estates of hundreds. A small estate deserves the opposite: a human deciding which reports still matter before anything is rebuilt.
Every .rpt file is listed with who runs it and how recently. The ones nobody has opened in a year are retired by agreement before a single formula is converted, so the fixed fee covers work you will actually use.
Crystal formula syntax does not map line-for-line onto DAX. Each formula is traced back to the business rule it encodes, confirmed with its owner, and rewritten as a Power Query step or a measure defined once.
A subreport is the hardest single item in this migration, because an interactive Power BI report has no equivalent object. Each becomes a drillthrough page, an expandable matrix, or a Report Builder section — chosen deliberately, per report.
Invoices, statements, packing slips, and compliance forms are documents, not dashboards. They are rebuilt as paginated reports so page breaks, headers, and totals land where the people signing them expect.
Crystal is usually reached from inside an ERP rather than a portal. We scope where each report is invoked from and replace it with a secure embed, a workspace app link, or a scheduled export — not a shrug and a bookmark.
A written record of what moved, what was deliberately retired, and what still calls the Crystal viewer or runtime — so the designer licences, the scheduler, and the server behind them can be switched off on a date you choose.
How it works
A free consultation plus a walk through your report menu and .rpt folder tells us what is run, what is duplicated, and what nobody has opened in a year. You get a written scope, one fixed price, and a delivery date.
Shared tables become a semantic model, formulas and running totals become DAX measures, subreports and cross-tabs are rebuilt, and print documents move to Report Builder — each batch checked against the live Crystal output before sign-off.
The ERP-side invocation is replaced, users get a walkthrough of what changed, and once the outstanding list is empty you receive the retirement plan and 30 days of hypercare.
The awkward truth about a Crystal estate is that the reports are not just presentation. Years of rules — how a discount is applied, which orders count as shipped, what "net" means on the statement a customer disputes — were written into formula fields, running totals, and record selection formulas inside individual .rpt files. Nobody wrote them down anywhere else, and the person who wrote them has usually left.
That is why an automated converter is the wrong instrument for a small estate. Crystal's formula language and DAX are not the same kind of thing: Crystal evaluates in report passes over a record set, while DAX (opens in new tab) evaluates measures against filter context on a model. A machine translation of the syntax produces something that runs and quietly answers a different question. We re-derive each formula from the rule it encodes, confirm it with the person who owns the number, and put row-level work in Power Query (opens in new tab) and aggregation work in a measure written once on a star-schema model (opens in new tab).
Some Crystal constructs land cleanly. Others do not exist in Power BI at all, and pretending otherwise is how these projects overrun. The subreport is the clearest example: a whole second report embedded in a band of the first, running its own query, often linked on a field. An interactive Power BI report has no such object. The honest answer is that a subreport is a modelling problem wearing a layout costume — in most cases the two queries belong in one semantic model, and the embedded detail becomes a drillthrough page or an expandable matrix. When the printed artifact genuinely has to keep its shape, the section is rebuilt in Power BI Report Builder as a paginated report (opens in new tab) instead.
The same care applies to groups with suppressed sections, cross-tabs with running totals in the margins, and record and group selection formulas that silently filter what the report ever sees. Each is scoped as its own line item, because "convert 40 reports" is a meaningless number when three of them carry nine subreports between them. This is the point where our approach differs from the field: if your estate really does run to hundreds of reports on a Microsoft report server instead, our SSRS to Power BI migration service is the right page — there the RDL definitions travel largely intact and the work sits in subscriptions and folder security. If the incumbent is a modern self-service BI tool, our Tableau to Power BI migration service covers rebuilding the semantic layer under workbooks that carry their own logic, and our QlikView to Power BI migration service covers the QlikView variant of the same problem, where the business rules sit in a load script and in set analysis expressions rather than in formula fields. If the reports are Cognos rather than Crystal, our Cognos to Power BI migration service is the closer match: the business rules there are governed centrally in a Framework Manager package instead of being redefined inside every report file. And if the SAP estate in question is the BI platform rather than the report writer — universes, Web Intelligence documents, BI Launch Pad and scheduled publications — our SAP BusinessObjects to Power BI migration service is the page for that: same vendor, a different product, and a governed semantic layer that has to be read as a specification before any document is rebuilt.
Most Crystal estates decompose into the same pieces. The table below is the mapping we work from; the inventory in your written scope is a filled-in version of it, report by report.
| In Crystal Reports | Where it lands in Power BI | What the work involves |
|---|---|---|
| Formula fields (Crystal or Basic syntax) | Power Query column or DAX measure | Row-level logic becomes a query step; anything that aggregates or compares periods becomes a measure, re-derived from the business rule rather than translated token by token |
| Running totals and summary fields | DAX measures on the shared model | Reset-on-group and evaluate-after behaviour is re-expressed with explicit filter context, then reconciled against the live Crystal output line by line |
| Record and group selection formulas | Query filters, report filters, row-level security | Hidden filters are surfaced and classified: data that should never load moves upstream, user-dependent filtering becomes row-level security rather than a formula |
| Subreports (linked or unlinked) | One model plus a drillthrough page — or a Report Builder section | No equivalent object exists in an interactive report, so each is rebuilt: usually merged into the semantic model, occasionally kept as a paginated section when the print layout must survive |
| Cross-tabs | Matrix visual on the semantic model | Rows, columns, and summarised fields map onto a matrix; margin totals and percentage-of-parent calculations are rewritten as measures instead of grid-level settings |
| Groups with conditional suppression | Hierarchy plus visual-level filters, or paginated visibility rules | Each suppression condition is read as a business rule and re-implemented where users can see it, rather than hidden in section formatting |
| Parameter fields and prompts | Slicers, or paginated report parameters | Prompt-then-run becomes filter-then-explore for analytical reports; documents that must be produced for one order or one customer keep real parameters in Report Builder |
| Print-fidelity output (invoices, statements, compliance forms) | Paginated report in a Power BI workspace | Rebuilt in Report Builder with page size, headers, footers, and page breaks matched, then render-tested against the PDF your Crystal report produces today |
| Report launched from inside your ERP | Secure embed, workspace app link, or Power Automate export | The invocation path is documented first, then replaced with whatever your ERP supports; scheduled or bursted output becomes a flow with visible run history |
| Databases and stored procedures behind the reports | Stay where they are, read through a data gateway | Nothing is moved; Power BI connects alongside Crystal so both can run in parallel while each report is reconciled |
| Designer licences, scheduler, viewer and runtime components | Nothing — this is what you retire | Written retirement plan: remaining dependencies, what still calls the runtime, and a shutdown date you choose rather than discover |
This is the scoping question that separates a Crystal migration from every other reporting move, and the one most proposals skip. Crystal is rarely reached from a report portal. It is reached from a button in an ERP, a menu item in a line-of-business application, or a nightly scheduler that bursts a PDF per customer. Move the report and leave the button, and you have not finished the job — you have given forty people two places to look.
So the invocation path is inventoried alongside the reports. Some ERPs will happily open a URL, in which case a link to a workspace app or a filtered report is enough. Others support hosting a page, where Power BI's secure embed (opens in new tab) puts the report inside the application with your existing sign-in still doing the authentication. Where the report was never interactive to begin with — the statement run that mails a PDF to every account on the first of the month — the right replacement is a scheduled export, which is the kind of work our Power Automate consulting service covers in more depth. Underneath all three options, your databases stay where they are and Power BI reads them through a data gateway (opens in new tab), so Crystal and Power BI can run side by side until every report has been signed off.
It fits organisations already on Microsoft 365 that are carrying a Crystal estate somewhere between a dozen and a few dozen reports: a designer licence or two, a scheduler nobody wants to touch, a runtime pinned to an ERP version, and a set of reports that genuinely still matter. The trigger is usually an ERP upgrade, a server rebuild, or the moment someone asks why reporting lives outside the platform everything else already runs on.
It is deliberately not scoped as an enterprise programme. If you have hundreds of reports and want a tool to convert them in bulk, several firms sell exactly that and you should talk to them. What we sell is one fixed-fee project with a stated end date, where the first deliverable is a shorter list of reports than you started with. Once the estate lands, new reporting built on the model is separate work — that is our fixed-fee Power BI dashboard development service, and the guide to what a Power BI dashboard actually costs explains how scope drives a number. Licensing comes up early too, and the small-business licensing guide covers the options — including the fact that publishing paginated reports has a different licensing footprint from publishing interactive ones, which is a decision worth making before the rebuild rather than after.
The table shows scope and typical timeline rather than prices, because an honest number requires seeing your report list and your subreport count first — the same principle described on how our fixed-fee process works.
| Phase | Scope | Typical timeline | Fee |
|---|---|---|---|
| Phase 1 — inventory, triage, and the model | Every .rpt catalogued with its owner, usage, and invocation path; the dead ones retired by agreement; workspace and gateway set up; the shared semantic model built from the tables the survivors depend on | About the first week | Fixed fee — scoped after your free consultation |
| Phase 2 — formulas, subreports, and print documents | Formula fields and running totals re-derived as Power Query steps and DAX measures, subreports and cross-tabs rebuilt, print-fidelity documents recreated as paginated reports, each reconciled against live Crystal output | Weeks 2–3 | Fixed fee — scoped after your free consultation |
| Phase 3 — rewire and retire | ERP-side invocation replaced with an embed, link, or export flow; access rules applied and tested; user walkthrough delivered; plus the written retirement plan for the designer licences, scheduler, and runtime | Week 4 and close-out | Fixed fee — scoped after your free consultation |
Everything produced is yours from the first day: the semantic model, every measure, the report and paginated report files, the flows, and the workspace configuration all live in your own Microsoft tenant, never in ours.
Related services
When the source is a Microsoft report server: RDL files republished as paginated reports, subscriptions rebuilt, the server retired.
When the source is a modern self-service BI tool: the semantic layer rebuilt first, then reports moved in waves by business unit.
Fixed-fee development for the reporting you want built new, once your estate has landed on Power BI.
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
Each formula is read and re-expressed rather than transliterated. Row-level calculations usually become Power Query columns; anything that aggregates, ranks, or compares periods becomes a DAX measure defined once on the shared model. We agree the business rule behind each formula with its owner before writing the replacement.
A Power BI report has no subreport object, so each one is handled deliberately. Most become part of the same semantic model, surfaced as a drillthrough page or an expandable matrix. Where the output has to print exactly as it does today, the section is rebuilt in Power BI Report Builder instead.
That invocation is scoped explicitly, because it is usually the part nobody documented. Depending on what your ERP allows, a report button becomes a secure embedded Power BI report, a link to a workspace app, or a Power Automate flow that exports and delivers the document on the same schedule.
No. Documents built to print — invoices, statements, packing slips, compliance forms — stay paginated and are rebuilt in Power BI Report Builder, where page size, headers, and totals behave predictably. Only the reports people genuinely explore are rebuilt as interactive Power BI reports on the shared model.
Deliberately not. The first pass is an inventory: who ran each report, how recently, and whether anyone would notice if it stopped. Reports nobody has opened in a year are retired by agreement before any conversion work starts, so you pay to rebuild the ones that still earn their place.
Typical delivery is two to four weeks from kickoff, with dates written into your scope. The fixed fee reflects how many reports survive triage, how much formula logic has to be re-derived, how many subreports need rebuilding, and how the reports are invoked today. Nothing starts until you approve it.
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.