Inheriting a Power Platform App: Audit and Maintenance

The scenario plays out every month in an SME somewhere. A Power Apps application handles leave requests, or quotes, or quality checks. It was built by an apprentice, an enthusiastic colleague or a contractor, two years ago. That person has left. This morning a Power Automate flow failed, nobody knows why, and the only documentation is a notes file on a OneDrive nobody can access anymore.

Nothing dramatic, as long as you do not start tinkering. An inherited application is taken over with a method: a short audit, a clean handover, then Power Platform application maintenance with a name, a channel and a response time.

The audit: what we look at

A few days are enough for an application of normal size and its flows. During the audit, nothing gets rewritten; we look.

1. Inventory: the applications, the flows, the environments, the SharePoint lists or Dataverse tables, the Power BI reports that depend on them. There are often surprises: the leave application has three flows, including one nobody had seen.
2. Owners: who owns each object, who can modify it, who is co-owner. An application whose only owner is a disabled account is a time bomb.
3. Connections: every flow runs on someone's connections. If that someone has left, their connections stop working along with their account, and the flow stops. It is the number one cause of the failures we get called in to fix.
4. Licences: does the application use Dataverse or a premium connector? Does everyone have the right licence, or was it running on a free trial?
5. Weak points: hard-coded identifiers, a SharePoint list approaching 5,000 items, unreadable formulas, flows with no error handling, no solution and no backup.

The audit ends with a report of about ten pages, with a rating per item: green, watch, fix soon.

Document, hand over access, monitor the flows

Minimal documentation fits on one page per application: what it is for, who uses it, where the data is, which flows depend on it, which connections and which accounts, what breaks if a given element changes. Nothing more. A fifty-page document is never read and never updated.

Handing over access follows one simple rule: never a single person. Two co-owners on every application and every flow, one of them in IT. The connections of critical flows are moved to a dedicated service account, with a password managed by IT, so that the next departure breaks nothing.

Then monitoring: Power Automate failure notifications must land in a mailbox someone reads, not in the former colleague's inbox. A control flow that lists every morning the runs that failed the day before and posts them in a Teams channel takes an hour to set up. It stops you discovering a problem two weeks late.

The support channel and the roadmap

A maintained application has an address. A Teams channel or a mailbox where users report a problem, an announced first-response time, and an incident log with resolutions. That is exactly what our Power Platform maintenance offer covers: a monthly retainer, response times guaranteed by contract, a senior consultant who knows your application.

The roadmap is a list, reviewed every quarter: what users ask for, what the audit flagged, what Microsoft changes (a connector being retired, a limit that moves). We prioritise, we price, we deliver in small batches. An application that does not evolve dies slowly; an application that evolves without a plan breaks fast.

When rebuilding is the better option

Sometimes the audit concludes that the application should not be repaired. The signals that never lie:

• The data lives in an Excel file on someone's personal OneDrive, and the application reads that file.
• The business logic is spread across the application, six flows and two Excel formulas, and nobody can say which does what.
• Every fix breaks two other things.
• The need has changed: the application covers 40% of what the team actually does, and the rest has gone back to paper.

In that case, we keep the application alive while we rebuild on a clean foundation, with the same scoping as for a new application: see our method and the fixed-price build offer. The decision rule is financial: if the estimated cost of the fixes exceeds half the cost of a rebuild, we rebuild.

An inherited application is not a problem, it is a poorly documented asset. An initial assessment, included in our managed services, tells you what you really own and what needs securing first. The simplest starting point is a thirty-minute call to describe what is running on your side.