What it does

Canvas apps carry two control sets at once. Turn on Modern controls and themes and the modern set takes over the standard insert categories while the older controls move into Classic and Classic icons. Both render in the same app, on the same screen, in the same formula bar.

Key facts

• Coexistence is the supported state, not a migration step. There's no converter and no "upgrade all controls" action.
• The modern set has no equivalent for several classic controls, including Pen input, Camera, Barcode scanner, PDF viewer, Rich text editor, the chart controls, Power BI tile and Map. If you need those, you're using classic controls in a modern app.
• The classic set has no equivalent for Avatar, Badge, Header, Info button, Progress bar, Spinner, Tab list or Data Grid.
• Apply a modern theme while classic controls are present and Power Apps writes Power Fx formulas onto those classic controls' properties, referencing the theme's variables. It's a styling bridge, not a conversion.
• Microsoft is explicit that the visual result won't match exactly, because classic controls aren't built on Fluent v9.
• Classic themes are retired. To get them back you go to Settings > Updates > Retired > Keep classic themes.
• Property names diverge between the sets after the February 2026 modern control updates — FontColor versus Color, FontSize versus Size — so copy-pasting formulas between a classic and a modern control fails.

When to use / skip

Build new apps modern-first and accept classic controls where there's no alternative — a camera or a PDF viewer next to modern controls is normal and fine. Don't mix for cosmetic reasons: two visually similar buttons from different sets on one screen is the thing users notice and can't articulate. For an existing app, converting control by control is rarely worth it on its own; do it as part of a rebuild or a redesign, where you're touching the formulas anyway.

Configuration decisions

• Whether an app is modern-first with classic exceptions, or left entirely classic — and picking one per app rather than per screen.
• Where the exceptions are allowed: usually device capture, rich text, charts and Power BI content.
• Whether you keep classic themes turned on for an app that's mid-transition, accepting that you then can't use the modern theme picker.
• How you handle shared components and templates that were built classic and are now consumed by modern apps.

Gotchas

• Applying a modern theme to a screen full of classic controls writes formulas onto their properties. If someone later overwrites those properties by hand, the theme link is quietly broken for that control only.
• Focus and keyboard behaviour differs between the sets. An app that mixes them can have an inconsistent tab experience even when every TabIndex looks right.
• TabIndex and AcceptsFocus were removed from some updated modern controls. Accessibility patterns built on classic control properties don't port straight across.
• Nothing warns you that you're mixing sets. The insert pane groups them, but the tree view doesn't distinguish them.

Consultant notes

• Set the rule at the start of a build: modern by default, classic only for the listed exceptions, written into the app standards doc. Retrofitting consistency is the expensive version.
• When a client asks "should we migrate our apps to modern controls", the honest answer is usually no, not on its own. Tie it to a release that was already going to touch the screens.
• Demo both sets side by side early. Stakeholders form opinions about the visual difference quickly and it's cheaper to hear that in week one.
• Keep a list of which apps in the estate have the toggle on. There's no report for it and it changes what a maker sees when they open the app.

---

Revisit if Microsoft ships modern equivalents for the camera, pen or chart controls, or if a conversion tool ever appears.