Acumatica Modern UI Migration: Move Your Customizations Off Classic UI

Why This Has a Deadline: the 2026 R2 Classic UI Deprecation

Acumatica has been retiring the Classic UI in stages, and 2026 R2 is where that process finishes. Classic UI cannot be enabled in 2026 R2 or any later version. There is no configuration switch, no compatibility mode and no supported way to keep a Classic screen reachable once a tenant is on that build. Every customization that exists only as a Classic UI screen becomes unreachable at the moment of upgrade.

That is the whole deadline, and it is worth being precise about it, because a lot of the commentary around this has been overstated. If you are running a supported build today, your Classic screens are not going to fail on their own next quarter. The pressure comes from your upgrade calendar, not from a countdown clock inside the product. What you cannot do is upgrade to 2026 R2 with Classic-only customizations still in place and expect to sort it out afterwards. The migration has to land before the upgrade, or the upgrade has to wait.

The browser side of this, stated accurately

You have probably read that Chrome is removing XSLT and that this will make Acumatica Classic UI screens stop loading. The first half is true, the second half is not, and the distinction matters when you are deciding how urgent this is.

Chromium announced the removal of the browser's built-in XSLT engine - the same engine Classic UI leaned on to turn its server-rendered output into a page. Acumatica responded with platform patches for 2025 R1 and later builds that preserve Classic UI browser compatibility once that removal ships. On a patched, supported build, Classic UI screens keep rendering. Nobody with a current build is going to open Acumatica one morning and find blank screens because of the browser change.

What those patches do not do is give Classic UI a future inside the product. They keep it working on the versions that still have it. They cannot put it back into 2026 R2, where it no longer exists. So the honest version of the urgency argument is: the browser problem has been handled by Acumatica, and the deprecation has not been, because it is not a defect to be patched - it is the product moving on. Migration is required for anyone upgrading to 2026 R2. It is not required this week for anyone who is not.

The upside is worth naming too. Modern UI is where the platform's newer capabilities live: AI Studio, expanded anomaly detection and AcuChat are Modern UI features, and screens that are still on Classic cannot participate in them. Read our full breakdown of Acumatica 2026 R2 changes →

What Actually Changes: Classic UI and Modern UI Are Different Presentation Layers

The single most useful thing to understand before scoping a migration is that this is a presentation-layer change, not a platform rewrite. Your data model and your business logic are not moving. Your screen definitions are.

Classic UI defines a screen as ASPX/Web Forms markup - a page of Acumatica's own server controls, the PXControls family, laid out declaratively. That markup is turned into a rendered page through an XSLT transformation pipeline, and customizations frequently reach into that pipeline directly with XSLT fragments, or into the resulting page with JavaScript written against specific DOM element IDs.

Modern UI does none of that. Screen definitions are built on Aurelia with TypeScript: a component model, typed view models, and a declarative binding layer between the screen and the graph behind it. There is no XSLT step to hook into and no Web Forms control tree to manipulate. This is why the Modern UI should not be thought of - or described - as an ASPX framework. It is a different client architecture that happens to talk to the same xRP server code your customizations already extend.

That single fact is what makes migration tractable. The graph is unchanged. The DACs are unchanged. What has to be re-expressed is the part that was always about drawing the screen.

What Carries Across, and What Has to Be Rebuilt

In a typical engagement, the majority of the C# in a customization project ships to Modern UI untouched. The following components are normally reusable:

• DAC extensions and custom fields - your extended data model is the same data model. Custom fields defined through DAC extensions continue to exist and continue to be bound.
• Graph extensions - extension classes on the standard graphs carry across as written.
• Server-side business logic - validations, calculations, document flows, integration calls, anything that runs on the server as part of the graph.
• DAC attributes - selectors, defaults, formulas, dimension and period attributes, and custom attributes you have written yourself.
• Server-side PXActions and event handlers - actions and the row/field event handlers that back them remain the mechanism the Modern UI screen invokes.

The components that typically require review or redevelopment are the ones that are specific to how Classic UI drew the page:

• ASPX page layouts - the screen's structure, containers, tabs and field placement have to be expressed in the Modern UI screen definition rather than in Web Forms markup.
• Classic UI PXControls - Classic-only server controls have Modern UI counterparts with different capabilities and different configuration; the mapping is deliberate, not mechanical.
• XSLT fragments - any customization that injected or overrode XSLT has nothing to attach to in the Modern UI and is redeveloped.
• DOM-dependent JavaScript - scripts written against Classic element IDs or the Classic control tree break by construction; the behavior is reimplemented within the Aurelia/TypeScript model.
• Client-side grid customizations - custom column behavior, in-grid editors, client-side sorting or formatting hooks and grid event wiring are rebuilt against the Modern UI grid.
• Classic SmartPanels and other UI-specific behavior - SmartPanel dialogs, Classic-specific popups, and any interaction pattern that was implemented in the Classic client rather than on the server.

Development, Regression Testing, UAT and Rollback

Once the classification is agreed, the build runs screen by screen in a sandbox against a copy of your configuration - not a generic demo tenant, because a generic tenant hides exactly the interactions that cause problems. Server-side code that is being reused is left alone wherever possible; the work concentrates on the Modern UI screen definitions, the control mapping, and reimplementing client behavior in TypeScript.

Regression testing runs against the behavior you have today, not against the specification. For each migrated screen we test the document flow end to end, the actions and their side effects, validation and defaulting behavior, selectors and lookups, field-level security by role, and any integration that touches the screen. Screens that were reclassified as adapt or rebuild get the most attention, because that is where behavior can drift quietly.

UAT happens in your own test environment with your own users and your own data, on a defined window with a written scope of what is being signed off. We would rather hold a release for a UAT finding than ship a screen that technically works and is wrong for the way your team uses it.

Rollback planning is part of the deployment package, not a contingency we improvise. Every production deployment ships with the customization package versioned, a documented rollback path back to the previous package state, and a defined set of checks to run immediately after go-live. Where the migration is being paired with a 2026 R2 upgrade, we sequence the two deliberately, because after the upgrade Classic UI is no longer there to fall back to - which makes pre-upgrade validation on the migrated screens the point where problems have to be caught.

Deployment includes a customization inventory and upgrade notes, and 30 days of support after go-live.

Fixed-Price, Per-Screen Scoping

The quote is fixed and it is broken down per screen, with the audit classification next to each line. You can see what each screen costs, why it costs that, and what happens to the total if you retire it instead of rebuilding it. That structure exists because migrations are one of the easiest projects to lose control of on time and materials: the work is repetitive, the surprises are all in the individual screens, and an hourly engagement gives nobody an incentive to shrink the scope.

Practically, simple screen customizations land in the 1-3 day range. Complex custom modules with real business logic, multiple screens and integration surface typically run 2-4 weeks. Scope changes are requoted as a delta rather than absorbed quietly, and screens you decide to retire during the review come straight off the total.

You can also buy the audit on its own. Some clients want the inventory and the per-screen classification in order to budget for next year, or to give their own team a plan. That is a fine outcome and the deliverable is written to be useful without us.

Why Choose Envinse

How We Work