By Michael Branson, Founder/COO, i3solutions

Quick answer. If your Power App is failing, its rebuild statement of work names seven things: the failures to close, the rebuild evidence, the data carried over, the licenses, a managed path to production, acceptance criteria, and phases ending on named events. If the process is not yet agreed, write discovery first.

If a business unit’s Power App loses a submission on a Friday, it has stopped being a convenience and become a record-keeping failure. The statement of work (SOW) for the rebuild is where that failure either gets a written definition of fixed or gets rebuilt into new screens. This checklist covers what that document has to name, clause by clause, for an app that is already running in production and already failing.

Why a Rebuild Statement of Work Differs From a Build Statement of Work

If you start from a new-build template, it will miss what a rebuild has and a new build never does: a live app with users, records and defects. A rebuild statement of work names seven things before it names a single screen: the failures it is closing, the decision to rebuild and its evidence, the data it carries over, the licenses the new design needs, where the new app is built and how it reaches production, what counts as accepted, and the event that ends each phase. The delivery model for a new Power Platform build is set out in Enterprise Power Platform Development & Implementation Services for Governed Operations; the clauses below are the ones a rebuild adds, because the current app is the baseline every one of them is written against.

The Failures the Rebuild Must Close

If the current app loses records when people submit, write that down as a finding before anyone designs a screen. The current-state findings clause lists each defect as it was observed: records lost on submit, logic edited directly in production, one person holding the only maker and admin rights, a flow that fails without telling anyone. Each finding then reappears in the acceptance clause as an item the rebuild must show closed. A finding that does not reappear there is a failure the new app is allowed to repeat, and no one will have agreed to that in writing.

The Rebuild Decision and the Evidence Behind It

If the decision to rebuild is already made, the SOW records it and does not argue it again. It names the path chosen and cites the discovery finding that decided it. Whether a failing app should be fixed or rebuilt is covered in Power Apps for a Business-Critical Enterprise Application, and the wider choice of modernization path in Application Modernization Decision Framework: Six Paths. The definitions a scope rests on come from Power Apps Discovery: What to Define Before Scoping a Build, and that output is the input to this document.

If the evidence line is vague, the rebuild inherits the vagueness. A finding strong enough to decide a rebuild is specific. Microsoft’s delegation article, last updated January 13, 2026, states: “When a query is nondelegable, Power Apps gets the first 500 records from the data source and then runs the actions in the query.” An app whose main screen filters a growing list with a formula that cannot be delegated stops finding records past that limit, so the evidence line names the formula, the data source and its record count on the day it was read, as logged in the discovery report. How to read that exposure before a scope is written is covered in the Delegation Exposure section of the discovery page linked above.

Data Carried Over and the Licenses the New Design Needs

If the current app has lost or duplicated records, the data clause matters more than the screens. It names every table, list and attachment store that carries over, who counts the records before and after the move, and who signs the reconciliation. Records already lost are a business decision: the clause says whether they are rebuilt from email, printed copies or another system and who does that work, or states in writing that they are not. i3solutions selects Dataverse over SharePoint as the primary relational store when a client needs scalable high-volume transactional data, and holds application secrets in Azure Key Vault.

If the rebuilt app will run on Dataverse or premium connectors, the licensing clause names the license each user role needs. The managed path to production adds a second licensing line. Microsoft’s pipelines overview, last updated January 13, 2026, states: “Licenses granting premium use rights are required for all managed environments.” Name the license for each role and for each environment in the SOW, and confirm each entitlement with whoever holds your Microsoft agreement before signature.

Environments and ALM: The End of Editing in Production

If the current app was edited directly in production, the environments clause is the one that stops it happening again. It names a development environment, a test environment and a production environment, and it says changes reach production only as a managed solution. Microsoft’s solution concepts article, last updated January 29, 2025, states: “Managed solutions are deployed to any environment that isn’t a development environment for that solution.” It also states: “You can’t edit components directly within a managed solution.” Microsoft’s environments overview, last updated September 1, 2026, says: “Sandbox environments are used for development and testing, separate from production.”

If settings differ between environments, the clause names how they move. Microsoft’s environment variables article states: “Environment variables enable the basic application lifecycle management (ALM) scenario of moving an application between Power Platform environments.” Its connection references article states: “A connection reference is a solution component that contains a reference to a connection about a specific connector.” Both were last updated January 9, 2026. The clause also names a deployment pipeline and who approves each release. Microsoft’s pipelines overview also states: “We recommend that you always deploy managed solutions to nondevelopment environments.” Last, the clause names who holds maker and admin rights in production after go-live, by role, so one person never again holds the only keys. The managed path itself is covered in Power Platform ALM: Maker Solution to Managed Production.

i3solutions runs client Power Platform work on a multi-tenant Center of Excellence model with separate Dev, Test, UAT, and Production environments promoted through managed solutions. i3solutions delivery includes ALM practices with Power Platform pipelines or Azure DevOps integration, environment separation strategies, and change control processes. i3solutions governs client Power Platform tenants with the Center of Excellence Starter Kit, tenant-level and environment-level DLP policies, and managed environment controls. Microsoft guidance dated May 7, 2026 says the Center of Excellence Starter Kit is no longer actively maintained, that it remains available, and that its core capabilities are part of the Power Platform admin center.

Acceptance Criteria Written Against the App You Already Have

