How is a Power BI engagement priced for enterprise workloads?

Pricing is modeled against three variables: the complexity of the semantic layer, the volume and velocity of source data, and the governance footprint required after go-live. A scoped implementation typically runs as a fixed-fee discovery sprint followed by a time-and-materials build, because dataset refresh patterns and row-level security rules almost always evolve once real user personas review early drafts. Licensing is separated from consulting fees and mapped against Power BI Pro, Premium Per User, and Fabric capacity SKUs so finance teams can plan capacity uplift independently of delivery cost. A typical mid-market rollout lands between 120 and 480 consulting hours across data modeling, DAX optimization, report design, and deployment pipelines. Fabric workloads add capacity sizing sessions to avoid over-provisioning F-SKUs on day one.

How long does a production-ready Power BI rollout take?

A single subject-area workspace with a conformed star schema, deployment pipeline, and row-level security ships in roughly six to eight weeks once source access is granted. Multi-domain rollouts that span finance, operations, and customer analytics typically run three to five months because the semantic model has to reconcile calendar, product, and organizational hierarchies that rarely align across source systems. Fabric lakehouse projects add four to six weeks for medallion design, Direct Lake tuning, and OneLake shortcut setup. Timelines compress when an authoritative data dictionary already exists and lengthen when stakeholders are discovering definitions (for example, what counts as "active customer") for the first time. Governance, training, and center-of-excellence enablement are run in parallel rather than sequentially.

What delivery methodology do you use for Power BI and Fabric projects?

Delivery runs on a five-stage pattern: Discover, Model, Visualize, Operationalize, and Enable. Discover captures questions stakeholders actually want answered, not just source tables. Model builds a Kimball-style star schema (or a medallion lakehouse in Fabric) with conformed dimensions and documented grains. Visualize produces reports against a shared theme file, applies accessibility tokens, and uses bookmarks and field parameters instead of bespoke page duplication. Operationalize wires up deployment pipelines, dataset refresh monitoring, and Azure DevOps or GitHub source control via TMDL. Enable delivers hands-on training for citizen developers and a lightweight center-of-excellence charter. Each stage ends with a demo and a written acceptance checklist, so scope creep is visible before it becomes rework.

How do you secure sensitive data inside Power BI reports?

Security is layered rather than relying on a single control. Row-level security and object-level security are enforced inside the semantic model using DAX filter expressions driven by Entra ID group membership, so filters survive refresh and cannot be bypassed by report-level tricks. Sensitivity labels from Microsoft Purview are applied at dataset and report scope and follow exports into Excel and PDF. Workspace roles follow a least-privilege pattern (Admin, Member, Contributor, Viewer) and are granted to Entra ID groups, never individuals. Private endpoints and VNet data gateways keep on-premises sources off the public internet, and tenant-level settings restrict publish-to-web, external sharing, and guest access. Every production dataset is audited quarterly against a written RLS test plan.

Can existing Excel and Tableau reports be migrated into Power BI?

Yes, but a migration is an opportunity to redesign rather than a literal port. Excel financial models usually translate cleanly into a semantic model: named ranges become dimensions, pivot tables become matrix visuals, and SUMIFS chains become well-formed DAX measures with variables. Tableau workbooks require more interpretation because Tableau extracts and Power BI datasets have different refresh and relationship semantics; calculated fields are rewritten as DAX, LOD expressions become CALCULATE patterns, and dashboard actions are rebuilt using bookmarks and drillthrough. A discovery audit catalogs every report, ranks them by business value, and retires the long tail of duplicates before migration starts. This typically reduces the report estate by 30–50 percent.

How do you optimize DAX performance on large semantic models?

DAX performance starts with the model, not the measure. Star schemas with integer surrogate keys, single-direction relationships, and calculated columns materialized in Power Query outperform ambiguous snowflakes every time. Measures are written using variables (VAR/RETURN) to avoid repeated context transitions, and expensive patterns like FILTER over entire tables are replaced with KEEPFILTERS and Boolean filter arguments. Aggregation tables and composite models offload detail-level queries from imported caches to Direct Lake or DirectQuery sources. Every measure that appears in a production report is profiled with DAX Studio and VertiPaq Analyzer; queries above a 2-second threshold on representative hardware are rewritten before release. Fabric capacity metrics are reviewed weekly to catch runaway refreshes and interactive CPU spikes.

Do you support Microsoft Fabric, OneLake, and Direct Lake workloads?

Fabric is now the default landing zone for new analytics workloads unless a client has a specific reason to stay on legacy Power BI Premium capacity. Engagements cover medallion architecture design in lakehouses, data engineering pipelines built in Fabric notebooks or Dataflows Gen2, shortcut-based integration with Azure Data Lake Storage and Amazon S3 through OneLake, and Direct Lake semantic models that skip import refresh entirely. Capacity sizing is based on measured workload patterns rather than vendor rules of thumb, and F-SKU scaling is automated through Azure Logic Apps or the Fabric REST API so off-hours costs stay predictable. Copilot in Fabric is configured with tenant-level data boundaries and audit logging before it is enabled for end users.

