Our Power BI Developer Has Left. Now What?

If your Power BI developer left last week or handed in their notice this morning, you are probably not reading this for theory. Reports need to refresh tomorrow and the one person who knew how it all worked is gone, or nearly gone. I have been called into this exact situation more than once, so let me give you the short version first.

Secure admin access and gateway credentials before the account is disabled. Stabilise what is running today, refresh schedules, credentials, anything sitting in a personal workspace. Then, and only then, decide the long-term ownership model before you rush a replacement hire.

Key takeaways:

• The first week is about access and continuity, not decisions. Get the keys before the account goes.
• The first month is about finding out what you actually have. Most teams are surprised.
• Replacing like-for-like is one option of three, and often not the right one.
• The real problem is rarely the person leaving. It is that everything lived in one person's head, and that is a governance gap you can fix.

The First Week After Your Power BI Developer Leaves

Stop the bleeding first. Here is the checklist I work through when I walk into one of these, roughly in order of how quickly things break without them:

• Tenant and workspace admin access: make sure at least one other named person is a Fabric admin and an Admin on every production workspace.
• Gateway ownership and credentials: find every on-premises data gateway, who owns it and which machine it runs on. Recover or reset the data source credentials.
• Refresh schedules and failure alerts: list every scheduled refresh and change the failure notification contact. If refreshes ran under the developer's account, they can start failing the day that account is disabled.
• Licence and capacity admin: confirm who can manage Pro or PPU licences and any Fabric capacity settings.
• The files themselves: find where the PBIX or PBIP files actually live. Desktop folder, OneDrive, SharePoint, a repo if you are lucky. Get copies somewhere the organisation controls.
• Personal workspaces: check whether anything in the developer's My Workspace is being used in production. This happens far more than people expect and content in a personal workspace can be lost when the account is deleted.

And talk to IT before they run the standard leaver process! Offboarding scripts that disable accounts on the last day are exactly right for security, and exactly wrong for a gateway still running under that identity. Buy yourself a short window.

One more thing, and it matters. If the developer is still serving their notice, you are in the cheapest recovery window you will ever get. Run a proper handover while they can still explain things. Walk through the critical reports together, record the sessions, have them talk through the logic that exists nowhere but their head, transfer gateway and data source ownership while they are there to confirm it works. A structured Power BI handover in the notice period saves weeks of reverse engineering later. Do not let those weeks disappear into wrapping up tickets.

The First Month, Find Out What You Actually Have

Once nothing is on fire, the next job is an honest inventory. In our experience, this is where the surprises live. I walked into one of these situations and found the report feeding a board pack every month was published from the developer's personal workspace... nobody else even had access to it. At another, the gateway for half the refreshes was running on a laptop. A laptop that went home with its owner every evening (not good).

So, what does the inventory cover? Which reports and semantic models exist, which are business-critical versus quietly abandoned, what data sources feed them, what the refresh dependencies are, and where the undocumented logic sits. That last one matters, the DAX and Power Query steps that only made sense to the person who wrote them.

You are probably thinking this sounds like a lot of work on top of everything else. It is, but it does not need to be a six-month archaeology project. A lightweight, structured pass over the estate is enough to separate what needs protecting from what can wait. This is essentially a scoped-down version of what we cover in a Power BI health check, and if you want the deeper structured version, our governance audit approach covers how to assess an estate properly.

Should You Replace Your Power BI Developer Like-for-Like?

Here is the question most organisations jump to on day one, and I would gently push it to week two or three. Once you know what you actually have, there are usually three routes, and the right one depends on the shape of the work, not the shape of the vacancy.

A like-for-like permanent hire is right when the workload is genuinely full-time and stable. New reports every week, an active backlog, real demand. If that is you, recruit, and recruit properly.

Consultancy support is right when the estate needs stabilising and rebuilding on better foundations before anyone permanent inherits it. A good partner fixes the structure, documents it, and hands it over stronger than they found it. I have written before about when in-house is enough and when it is not, so I will not re-run that argument here.

Fractional or part-time ownership is right when the estate needs senior oversight and steady hands, but not five days a week of building. A day or two of experienced attention often covers maintenance, small changes and standards, at a fraction of a full-time cost. More on this in our fractional BI leadership page, and on choosing between a freelancer and a consultancy.

And a fourth, honest mention. If your plan and standards are already solid and you simply need hands while you recruit, a good contractor can hold the line, provided someone internal owns the direction. More on choosing between a freelancer and a consultancy.

Let me be clear, none of these is the "correct" answer in general. I have recommended all three, and I am happy to tell a prospective client that what they need is a recruitment process, not us.

Why This Happened, and How to Stop It Happening Twice

Now the uncomfortable bit. The developer leaving hurt this much because everything lived in one person's head. That is not a hiring failure, and it is not the developer's fault either. It is a standards and governance gap, and it is one of the most normal things I see. Organisations let knowledge concentrate because the person was good and things worked... right up until they did not.

The fix is structural, not personal. Documentation standards, so the next person can read the estate. A deployment process and version control, so files live somewhere the organisation owns. A second pair of eyes on anything business-critical, so no single account is a single point of failure. Whoever you bring in next, permanent or external, capability plus capacity plus standards is the combination that makes the estate survivable. This is exactly the ground our Power BI governance service covers, and if you want the wider argument for foundations first, I have made it here.

"We Just Need Someone Quickly, Not a Governance Lecture"

Fair. I get this pushback a lot, and honestly, in week one you are right. Stabilise first, worry about frameworks later.

But here is the recruitment reality, a good permanent Power BI developer can take months to land. Advert, interviews, notice period. Your reports still need to refresh tomorrow, and next month, and the month after. Interim support and recruitment are not either/or. Some of the most sensible engagements I have run were exactly this shape, keep the lights on, document as we go, then hand a clean, understandable estate to the permanent hire on their first day. The new person starts with a map instead of a mystery.

This is broadly what Metis BI does when a developer leaves. We stabilise access and refreshes, inventory and document the estate, then help you choose the long-term model with no bias toward it being us. It suits organisations that have just lost their only Power BI person and need experienced hands quickly without committing to a permanent decision under pressure. If that is where you are, book a call and we can talk through your specific situation, or read more about how we work.

Summary

A Power BI developer leaving is disruptive, but it is recoverable, and it is more common than you might think. Secure access and credentials in the first week, inventory the estate in the first month, then choose between a permanent hire, consultancy support or fractional ownership based on what the work actually looks like. And fix the underlying gap, because the pain came from knowledge living in one head, not from the resignation itself. Handle it well and you come out of this with an estate that is better documented, better governed and no longer one resignation away from a crisis.