Clients ask me a version of this question constantly now: "should our new customizations be Modern UI or classic?" It's a more nuanced question than "which is newer," because the two aren't just different presentation technologies for the same underlying platform — they have genuinely different development ergonomics, and picking wrong for a given screen shape costs real time. Here's the comparison I actually give, grounded in what changes and what doesn't.
What stays identical regardless of which UI you choose
Get this out of the way first, because it's the most common misconception: the graph, the DAC, the event pipeline, BQL, the cache — none of it changes based on UI choice. A PXGraph with RowPersisting validation and a custom action behaves identically whether a classic ASPX screen or a Modern UI TypeScript screen sits in front of it. This is deliberate architecture, not an accident — Acumatica separated presentation from business logic specifically so the platform could introduce Modern UI without forcing every existing customization to be rewritten. If your work is primarily graph and DAC extensions, "Modern UI vs classic" barely affects you at all.
Where the development experience genuinely diverges
| Aspect | Classic (ASPX) | Modern UI (TypeScript) |
|---|---|---|
| Screen definition | ASPX markup + Screen Editor, WYSIWYG-adjacent | TypeScript view classes + separate layout markup, hand-authored |
| Build step | None — ASPX compiles at request time / with the assembly | npm/webpack build required to produce browser bundles |
| Iteration loop | Publish customization, refresh browser | Watch-mode build during dev, still requires publish for deployment |
| Client-side validation | Minimal, mostly server round-trip driven | First-class client validators alongside server rules |
| Custom controls | Custom ASPX user controls, older and clunkier extension model | TypeScript component classes, cleaner extension surface |
| Layout flexibility | Table-ish, ASPX-constrained | Web-component based, more flexible responsive behavior |
| Learning curve for a .NET-only developer | Low — it's ASP.NET Web Forms-adjacent | Real — needs genuine TypeScript/frontend competency |
| Mobile rendering | Separate MSDL-driven mobile screens entirely | Same — Modern UI doesn't unify mobile presentation either |
The decision usually comes down to team skillset, not screen requirements
In my experience the deciding factor is rarely "which technology can do X" — both can build essentially any screen shape Acumatica supports — it's whether the development team has genuine TypeScript and modern frontend experience. A developer coming from a decade of ASP.NET Web Forms and classic Acumatica screens can be productive in Modern UI, but there's a real ramp-up period, and rushing a team onto Modern UI for a client deadline without budgeting that ramp-up is how projects slip. Conversely, a team with strong frontend chops finds Modern UI noticeably more pleasant to work in — the component model is more composable, and things like conditional validation and dynamic field states are less awkward to express than in ASPX's more rigid model.
My default recommendation for genuinely new screens on a current-version instance is Modern UI, because it's where Acumatica's own investment is clearly going and because the client-side validation and control model are simply better once a team is past the learning curve. But migrating an existing, working classic screen to Modern UI purely for its own sake is rarely worth it — extending a classic screen with a graph extension and a screen editor change is cheap and low-risk; rewriting its presentation layer in Modern UI for no functional gain is cost with no corresponding client benefit, and I say so explicitly when a client suggests it without a concrete driving reason.
Mixed instances are the norm, not a problem to fix
A worry I hear from clients: "won't having some classic screens and some Modern UI screens look inconsistent or be a maintenance mess?" In practice, no — Acumatica's own stock screens are a mix (newer modules and updated screens trend Modern UI, older stable ones remain classic), and the platform handles both coexisting without friction. I don't treat "convert everything to one UI framework" as a goal worth pursuing on its own; I treat each screen decision independently, based on whether it's new work, whether it needs Modern UI's validation/control advantages, and what the team can realistically deliver well.
Wrapping up
The graph and DAC layers are identical either way — this is a presentation-layer decision only, and a narrower one than it first appears. Default to Modern UI for genuinely new screens if the team has or can build real TypeScript competency; keep extending classic screens rather than migrating them without a concrete reason; and don't treat a mixed classic/Modern UI instance as a problem, because it isn't one — it's the normal state of a platform mid-transition, same as most enterprise software going through the same shift.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.