What training and enablement do end users receive after go-live?

Training is tiered by persona. Report consumers get a 45-minute guided tour covering filters, bookmarks, subscriptions, and mobile access. Analysts get a three-session workshop on self-service semantic model extensions, composite models, and publishing to workspaces that follow the governance pattern. Data modelers receive a two-day immersion on star schema design, DAX fundamentals, and deployment pipeline usage. Every session is recorded, indexed, and paired with a sandbox workspace seeded with representative sample data. A written center-of-excellence charter defines who owns certified datasets, who can promote a report to production, and how to request enhancements. Office hours run for 30 days post-launch so questions do not pile up into a formal change request.

How are Power BI deployments managed across dev, test, and production?

Every production workspace is paired with matching development and test workspaces wired through Power BI deployment pipelines. Datasets are source-controlled as TMDL files in Azure DevOps or GitHub so pull requests can be reviewed by a second modeler before merge. Environment-specific parameters (connection strings, sensitivity label rules, capacity assignments) are swapped at deployment time using parameter rules rather than manual edits. Fabric deployment pipelines handle lakehouses, notebooks, and data pipelines with the same promotion pattern. Refresh schedules, gateway assignments, and alerting are applied through the Power BI REST API so they survive redeployment. A written change-management checklist covers dataset certification, dependency impact analysis, and rollback procedure for every promotion to production.

Which industries and data sources do you support most often?

Heaviest experience sits in healthcare, financial services, energy, manufacturing, and public sector, because each of those verticals pushes a different dimension of Power BI: HIPAA-bound PHI handling, transaction-grain reconciliation, time-series sensor data, cost-center-driven manufacturing variance, and FedRAMP-aligned government reporting. Source systems frequently include Microsoft Dynamics 365, SAP ECC and S/4HANA, Salesforce, Workday, Epic and Cerner (Oracle Health), Infor, and a long tail of legacy ODBC databases connected through on-premises data gateways. Fabric engagements add Azure Data Lake Storage, Snowflake, Databricks, BigQuery, and Amazon S3 through OneLake shortcuts. Regardless of source, the modeling discipline is identical: conformed dimensions, documented grains, and a semantic layer that hides the join complexity from report authors.

Power BI Project Format (PBIP) + Git + CI/CD (2026)

Quick Answer

PBIP is the Git-native Power BI save format. Every new project in 2026 should be PBIP. TMDL is the text-first format for the semantic model, and it diffs cleanly in pull requests. Combined with Fabric Git integration, CI pipelines running Tabular Editor BPA, and automated deployment via XMLA, PBIP is the foundation of enterprise Power BI ALM.

1. Anatomy of a PBIP Project

SalesAnalytics.pbip             # Project manifest (small JSON file)
SalesAnalytics.SemanticModel/
    definition/
        model.tmdl              # Root model definition
        tables/
            Customer.tmdl       # Per-table definitions
            Product.tmdl
            Sales.tmdl
            Calendar.tmdl
        cultures/
            en-US.tmdl          # Localization metadata
        relationships.tmdl      # Relationship definitions
        roles.tmdl              # RLS role definitions
    diagramLayout.json          # Model view diagram positions
SalesAnalytics.Report/
    definition.pbir             # Report definition
    report.json                 # Report structure
    StaticResources/            # Images, themes
.gitignore
README.md

2. TMDL Example

