Power Platform project rescue services
Senior US-based engineers take over a half-finished or failing Power Apps, Power Automate or Dataverse build that somebody else started. We read the artifact first — the screens, the flows, the connections they run on, the data underneath and who owns each piece — and hand you a written verdict on what is salvageable before anyone commits to a fix. Then one fixed price for the takeover, typical delivery in 2–4 weeks with 30 days of hypercare.
Representative dashboard — sample data
What you get
Starting from somebody else's half-finished artifact is a different job from starting from nothing. The first week is archaeology, not design — and the archaeology is what makes the price honest.
We open the app, the flows and the data layer and report what is actually there, not what the original proposal said would be there. The assessment is a document you keep, and it is written to be readable by the person who has to approve the next spend.
Which account owns each app and flow, which connections they authenticate through, and what stops working the day that account is disabled. On a build whose author has already gone, this is usually the finding that explains the failure everyone is arguing about.
Every screen, flow and table gets one of four answers: keep it, repair it, finish it, or rebuild it. Nothing is carried forward out of sunk-cost loyalty, and nothing is thrown away because rewriting is easier for us than reading.
The defect list is closed before any new scope is entertained. A rescue that adds features on top of an unresolved data problem is the second failed project, and it is the one the business remembers.
How the thing works, what each flow is for, where the data lives, which decisions were deliberate and which were accidents we chose to leave alone. Written during the work rather than promised at the end of it.
Ownership moved to accounts that will still exist next year, a walkthrough for whoever inherits it, and 30 days of hypercare behind the handover. The measure of a rescue is that you do not need to buy another one.
How it works
The app and its screens, every cloud flow and the connections behind it, the data layer, the environment and solution structure, and the ownership records. We also read what was originally agreed, because the gap between promised and delivered is half of what you are trying to settle.
A written assessment: what works, what is broken and why, what is missing, and a component-by-component recommendation to repair, finish, rebuild the data layer, or rebuild. If starting again is genuinely cheaper, that is what the document says. The fixed fee follows the verdict, not the hope.
The agreed list worked through in your own tenant, tested against real data with the people who will use it, ownership reassigned, documentation written, and a named internal owner walked through the result — with 30 days of hypercare after go-live.
A normal engagement starts with a requirement and an empty environment. This one starts with an artifact that already exists, that somebody else designed, that is running against live data, and that at least one person in your organization has already defended in a meeting. The unknown is not what to build; it is what is already there, and no honest price can be quoted before that has been read. So the work is split: a scoped assessment phase first, a fixed-fee takeover second, and a documented recommendation in between that you own whether or not you continue with us.
Reading is a real phase because Power Platform hides its state in several places at once. An app lives in an environment, and Microsoft's overview of Power Platform environments (opens in new tab) explains why that matters: an environment is the boundary for data, and an app can only reach data sources deployed alongside it. Whether the work was packaged as a solution decides whether it can be moved at all, which is the point of Microsoft's application lifecycle management guidance (opens in new tab) and its companion introduction to solutions as the unit of transport (opens in new tab). And the tenant-wide inventory in the admin center (opens in new tab) is where the ownership truth lives, which is frequently different from the ownership everyone assumed.
Four adjacent services touch this ground, and the distinction is worth two minutes because buying the wrong one wastes a month. Power Apps consulting and Power Automate consulting are greenfield: a requirement, a blank environment, a design conversation, a build. Rescue inverts that. There is no blank environment, the design conversation already happened without us, and the first deliverable is a reading of somebody else's decisions rather than a proposal of our own. If your assessment concludes that nothing meaningful survives, the honest answer is that you do not have a rescue — you have a build, and it is scoped as one of those two engagements at a build price.
Our SharePoint support and maintenance service is the steady-state end of the same spectrum: something that works, kept working — small changes, questions, the occasional break, delivered as ongoing care with no end date. This page is the opposite shape. It is a one-off intervention on something that does not work, with a defined finish line, and its success condition is that the engagement ends. A rescued build is a perfectly good candidate for that support arrangement afterwards, which is a sensible sequence rather than an upsell — and for a rescued app specifically, the equivalent is our Power Apps support and maintenance services, which keep a working app working once the rescue has ended. A rescued report estate has the same next step in our Power BI support and maintenance services.
And Power Platform governance consulting services are the aftercare that stops this happening twice. Governance is prevention: an environment plan, connector data policies, maker permissions, a real inventory, and a Power Platform step in your offboarding checklist so the next departure does not orphan another app. Rescue is what you buy when prevention was skipped. Most clients who go through a takeover ask about governance in the closing session, and it links forward naturally from here rather than competing with it. One distinction catches people out on the way in: if the thing that stalled is the project rather than a piece of software — no owner on the tasks, milestones that moved without anyone noticing, a tracker that stopped being true — then there is no broken artifact to assess, and what you want is a place to run projects from, which our SharePoint project management system build delivers. How the fixed fee is set for any of these, and what is locked down before work starts, is spelled out in our fixed-fee process.
Failed low-code projects fail in a small number of recognizable ways, and the symptom people describe on the phone is rarely the cause. The table below is the pattern library we read against; your assessment is the filled-in version of it, with a named component against every row.
| What people describe | What we usually find underneath | What the assessment checks first |
|---|---|---|
| It works for the person who built it and nobody else | Sharing was never configured, or the app reads a data source the rest of the team has no permission to open | How the app and its flows are shared, the permissions on the underlying list or tables, and whether each connection is personal or shared |
| It was fine in testing and falls over on real data | Queries the platform cannot push down to the data source, so the app only ever sees the first page of records | Delegation warnings in the app and the record limit in force — Microsoft's delegation overview (opens in new tab) sets out which operations survive at scale — plus whether the list has passed SharePoint's 5,000-item view threshold |
| The build stopped when the developer left | Apps and flows still owned by a deprovisioned account, running on connections tied to it | The tenant inventory: every app, flow and agent with its owner, its environment and when it last ran, checked against who still works there |
| Nobody can get it from test into live | The work was built directly in an environment instead of being packaged, so there is nothing transportable to move | Whether solutions exist at all, what is unmanaged, and how much of the build can be carried across as-is rather than rebuilt in place |
| The scope grew until nobody would sign it off | An open-ended engagement with no written definition of finished, re-negotiated verbally every few weeks | What was agreed, what was delivered, and the gap between them — written down once, in language a non-technical approver can act on |
| It runs, but the business does not trust the numbers | The same calculation implemented in the app, in a flow and in a spreadsheet, with no agreement on which one is authoritative | Where each rule lives, which copy is correct, and what it would cost to have exactly one of each |
Two mechanics are worth understanding before the readout, because they explain a disproportionate share of stalled builds. First, ownership is not a label. A canvas app has an owner and any number of co-owners, and Microsoft's guidance on sharing a canvas app (opens in new tab) is where the difference between using an app and being able to edit it is defined — a build with exactly one owner who has left is a build nobody can change. Second, cloud flows run on connections belonging to a named account, so disabling that account takes the automation with it, regardless of who the business thinks owns the process. Microsoft's reference on the types of flow (opens in new tab) is a useful map of what you may be inheriting. One practical consequence: cloud flow run history is retained for 28 days, so a failure from last quarter cannot be read back after the fact. If a flow is failing intermittently, the assessment is better run while it is still failing.
The assessment ends in one of four recommendations per component, reached by estimating both paths rather than by instinct. Salvaging work has real value, and so does admitting when it has none. The distinction is what you are paying the first phase to establish.
| Verdict | When we reach it | What the takeover then involves |
|---|---|---|
| Repair | The design is sound and the failures are specific — a delegation problem, a broken connection, a permissions gap, an error path nobody handled | Targeted fixes against a numbered defect list, each tested and signed off individually, with the rest of the build deliberately left alone |
| Finish | What exists is right but incomplete: screens missing, a flow that only covers the happy path, no handover, no documentation | The remaining scope written down and closed at a fixed price, continuing the existing artifact rather than restarting it |
| Rebuild the data layer | The app is salvageable but what it sits on is not — a flat list where relationships are needed, or no security model where one is required | The data layer rebuilt in Dataverse or a restructured SharePoint design, with the existing screens and flows repointed at it |
| Rebuild | Repair would cost more than starting again, or the platform choice was wrong for the requirement in the first place | We say so in the assessment, in writing, before you spend anything on a fix — and the replacement is scoped as a normal build at a build price, not dressed up as a rescue |
Very little, and none of it requires cooperation from whoever built the thing. We need a Microsoft Entra account in your tenant with enough rights to read the Power Platform estate — the tenant-wide inventory needs an administrator or reader role held by somebody on your side — along with access to the environment the build lives in and, where it exists, the original statement of work. That last item is optional. Plenty of rescues arrive with no paperwork at all, and the assessment simply records what is there instead.
What we do not need is a meeting with the outgoing party, an agreement about whose fault it was, or a decision from you about repair versus rebuild. That decision is the output of the phase, not an input to it. We would rather you arrive undecided than arrive committed to a conclusion the evidence does not support.
The table shows scope and timeline rather than prices, because an honest number requires seeing how large the build is, how much of it survives the verdict, and whether the data layer has to be rebuilt underneath it. The fee for each phase is fixed in writing after a free consultation.
| Phase | Scope | Typical timeline | Fee |
|---|---|---|---|
| Phase 1 — independent assessment | A full read of the existing build: screens and their logic, every cloud and desktop flow with its connections and failure history, the data layer and its permission model, environment and solution structure, ownership and licensing, and the gap between what was agreed and what exists. Returned as a written verdict per component, plus a numbered defect list. Can be bought on its own | About the first week | Fixed fee — scoped after your free consultation |
| Phase 2 — stabilize and take over | The agreed list worked through in your tenant: defects closed one at a time against real data, ownership reassigned to accounts that will still exist, connections rebuilt where they were tied to a departed user, missing scope completed, and the build packaged so it can be moved between environments in future | Weeks 2–3 | Fixed fee — scoped after your free consultation |
| Phase 3 — document and hand over | How it works and why, written for the person who inherits it; the data model and flow inventory recorded; a named internal owner walked through the result; and the open questions we chose not to answer listed honestly as future work rather than buried | Week 4 and close-out | Fixed fee — scoped after your free consultation |
Everything produced is yours from the first day. The assessment, the defect list, the rebuilt components and the documentation all live in your own Microsoft tenant, never in ours, and the assessment stays useful even if you take it to somebody else. Nothing is deleted, reassigned or rebuilt without your approval of the list first. If you have been burned by an open-ended engagement, our comparison of fixed-fee versus hourly consulting sets out exactly which risks a fixed price moves off your side of the table.
The usual fit is an organization of roughly 20 to 200 people that commissioned a Power Apps or Power Automate build — from a contractor, an agency, or an enthusiastic internal maker — and now has something that half works, a stakeholder who has stopped answering, and a budget conversation nobody wants to open. The trigger is generally one of four: the builder left or was let go; the deadline passed twice; the app broke under real volume; or an internal champion moved on and took the only knowledge of it with them.
It fits badly in two cases, and we would rather say so during the consultation than after the invoice. If the existing work is a genuine prototype — a weekend experiment nobody deployed — there is nothing to rescue, and a normal build is cheaper and better. And if what you need is somebody on call overnight with a contractual response time, that is a managed service provider rather than a project team. Neither answer earns us a fee, which is rather the point of putting the assessment first.
Related services
The aftercare that stops it happening twice: environment plan, connector data policies, a real inventory, and a named administrator.
The greenfield build, for when the assessment concludes that starting again is genuinely the cheaper answer.
Steady-state care once something works again — small changes, questions and breaks, without an open-ended retainer.
Further reading
Hand-written guides from our article library.
Which risks each model puts on which side of the table, and why an open-ended rate card is how scope quietly escapes.
The scope drivers behind a build quote, Microsoft's published license rates, and what continues to cost money after launch.
What the rights in your existing seats already cover, and the exact point at which a flow crosses into a paid tier.
FAQ
Yes, it is a phase you can buy on its own. We read the app, the flows, the connections, the data layer and the ownership records, then hand back a written verdict on each component: repair, finish, rebuild the data layer, or rebuild. You own that document whether or not we do the work.
That is the usual case, and it needs no cooperation from them. Everything we need lives in your own tenant, provided somebody on your side holds the administrator role. We read what is there rather than what the original proposal claimed, and the assessment records the gap between the two.
By estimating both and comparing them honestly. Repair wins when the design is sound and the failures are specific. Rebuild wins when the data layer cannot carry the requirement, or when the platform choice itself was wrong. We put the recommendation in writing before you spend anything on a fix.
Common, and survivable. Apps and flows keep running under a departed account until a credential expires. We list them from the tenant inventory, reassign ownership to accounts that still exist, rebuild the connections under a service account where appropriate, and record what changed.
No. Support is steady-state care of something that already works: small changes, questions, the occasional break. This is a one-off intervention on something that does not work, with a defined end. A rescued build can move onto support afterwards, but the two are scoped and priced separately.
Typical delivery is two to four weeks after the assessment, with the date written into your scope. The fixed fee reflects the defect list the assessment produced, how much of the build survives the verdict, and whether the data layer has to be rebuilt underneath it. One price, agreed before work starts.
Book a free consultation
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.