From PowerApps to production: when low-code stops scaling

Why PowerApps wins (when it wins)

PowerApps + Dataverse + Power Automate is the right answer when:

1. You're a Microsoft 365 tenant. The license is already in your plan.
2. IT will only sign off on Microsoft. (Common in regulated industries.)
3. The app's integrations are mostly Microsoft-native — SharePoint, Outlook, Teams, Dataverse, Power Apps.
4. The team that will maintain it is more comfortable with low-code than with TypeScript.
5. Volume is moderate — low thousands of operations per day.
6. The app is internal, not customer-facing.

When those conditions hold, PowerApps lets you ship in weeks what would take months in custom code. We have built dozens of PowerApps and we will continue to.

Where it stops scaling

The places where PowerApps starts hurting are predictable. We see the same five signals across clients.

1. Performance

A PowerApps canvas app loads its UI, its data, and its formula tree on every visit. As the app grows — more screens, more controls, more formulas — load time grows. Past about 3 seconds on commonly-used screens, users start complaining. Optimisation helps (delegation rules, formula simplification, fewer controls per screen) but there's a ceiling.

Custom code with a properly tuned backend hits sub-second response times effortlessly. PowerApps doesn't, at scale.

2. Business logic complexity

PowerApps formulas are spreadsheet-style. Power FX is more capable than 2020-era Excel, but it isn't TypeScript. Complex business logic — multi-step state machines, branching workflows with conditional side effects, complex validation rules — becomes a maintenance nightmare in formula bars.

The signal: you find yourself implementing the same logic across multiple screens because there's no good way to share it. Or your formula bar exceeds three lines for the third time.

3. No proper version control

PowerApps does have version history and source control via solutions + ALM. It's better than 2022. It's still not git with code review, branches, and CI.

For a one-person internal tool, that's fine. For a multi-person team shipping changes daily, the absence of real version control is a productivity tax that grows over time.

4. Customer-facing surface

PowerApps Portals (now Power Pages) exist for public-facing apps. They work for many use cases — partner portals, supplier portals, basic customer self-service. They struggle when you need:

• Custom design that matches your brand exactly.
• Server-side rendering for SEO.
• Custom auth flows (passwordless, SSO with non-Microsoft IdPs).
• Real performance: LCP under 2s, low CLS, mobile-first.

If your customer-facing app needs any of those, Power Pages isn't the right surface. Custom Next.js / Astro is.

5. Cost at scale

PowerApps per-app and per-user licensing is reasonable for moderate use. At scale — thousands of monthly active users, especially external users — the cost line crosses what equivalent custom-hosted infrastructure would cost, and keeps growing linearly.

For high-volume external apps, custom code's near-zero marginal cost per user beats PowerApps' per-user licensing once you cross the threshold.

The hybrid migration pattern

Whole-app rewrites of PowerApps to React are usually wasted effort. The right pattern is hybrid:

• Keep PowerApps for the workflows it handles well — internal forms, simple dashboards, Teams-integrated tools.
• Migrate the parts that hit ceilings to custom code — customer-facing portals, performance-sensitive screens, complex logic.
• Keep Dataverse as the system of record for both.
• Power Automate continues to handle the workflow / integration layer.

A typical migration looks like:

[Dataverse (system of record)] ← stays
        ↕
[Custom API layer (Cloud Functions or Cloud Run + Dataverse Web API)] ← new
        ↕
[Next.js customer-facing portal]  ← replaces Power Pages
[PowerApps internal admin tools]   ← stays
[Power Automate workflow layer]    ← stays

The custom API layer is the bridge. It exposes the same Dataverse data through a typed interface that the Next.js app consumes. PowerApps continues to read/write Dataverse directly.

The migration playbook

A six-step migration we have run multiple times.

1. Inventory the PowerApps surface

Identify every screen, every control, every formula. Categorise into:

• Keep in PowerApps — works fine, no migration needed.
• Wrap with API — keep the data model and Power Automate, move the UI to custom.
• Rebuild in custom — full UI + logic rewrite.

Most surfaces fall into category 1.

2. Identify the read/write boundary

What data does the migrating surface need? Map it to Dataverse tables, SharePoint lists, external systems. This becomes the surface area of the new custom API.

3. Build the API layer

Next.js API routes or Cloud Functions calling Dataverse Web API. Strict typing (Zod schemas). Auth via Microsoft Entra (the same identity provider PowerApps already uses).

4. Build the new front-end

Next.js + Tailwind + shadcn/ui (our default). Reads/writes via the new API. Shares Microsoft Entra auth with PowerApps so users SSO seamlessly.

5. Cutover in slices

Move one workflow at a time. Old workflow stays running in PowerApps until the new one is proven. Power Automate flows continue to run regardless of which UI invoked them.

6. Decommission what's done

Once a workflow is fully migrated and stable in custom, retire the corresponding PowerApps screen. Keep the Power Automate flows.

When NOT to migrate

Migrating costs time and money. Don't migrate when:

• The PowerApps surface works fine and users aren't complaining.
• The migration would take longer than the remaining useful life of the app.
• You don't have someone on the team who will own the custom stack.
• The reason for migrating is "PowerApps feels old" — that's not a business reason.

Stack we tend to reach for in the new layer

For broader Microsoft 365 + AI strategy, see Microsoft 365 + AI in 2026. For our take on the broader Microsoft Power Platform fit see the System Integration service page.

If you're hitting a PowerApps ceiling and want a feasibility review of migrating, drop us a note. We'll come back with a clear next step within a business day.