// tables/Sales.tmdl
table Sales
    lineageTag: 7f3e4d-sales-fact

    measure 'Total Revenue' = SUM(Sales[Amount])
        formatString: $#,0;-$#,0
        displayFolder: Revenue

    measure 'Total Revenue YoY %' =
        VAR Current = [Total Revenue]
        VAR Prior =
            CALCULATE([Total Revenue],
                SAMEPERIODLASTYEAR('Calendar'[Date])
            )
        RETURN DIVIDE(Current - Prior, Prior)
        formatString: 0.0%;(0.0%)
        displayFolder: Revenue

    column Amount
        dataType: decimal
        sourceColumn: Amount

    column OrderDate
        dataType: dateTime
        sourceColumn: OrderDate

    partition Sales = m
        mode: import
        source = "
            let
                Source = Sql.Database(ServerName, DatabaseName),
                FactSales = Source{[Schema=\"dbo\",Item=\"FactSales\"]}[Data]
            in
                FactSales
        "

Every object is explicit and indented. Measures, columns, partitions, and lineage tags are all visible. A code reviewer can evaluate a pull request without opening any Power BI tool.

3. Recommended .gitignore

# Power BI cache and local settings
*.pbix
*.pbit
.pbi/cache/**
*/.pbi/cache.abf
*/.pbi/localSettings.json
*/.pbi/mashup.cache

# OS
.DS_Store
Thumbs.db

# Editor
.vscode/
.idea/

Commit the TMDL and .pbip files. Exclude any binary PBIX, Power BI Desktop cache files, and local environment settings.

4. Branching Strategy

main: protected, requires pull request and passing CI.
feature branches: developers create a branch per change. Open pull requests back to main.
release branches: optional for major version milestones; tag with semantic versions.

For Fabric Git integration, most teams connect the Development workspace to a long-lived "workspace/dev" branch that auto-syncs. Merges from feature branches into this branch trigger the workspace to update.

5. CI Pipeline Steps

Checkout: pull the feature branch.
Tabular Editor BPA: run Microsoft's Best Practice Analyzer rules on the .SemanticModel folder. Fail on Critical and Major violations.
TMDL lint: custom rules (naming conventions, required descriptions, forbidden patterns).
DAX smoke tests: deploy to a test workspace, run expected-result queries, validate.
Report JSON lint: check for hardcoded URLs, missing accessibility tags, or inconsistent themes.
Status check: publish results to the pull request. Block merge if any step fails.

For detailed CI/CD examples see our deployment pipelines and CI/CD guide.

Frequently Asked Questions

What is PBIP format?

PBIP stands for Power BI Project format. It is a folder-based, text-first save format that replaces the legacy binary PBIX format for source-controlled development. A PBIP project contains a .pbip file (the project manifest), a .SemanticModel folder (TMDL definition of the model), and a .Report folder (JSON definition of the report canvas). Because every artifact is text-based, PBIP projects work naturally with Git, diff cleanly in pull requests, and merge without conflicts in most cases.

How do I enable PBIP in Power BI Desktop?

Open Power BI Desktop. Go to File > Options and Settings > Options. Select Preview features. Check "Power BI Project (.pbip) save option" and "Store semantic model using TMDL format". Restart Power BI Desktop. Now when you save, choose Save As and pick the Power BI Project format. Existing PBIX files can be converted by opening them and re-saving as .pbip.

What is TMDL?

TMDL stands for Tabular Model Definition Language. It is a human-readable YAML-like format for defining Power BI semantic models. Every table, column, measure, relationship, role, and perspective is represented as indented text. TMDL diffs are meaningful in pull requests: changing a measure formula appears as a 3-line diff, not a 50MB binary diff. TMDL is the replacement for the legacy JSON-based Tabular Model Scripting Language.

Can PBIX and PBIP coexist?

Yes, but avoid mixing them within a single project. You can have some repos in PBIX format and others in PBIP. Within one project, pick PBIP and stay with it. Power BI Desktop can open both formats, and Save As converts between them, but mixing within a Git repository creates confusion. For any new project, use PBIP.

How do PBIP merge conflicts work?

Most conflicts are text-mergeable in Git. If two developers add new measures to different display folders, the merge is automatic. If two developers modify the same measure, the conflict appears on the specific TMDL lines and can be resolved manually. The one place conflicts can be painful is the report JSON file, which is less diff-friendly than TMDL. To minimize report conflicts, avoid having multiple developers edit the same report page simultaneously; instead, have them work on different pages or different PBIP files.

Can I author TMDL directly without Power BI Desktop?

Yes. Tabular Editor 3 has full TMDL support and is often the preferred authoring environment for experienced Power BI developers. Direct TMDL editing with Tabular Editor is faster than Power BI Desktop for measure-heavy work. Power BI Desktop is better for visual report authoring and initial data import. Most teams use both: Desktop for reports, Tabular Editor for model.

How does Fabric Git integration interact with PBIP?

Fabric Git integration reads and writes PBIP format directly. When you connect a Fabric workspace to a Git repository, the workspace contents appear as PBIP folders in the repo. Changes in the workspace appear as commits. Changes pushed to the repo apply to the workspace. This means your Git repo can serve as both the source control for desktop-authored changes and the sync layer for workspace-authored changes. It is the foundation of modern Power BI ALM.

Can I validate PBIP in CI builds?

Yes. Run Tabular Editor 2 Command Line (free) against the .SemanticModel folder to execute Best Practice Analyzer rules. Parse the .Report JSON with a linter for visual-level checks. Run DAX unit tests via XMLA endpoint against a deploy-and-test workspace. Reject the pull request if any validation step fails. This is the standard enterprise CI pattern.

Moving to PBIP and Git?

Our consultants help teams migrate from PBIX to PBIP, set up Fabric Git integration, and build validation pipelines. Contact us for an ALM maturity assessment.

Power BI Project Format (PBIP) + Git + CI/CD