If no one wrote down what working means, the rebuild can never be declared done. Write acceptance against the current app, in three parts:

  1. Parity. Every recorded behavior of the current app (each screen, rule, notification and output it produces) is either reproduced or retired in writing, with the business owner’s name beside each retirement in the parity inventory.
  2. Defects closed. Each finding from the current-state clause is shown closed in the test environment, on data shaped like production, and entered in the test log before user acceptance testing (UAT) signs off.
  3. The failure path. A criterion that is present and fails at test is logged, fixed and retested before the phase ends; the phase does not close on a waiver no one signed.

If parity and a named defect conflict, the defect wins: the rebuild does not reproduce a behavior the findings clause names as a failure. Build the parity list from the current app itself, its screens, formulas, flows and the records it writes, captured before the rebuild starts, so the list reflects the app people use and not the app someone remembers.

Timeline Benchmarks as Events, Not Dates

If procurement asks for timeline benchmarks, give it phases that end on events. Each phase ends on a named event: findings accepted, design signed, UAT passed, cutover done, parallel run closed, hypercare closed. Beside each event, name your own dependency as well as the vendor’s: the business owner who signs the parity list, the admin who creates the environments, the data owner who signs the reconciliation. The parties set a duration for each phase; a date with no event behind it is a benchmark no one can test. The one start-up figure this page gives is the publisher’s own: Senior Microsoft specialists from i3solutions typically embed in the client’s team within two to four weeks of engagement start.

Cutover and Handover From the Live App

If the old app stays open during cutover, records can land in both. The cutover clause names a freeze window for the old app, the moment of the final data cut, the condition for rolling back to the old app, written down before go-live, and whether the old app stays available read-only afterward. After hypercare, the handover clause names who owns the app, its environments and its support queue. Ownership after go-live is set out in Power Platform Support Model and Ownership RACI.

The Handover Test: A Second Person Ships One Real Change

If only the original developer has ever changed the app, a handover meeting does not prove the handover worked. The test that does: a second person ships one real change to production through the pipeline, and handles one real incident, while the original developer only watches and never touches the keyboard.

To run it, take a real change, not a rehearsal. The second person makes it in the development environment and releases it through the pipeline to production. If the second person stops at a step only the original developer can do, such as a connection or an environment role held in that person’s account, move it to a named owner and run the test again. The handover is finished when the test passes, and the handover clause names the second person who passed it.

When a Rebuild Statement of Work Is the Wrong Document

If one of these is true, write something else first:

  • One defect explains the failure. If a scoped fix closes it, the document is a fix task order with that defect as its only acceptance item.
  • The process is not agreed. Discovery comes first, because acceptance criteria cannot be written against a process the business has not settled.
  • Power Apps is the wrong platform for the load. The scope should not specify it; the signs are in When Power Apps Is the Wrong Choice: Enterprise Signs.
  • The current vendor stalled mid-project. The question is rescue or restart, covered in How to Rescue a Stalled or Failed Microsoft Modernization, before any new scope is written.
  • The app is near retirement with few users. A stabilization task order that closes the data loss is the lighter document and fits.

How i3solutions Writes a Rebuild Into the Statement of Work

If i3solutions writes the rebuild, the delivery structure is its own: i3solutions delivers through its Expert Delivery Model, a four-phase methodology (discovery, architecture, build, and knowledge transfer) with explicit exit criteria and delivery assurance at every handoff. i3solutions engineers work inside the client’s own tenant as Microsoft Entra B2B guest accounts with scoped Dataverse security roles, not from an i3solutions-owned tenant. i3solutions runs a governed Power Platform for a federal defense agency supporting roughly 10,000 personnel across about 180 locations, which works because it is governed, not despite it. Delivery is senior and US-based.

Key Takeaways

  • If you remember one rule: write acceptance against the app you already have, with every recorded failure named and shown closed.
  • A rebuild statement of work names the failures, the rebuild evidence, the data carried over, the licenses, the managed path to production, acceptance and phase-ending events.
  • Changes reach production only as managed solutions, which Microsoft says cannot be edited directly.
  • Phases end on named events with your dependencies beside the vendor’s; the parties set each phase’s duration.

Frequently Asked Questions

What acceptance criteria should a Power Apps rebuild SOW use?

If the app already runs in production, use three kinds: parity with every recorded behavior of the current app, reproduced or retired in writing; each observed defect shown closed in a test environment on production-shaped data; and a failure path, where a criterion that fails at test is logged, fixed and retested before the phase closes.

How should a rebuild SOW stop people editing the app in production?

If the current app was edited live, the statement of work names separate development, test and production environments and says changes reach production only as managed solutions. Microsoft’s solution concepts article states: “You can’t edit components directly within a managed solution.” The statement of work also names who holds maker and admin rights in production after go-live.

Who is responsible for the records the failing app already holds?

If records have been lost or duplicated, the statement of work names who counts the records before and after the move, who signs the reconciliation, and who decides whether lost records are rebuilt from other sources. The business owner makes that decision; the vendor carries out the move and the counts.

How do we put timeline benchmarks in the SOW without committing to dates we cannot defend?

If a date cannot be tested, it is not a benchmark. End each phase on a named event, such as findings accepted, design signed, user acceptance testing passed, cutover done, parallel run closed and hypercare closed, and list your own dependencies beside the vendor’s. The parties then set a duration for each phase.

When is a rebuild SOW the wrong document?

If one defect explains the failure, a scoped fix is the lighter document. If the process is not agreed, discovery comes first. If Power Apps is the wrong platform for the load, or the current vendor stalled mid-project and the question is rescue or restart, settle that before writing a rebuild scope.

Send the Facts Behind Your Power Apps Rebuild Scope

If you are drafting the rebuild statement of work, send the current app’s failure list, its data sources and the environments it runs in through the contact form. Those three facts are what the clauses on this page are written against. Contact a senior Power Platform architect

Sources