Low-code rested on a bargain: anyone can build, within limits. Microsoft has removed most of those limits, but many organizations still build and run their solutions as if the ceiling were there. Here is what changes now.
For a decade, Microsoft's low-code promise rested on a bargain that most organizations accepted without ever writing it down: anyone can build, within limits. A business analyst could ship a working app in a week. In exchange, that app lived inside a ceiling of canvas screens, standard connectors, time limits and a governance model designed to keep enthusiastic makers from hurting themselves or the data.
That bargain worked. It is also, quietly, over.
The ceiling did not just limit the apps. It shaped the operating model around them. Centres of excellence were set up to watch makers. Governance was designed to contain sprawl rather than to manage solutions the business depends on. Support teams learned to treat low-code as small and disposable, and anything serious went to a different team, a different stack and a much bigger budget.
Each of those structures made sense under the ceiling. Each of them assumes the ceiling is still there.
Several things arrived in quick succession. Code apps became generally available in early 2026, so professional React and TypeScript applications now run inside the same Power Platform governance as a canvas app; we wrote about what that unlocks in Breaking Through the Canvas Ceiling. The Dataverse MCP Server and MCP tools in Copilot Studio agent workflows reached general availability, so agents can read and act on business data through approved, governed connections. AI coding agents such as GitHub Copilot and Claude Code now help developers analyse, build and test in a fraction of the time. And in September 2026 Microsoft put its Copilot managed runtime into public preview, a governed home for apps built with Copilot, Copilot Studio and code.
The ceiling did not get higher. For practical purposes, it is gone.
Most organizations now run a large number of solutions built under the old limits. Many of them work around those limits in ways that were sensible at the time and fragile today: desktop flows driving virtual desktops, bots clicking through screens, scripts that outgrew the time they were allowed to run. The people who built them have often moved on, and there is rarely a single view of what exists, who owns it and how healthy it is.
None of these solutions can use the new capabilities on their own. They need to be brought across deliberately.
The instinctive response is to fix the app that hurts most. That removes a specific pain and changes nothing else. Without governance and lifecycle management, the next solution is built the old way, and the technical debt returns at the same rate it accumulated the first time. The ceiling's real legacy is not old apps. It is an old way of building and running them.
The organizations getting this right make three moves. They decide first: before anything is built, platform, security and business leads agree how the platform will be modernized, which capabilities each solution may use, where AI is allowed, and who owns the result.
They deliver on real work: solutions are built and released in their own tenant in a governed way, so that what was tested is what runs, starting where modernizing matters most.
And they defend what they built: every solution has a named owner and a reason to be looked at again before it breaks, so orphaned solutions stop accumulating.
Throughout, modernizing the platform leads. AI is what makes it faster.
Start with the framework. It is the cheapest step and the one that changes every decision after it. From there, real solutions delivered in your own tenant turn a strategy into working results, and give your team a way of building it can keep using.
This is the work behind our Beyond the Ceiling Power Platform modernization program. If your solutions were built under the old ceiling and are still living under it, talk to us.
Working through something like this? We talk shop without a pitch. Bring the problem and we will bring what we have learned in the field.
