Acumatica’s Classic UI is on its way out. With 2026 R2, the Classic interface disappears entirely, and every customization built for it needs a plan. In our June 2026 webinar for Acumatica partners, Samuel Robitaille and Garrett Rochell shared what we have learned from delivering Modern UI migrations on 2026 R1: real timelines, realistic effort estimates, and a recorded conversion demo showing exactly where the automated tooling stops and manual work begins.
Two deadlines, not one
Most partners are planning around a single date: the 2026 R2 release, expected late Q3 or early Q4 2026, when Acumatica removes the Classic UI switch entirely. 2026 R1 is the last release where Classic UI is available as a fallback, which makes it the natural validation window for migration projects.
There is a second deadline that lands earlier and catches many by surprise. On November 17, 2026, Chrome 158 removes XSLT support, the browser technology Classic UI relies on to render screens. When that happens, Classic UI stops loading in Chrome and all Chromium-based browsers, including Edge, Brave, and Opera. Customers still on 2026 R1 will hit this even though they never upgraded. Origin Trial and Enterprise Policy workarounds can extend support to August 2027, but Chromium’s own timeline makes clear they are a stopgap, not a fix. For most customers, waiting for 26 R2 is no longer a plan.
What changes for everyday users
Modern UI is more than a visual refresh. Navigation is rebuilt: side navigation, breadcrumbs, action bars, and search all behave differently. Personalization now saves per user rather than per role, so users can reorder fields, hide columns, and adjust layouts themselves, while admins lose some central control. Dashboards and pivot tables are converging, and performance is mostly faster than Classic but still uneven on some generic inquiries and heavy reports.
None of this is a blocker, but it means customers should get hands-on in a sandbox before go-live. The system will not look and feel the same on Monday after the upgrade as it did the week before, and short, focused training goes a long way.
Under the hood: why customizations need real work
Classic UI screens are ASPX markup with C# code-behind on the WebForms model, rendered server-side. Modern UI screens are HTML with TypeScript view models on the Aurelia framework, rendered client-side. Acumatica’s converter tool takes the ASPX file plus your custom DACs, graphs, field controls, and event handlers, and generates a TypeScript view model and HTML layout. The structure changes fundamentally, and that structural change is what drives the manual effort. Acumatica’s Modern UI development documentation covers the stack in depth.
The converter is a starting point, not a finishing tool
During the webinar we walked through a recorded, real conversion of two customizations: a standard Stock Items screen with four custom fields, and a fully custom warranty registration screen.
Both conversions required manual developer work, and the failure modes are instructive. On the standard screen, the converter generated an internal label that did not match what the system expected. The tool reported nothing; the problem surfaced only as a validation error at publish, and the custom fields silently disappeared from the screen until a developer traced the mismatch and fixed it. On the fully custom screen, the package validated successfully with no errors, yet the grid did not render and an action button was missing because it lived on the server side, where the converter does not look.
Across our migration work the pattern repeats: grid columns come out reordered, fields land in sections that do not exist, buttons or entire sections get silently skipped, and complex screens can fail outright. A successful validation does not mean a working screen. Every converted screen needs manual review and testing.
Sizing the work: a four-bucket triage
Effort is driven by the customer’s customization profile, not their starting version. We sort every screen in a tenant into four buckets:
| Bucket | When | Effort |
|---|---|---|
| Keep as-is | Standard screen, no customizations. Converts automatically; only user training needed. | Zero developer hours |
| Convert with the tool | Fully custom, self-contained screen. Run the converter, clean up the output, test. | A few hours per screen |
| Rebuild | Heavily modified standard screen or obsolete custom screen the converter cannot handle cleanly. | A day or more per screen |
| Retire | Unused, redundant, or replaced by standard functionality. | Minimal, mostly sign-off |
As ballparks: a custom screen through the converter typically takes a few hours including cleanup and testing. A modified standard screen runs from a couple of hours to a day, since the converter struggles most with this bucket and the work is manual extension files in TypeScript and HTML. Heavily customized screens can take a day or more each and are sometimes cheaper to rebuild than to convert. Full ISV package recertification is a project of its own, potentially weeks depending on the package. These are ranges; a per-tenant assessment turns them into a defensible estimate.
Do not forget automated tests
If a customer runs automated UI tests or a CI pipeline against Acumatica, the migration has a second workstream that most upgrade quotes miss. Modern UI screens have a different element structure, so existing UI wrappers stop matching the new screens and tests fail even though nothing is functionally broken. Test SDK wrappers need full regeneration, and suites with custom extensions and helpers require significant manual validation. Scope it, price it, and timeline it as its own project, and have that conversation before the upgrade kicks off.
Three things to tell your customers now
- The deadline is real. Classic UI ends with 2026 R2, and no instance can switch back after that. Every tenant moves to Modern UI either as a planned project or by default at the next upgrade.
- Daily users will notice changes. Navigation, personalization, dashboards, and layouts behave differently. Most changes are improvements, but every team needs short, focused training before go-live.
- Customizations need a migration project. Every custom screen, modified standard screen, and third-party package was built for Classic UI. Each needs review, conversion, and testing, planned and priced before any code is touched.
How Sprinterra helps partners
Sprinterra is an Acumatica ISV and Development Service Provider, in the ecosystem since 2013 and winner of the 2026 Acumatica Development Excellence Award. We have already delivered Modern UI migrations on 2026 R1, and we plug into partner teams in four ways: per-tenant migration assessments with a sized plan and pricing within one to two weeks, white-label development under your VAR brand, conversion of custom screens, modified standard screens, and ISV solutions, and autotest migration including Test SDK wrapper regeneration and regression suite rebuilds.