Taking over a Power BI project after the vendor walked away: where to start
The vendor is gone, documentation is non-existent, and reports keep breaking in production. Here is the approach I use to take back control without smashing what works.
Picking up a Power BI estate after a vendor has walked away is one of the most uncomfortable situations a data team can land in. No documentation, business-critical reports running in production, and every week that passes makes the environment more opaque. The good news: there is a clear way to take back control without breaking what works.
1. Stabilise first
The most common mistake I see is the urge to rebuild everything. It is almost never the right call. Before any optimisation or refactor, you need to secure what is running. Concretely:
- Inventory of workspaces, datasets and business-critical reports.
- Check on scheduled refreshes: frequency and success rate over the last 30 days.
- Identify service accounts and on-premises data gateways in use.
- Map sources: ERP, SQL, APIs, the Excel files everyone forgets that critical reports still rely on.
2. Reverse engineer the model
Once the environment is safe, attack the core: the data model. That is where the real complexity hides. A legacy dataset may carry hundreds of DAX measures, unchecked bidirectional relationships, and stacked calculated columns.
The goal is not to understand everything in a day, but to produce a readable map the team can use to make decisions:
- Tables, relationships, cardinalities, filter direction.
- DAX measures grouped by business domain (finance, sales, operations…).
- Power Query steps, sources, critical transformations.
- Dependencies between datasets, dataflows and reports.
3. Document so you can survive without the vendor
The documentation produced at this stage has to be sustainable over time. It should be readable by both a business analyst and a BI developer. Items I always document:
- List of critical metrics with their business formula (in plain English), their DAX formula (as code) and their source.
- Model diagram, with architecture choices justified.
- Refresh procedure: order, dependencies, fragile points.
- Onboarding playbook for the next BI developer.
4. Optimise only what is worth it
Once stabilisation and documentation are done, optimisation becomes an option. But be careful: optimising what you do not yet understand is how regressions get introduced. My priorities at this stage:
- Refactor the most used and slowest DAX measures.
- Rationalise duplicated datasets.
- Tune Power Query queries: query folding, reduce loaded volume, fix data types.
- Put basic governance in place: naming conventions, dedicated workspaces, access policy.
5. And after that?
At this point the environment is healthy and transferable. The team can keep evolving it in-house, or lean on a tightly scoped managed-support contract to absorb changes without piling up new debt.
The key to a successful handover is not speed. It is discipline in the order of steps: stabilise, understand, document, then optimise.
Running into something similar?
Tell me about your situation. I reply within one business day.