ProLaw to Microsoft Fabric: Keep Law Firm Reporting Dashboards Stable Through a System Change
ProLaw billing and matter data reaches OneLake through a protected read path, so Power BI law firm reporting dashboards can keep working through a system change.
ProLaw to Microsoft Fabric is the move many law firms consider when their practice management data needs better reporting than the system itself delivers. ProLaw, from Elite, holds matters, time, billing and trust and general ledger accounting. Partners and finance leaders still ask for realization, work in progress and utilization in one trusted view. Fabric gives that data a governed home, so reporting dashboards are built once and keep working whether the firm stays on ProLaw or changes platform later.
This guide is for managing partners, finance directors and the analysts who support them. It covers how ProLaw data can reach Fabric, how to model it so it outlives the source system, and which measures to build first.
Why Law Firm Reporting Strains on a Legacy System
ProLaw is a long-established product. A directory listing describes it as a legacy product that remains supported for existing customers, so confirm current support dates and the roadmap with Elite before you plan around it. Firms in that position often live with reports that were built years ago, a few spreadsheets maintained by one person and a growing list of questions nobody can answer quickly.
One practitioner write-up describes ProLaw reports running on SQL Server Reporting Services and writing rows into report tables while they run, with leftover rows slowing reporting if a session ends badly. Whatever your own setup, running heavy reporting against the live database is a risk worth removing.
Why ProLaw to Microsoft Fabric Works for Reporting Dashboards
Fabric brings OneLake storage, pipelines, notebooks, a warehouse and Power BI together on one capacity. Once ProLaw data lands in a lakehouse it can be modeled around firm concepts such as matter, client, timekeeper and period, instead of around ProLaw table names. Reporting dashboards then read from the model, not from the source system.
That separation is the main benefit for a firm in transition. If you later move, the source feed changes while the model and the reporting dashboards stay familiar. We cover neighboring systems in our guides to Elite 3E to Microsoft Fabric, Aderant to Microsoft Fabric and Clio to Microsoft Fabric, which also helps if the firm is comparing destinations.
How ProLaw Data Can Reach Fabric
One hosting provider states that ProLaw runs on Microsoft SQL Server, and that it can run on premises or in a private cloud. Because the data sits in SQL Server, there are several routes into Fabric. Confirm the details with your administrator and Elite, because hosting, versions and contract terms differ between firms.
| Route | What it offers | Check first |
|---|---|---|
| Mirroring from SQL Server | Near real-time replication of selected tables into OneLake, with no pipeline to build | Which SQL Server versions Fabric supports today, a gateway if the server is behind a firewall, hosting rules |
| Scheduled copy through a gateway | Dataflow Gen2 or a pipeline copies tables on a schedule using the SQL Server connector | Gateway placement, incremental logic, load window |
| Read-only replica or restored backup | Reporting reads from a copy, so the live database is not queried | Refresh frequency, storage, who maintains the copy |
| Report exports | Existing reports saved to files for a quick start | Fields missing from the export, manual steps, audit trail |
For most firms, mirroring or a scheduled copy is the best long-term route, because the data arrives as tables you control. If ProLaw is hosted by a provider, ask what database access they allow before you design anything. Our Microsoft Fabric migration approach and migration checklist show how data movement fits a wider plan.
How ProLaw data can reach OneLake through a protected read path so law firm reporting dashboards do not query the live database.
ProLaw to Microsoft Fabric: Build a Model That Outlives the System
Do not rebuild ProLaw's tables one for one. Land them as received in a raw layer, then build conformed tables for clients, matters, timekeepers, fee types and dates. Fact tables hold time entries, billings, collections and expenses. Measures sit on top. The layers below are a common pattern.
| Layer | What it holds | Check first |
|---|---|---|
| Raw | Source tables as received, with load date | Who can read it, retention |
| Conformed | Clients, matters, timekeepers, practice groups, dates | Matter and client hierarchies, closed matters, merged records |
| Facts | Time, billings, collections, expenses, work in progress | Write-offs, adjustments, rate changes |
| Measures | Realization, utilization, aging, work in progress | Definitions agreed with finance and practice leaders |
Keep rates, write-downs and adjustments as history, not overwritten values, so you can explain how a number changed. Trust accounting data deserves extra care, so apply strict access rules to it and agree with your compliance lead what may appear in a reporting dashboard.
- ProLaw to Microsoft Fabric gives law firm billing and matter data one governed home for reporting dashboards.
- Confirm current ProLaw support dates and roadmap with Elite before planning around the system.
- Mirroring or a scheduled copy from SQL Server keeps reporting load off the live database.
- Model around firm concepts, not ProLaw table names, so the model survives a platform change.
- Start with realization, work in progress and utilization, and agree each definition first.
Stay or Move: Keeping Reporting Stable
Firms often postpone reporting work because a system decision is pending. That is usually the wrong order. A Fabric model built on firm concepts can run on ProLaw today, run on both systems during a migration and continue on the new platform afterwards. Partners see one set of reporting dashboards the whole time, and finance can reconcile old and new results side by side.
Law firm data is sensitive, so decide who may see client names, matter detail and rates, and apply row-level security by practice group or office. Our OneLake security, DLP and governance checklist covers the controls. Our data governance consulting work and the Power BI Governance Platform keep definitions and access consistent. If the firm already knows the answer is a move, our guide on why to migrate CRM and ERP data to Microsoft Fabric explains the wider case.
Law Firm Measures to Build First
Start with a small set that partners and finance both use. Good first reporting dashboards cover work in progress, billing realization, collections and receivables aging, and utilization by timekeeper. Add budget against actual by practice group and matter profitability once the foundation is trusted.
An illustrative law firm billing and utilization reporting dashboard layout. All figures are sample data.
Agree each definition first. Realization against standard rates and against agreed fees are different numbers, and both can be useful. Decide how write-offs, write-downs and disbursements are treated. Model clients, matters, timekeepers and dates as shared dimensions so every measure reads the same entities. Our Power BI consulting team builds the models and dashboards.
ProLaw to Microsoft Fabric: What to Do Next
Start with one question and one practice group. Confirm ProLaw support dates with Elite, confirm which data routes your hosting allows, load a small set of tables into a restricted lakehouse, build one semantic model and one reporting dashboard, and reconcile it to a ProLaw report. Then add practice groups and offices. Our CRM and ERP Microsoft Fabric migration guide covers the wider plan.
A short discovery confirms what ProLaw data you can reach, how to secure it and what to build first. Numlytics designs and builds Microsoft Fabric consulting solutions and Power BI reporting for professional services firms. Speak with a certified consultant to turn your ProLaw data into reporting you can trust.