Acumatica customers still using Classic UI have two separate changes to plan around.
On 17 November 2026, Chrome 158 is scheduled to disable XSLT in stable releases. Acumatica says unpatched Classic UI screens depend on that browser feature and may stop loading in Chrome and Edge.
With Acumatica 2026 R2, Classic UI itself can no longer be enabled.
Both changes point towards Modern UI. Each has its own deadline and its own work.
The browser deadline is a compatibility problem
Chromium is removing native XSLT support from Chrome because of the security and maintenance cost of the ageing browser implementation. Microsoft Edge shares the Chromium engine, so the change affects it as well.
Acumatica has released fixes that allow supported Classic UI environments to continue loading after the browser change. Its current guidance covers Acumatica 2025 R1 and later. Environments on 2024 R2 or earlier need an upgrade to receive that fix. Acumatica identifies Firefox as a temporary workaround.
Verify the exact build. Acumatica confirmed, for example, that the fix was merged into the 2025 R2 SP1 patch released on 3 July 2026, build 25.201.0213.5. SaaS and private-cloud environments may also receive or apply patches differently.
Before relying on the fix, establish:
- the exact Acumatica build in production
- whether the site is SaaS or privately hosted
- how and when the relevant patch will be applied
- which users and workflows still open Classic UI screens
- whether managed browsers introduce a separate deployment timetable
Applying the fix keeps Classic UI available on that supported version. Modern UI migration and 2026 R2 preparation remain separate work.
Sources: Acumatica’s Chromium XSLT action notice and Chrome’s XSLT removal timeline.
The 2026 R2 change is a workflow migration
Acumatica states that Classic UI cannot be enabled in 2026 R2 or later under any circumstances. Customers on supported earlier versions can continue using Classic UI under the normal support policy, but an upgrade to 2026 R2 removes the fallback.
Acumatica describes this as an interface change: existing records, transactions, configuration and history remain. Most business-logic customisations should also remain unaffected solely because the interface changes.
UI-specific work needs closer attention:
- customised screens and controls
- ISV products with their own user-interface elements
- processes that rely on behaviour which differs between Classic and Modern UI
- workarounds that currently involve switching back to Classic
- training and support material built around the old screens
A screen opening successfully is only the first check. Users need to complete the actual sequence of work: filtering, editing grids, uploading files, entering dates and times, moving between records, processing batches and recovering from validation errors.
Source: Acumatica’s Classic UI deprecation announcement and FAQ.
Inventory the work before estimating the migration
Start with the workflows the business depends on and list the screens, customisations and ISV components inside them.
For each critical workflow, record:
- whether the screen is standard, customised or supplied by an ISV
- who performs the work and how often
- which behaviours need to remain equivalent
- which known Modern UI issues or different behaviours affect it
- who can decide whether the result is acceptable
This produces a testable scope. It also prevents a quiet Classic screen used once a month for an important close or exception process from being discovered after the upgrade.
When that scope crosses custom screens, ISV products and upgrade planning, AISI can help turn it into an implementation plan through our Acumatica services.
Use the patch window to keep migration moving
The XSLT compatibility fix creates room to plan while Modern UI testing continues.
A sensible sequence is:
- confirm the production build and patch path
- test representative Classic UI screens with XSLT disabled before the browser deadline
- inventory UI-specific customisations and ISV dependencies
- run important workflows in Modern UI with the people who perform them
- record blockers, workarounds and ownership
- plan the 2026 R2 upgrade only when the evidence supports it
The browser fix and the interface migration solve different problems. Treating them as one task risks either unnecessary panic or a false sense that installing a patch completed the move.