Acumatica Classic UI and Chromium XSLT: Patch and Test Before November 17, 2026
Verified October 15, 2026
Browser change has become an operational Acumatica risk. Chromium is removing XSLT support on November 17, 2026, and Acumatica has warned that Classic UI screens can stop loading in Chromium-based browsers without the applicable update. This guide gives administrators and operations leaders a focused patch, test, and communication plan – while keeping the larger Modern UI transition moving.
The deadline is a browser change with an ERP impact
On November 17, 2026, Chrome 158 is scheduled to stop supporting XSLT on Stable releases for most users. Acumatica's Classic UI relies on browser behavior affected by that change, so a Classic screen can fail to load in Chrome, Edge, or another Chromium-based browser even when the ERP server itself is healthy.
This is not simply a browser-standard discussion. A missed patch can interrupt order entry, approvals, reporting, and administration wherever a team still opens Classic UI screens. The immediate objective is continuity; the strategic objective is to reduce the remaining Classic UI footprint before the next upgrade decision.
Know which environments and users are exposed
Start with a short inventory, not an assumption. Record each production, sandbox, and tenant environment; its Acumatica version and build; the hosting model; the installed patch level; the browsers employees use; and the departments that still rely on Classic UI. Include administrators, power users, remote users, and third-party support teams.
Then identify the workflows rather than only the screens. A modern home page does not prove that a month-end dashboard, a legacy pivot table, a customized inquiry, a wizard, or an ISV add-on is safe. Ask each owner to name the transaction they cannot postpone for a business day.
Separate the browser patch from the Modern UI transition
The Chromium XSLT issue and the Classic UI retirement are related but different decisions. The current Acumatica notice says the updated fix is available through patches for 2026 R1, 2025 R2, and 2025 R1, while customers on 2024 R2 or earlier need a supported-version upgrade or a temporary non-Chromium workaround. Confirm the exact supported build and patch with Acumatica before making a production change.
A patch preserves near-term access to Classic UI in Chromium-based browsers; it does not eliminate the migration work. Acumatica's 2026 R2 documentation makes Modern UI the default, and Classic-only forms are warned for later retirement. Treat the patch as continuity protection while the organization completes its Modern UI plan.
Build a patch decision record
For every environment, capture the current version, build, patch candidate, maintenance window, backup point, owner, validation evidence, and rollback decision. SaaS and private-cloud customers can have different delivery responsibilities, so do not infer the outcome from another customer's model. Review the current Acumatica patch notice immediately before scheduling work.
This record gives finance and operations a reliable answer to a practical question: which workflows have been proven after the change, and which still need an alternate path? It also prevents a browser update from being treated as an undocumented production experiment.
Run regression tests that reflect real work
Test the browser and application together in a sandbox first. Use a supported Chromium browser at the current corporate version, then exercise the workflows identified in the inventory. Confirm login, navigation, data entry, save, release, approvals, attachments, printing or exports, dashboards, inquiries, and any custom actions that the team uses during a normal operating cycle.
For each test, preserve the expected result, actual result, timestamp, browser version, Acumatica build, and tester. Retest integrations and scheduled processes where a Classic UI setup page or manual exception path is involved. A successful landing page is not a regression test.
Give users a clear contingency plan
Publish one short notice before the production window: what is changing, when it occurs, which teams should test, where to report a problem, and what to do if a screen does not load. The Acumatica notice identifies Firefox as a temporary workaround in affected situations; use it only as a controlled contingency while the applicable patch or upgrade is completed, not as a silent long-term operating model.
Assign a named business owner and technical owner for each critical workflow. During the first business cycle after the change, monitor support tickets and confirm that exception queues, approvals, and time-sensitive operations continue normally.
Use the deadline to retire hidden Classic dependencies
The inventory will often uncover work that has not been modernized because it still works: custom forms, Classic dashboards, pivot tables, and legacy add-on screens. In 2026 R2, Classic UI is disabled by default, and the Beacon guidance specifically calls out forms and functionality that remain Classic-only as candidates for preparation.
Rank those items by operational risk, user volume, and replacement effort. Some may be converted, some redesigned, and some retired. Give each item an owner, target release, acceptance criteria, and a user-training date. That is a more durable response than waiting for the next upgrade window to expose the dependency.
A practical 10-business-day readiness sequence
Days 1-2: finish the environment and workflow inventory, confirm the current Acumatica advisory, and choose a patch candidate. Days 3-4: apply the patch in sandbox and execute the regression pack with business users. Days 5-6: resolve failures, validate customizations and ISV components, and document the production plan. Days 7-8: communicate the change and prepare the support rota. Days 9-10: apply the approved patch in production, run smoke tests, and track results through the next critical business cycle.
If the timeline is already compressed, reduce scope only after protecting the highest-risk workflows. Do not skip version confirmation, backup planning, or a post-change verification simply to meet the date.
Why XSLT removal matters to Acumatica Classic UI
XSLT, or Extensible Stylesheet Language Transformations, is a browser technology that can transform XML data into a format a user can view and work with. Chromium has deprecated the browser-side XSLTProcessor API and the XML stylesheet processing instruction, with removal planned for Chrome 158 on November 17, 2026. That browser decision is broader than Acumatica, but it matters to Acumatica because portions of the Classic UI depend on the browser behavior being removed.
The operational symptom can be deceptively simple: a Classic UI screen that worked yesterday may stop loading after a browser update. Users may initially report a blank page, incomplete rendering, or a screen that appears to hang. Because the server can remain available and Modern UI screens can continue working, the incident may look inconsistent across departments. That inconsistency is exactly why organizations need an inventory tied to real workflows rather than a generic statement that the site is available.
The change also demonstrates an important dependency-management lesson. ERP continuity depends not only on application code and infrastructure but also on browsers, identity services, document engines, operating systems, and third-party components. A mature readiness plan records those dependencies, assigns ownership, and tests them together before a vendor deadline becomes a production outage.
Understand the October 2026 change before the November deadline
Acumatica's original guidance focused on Chromium's planned November removal. The October 1, 2026 update added urgency: an unexpected Chromium behavior change caused Classic UI problems to surface earlier than anticipated and required updated fixes. Acumatica listed expedited patch dates for 2026 R1, 2025 R2, and 2025 R1. Organizations should therefore avoid treating November 17 as the first possible impact date.
This changes the planning sequence. Administrators should first verify whether their current browser and Acumatica build already show the issue, then confirm whether the environment contains the updated fix rather than only an earlier patch intended for the original removal schedule. A patch name or installation date is not enough evidence. The change record should identify the exact Acumatica build, the patch source, the browser version used for testing, and the date the current vendor notice was checked.
If a team already experienced intermittent Classic UI failures, the incident evidence should feed the regression pack. Capture affected screen IDs, browser versions, console or network symptoms when available, user roles, customizations, and whether the same transaction succeeds in Modern UI or Firefox. This turns an urgent support event into a repeatable validation scenario instead of relying on memory after the patch is installed.
Map the Acumatica version and hosting model
The correct response depends on both the Acumatica release and who is responsible for applying updates. Acumatica's current notice distinguishes environments on 2025 R1 or later from those on 2024 R2 or earlier. It also distinguishes SaaS delivery from private-cloud subscription environments. Those distinctions determine whether a fix may be delivered automatically, whether a customer must schedule a patch, or whether a supported-version upgrade is required.
Create one row per environment and include production, test, training, disaster-recovery, and integration tenants. Record the full version and build, hosting model, responsible administrator, maintenance process, browser-management policy, installed customizations, and business owner. Do not assume a sandbox matches production merely because the two environments share a major release. Patch history, customization packages, data volume, and authentication configuration can differ.
The inventory should also name the partner or internal team that can confirm patch eligibility. If an environment is outside the versions covered by the current fix, the decision becomes an upgrade and continuity decision rather than a normal patch. That requires additional time for customization validation, integration testing, data refresh, user acceptance, and change approval. Escalate that gap immediately instead of leaving it inside a technical checklist.
Create a dependable Classic UI dependency inventory
A useful dependency inventory starts with people and transactions. Ask department leads which processes still require a Classic UI screen and when those processes become time-critical. Examples include order release, shipment processing, cash management, month-end reconciliations, time entry, project billing, manufacturing exceptions, construction commitments, and administrative setup. The goal is to connect each screen to a business outcome and recovery priority.
Next, inspect technical sources. Review site maps, customization projects, access-right assignments, Classic dashboards, pivot tables, wizards, custom forms, and ISV documentation. Search support tickets for terms such as Classic UI, legacy screen, switch interface, blank page, browser, dashboard, or pivot. Ask power users to demonstrate shortcuts and exception paths because those are often absent from formal process documentation.
For every dependency, record the screen ID, workflow, user group, frequency, peak period, customization owner, Modern UI status, test owner, and fallback. Add a confidence field so unverified assumptions are visible. A screen marked as available in Modern UI is not complete until a business user confirms that the required fields, actions, imports, attachments, reports, and navigation behavior support the real transaction.
Prioritize workflows by operational risk
Not every Classic UI dependency deserves the same response. Prioritize the inventory using business impact, time sensitivity, transaction volume, number of affected users, availability of a workaround, customization complexity, and recovery effort. A rarely used inquiry with a documented Modern UI replacement is different from a release screen that controls daily shipping.
A practical classification uses three tiers. Tier 1 covers workflows that can stop revenue, payment, regulatory, payroll, shipment, or customer-service operations within hours. Tier 2 covers important work that can tolerate a short delay but creates a growing backlog. Tier 3 covers low-frequency administrative or analytical tasks with a workable alternative. The exact labels matter less than having owners agree on the order of testing and recovery.
Risk ranking also helps when time is limited. If the organization cannot execute every test before the maintenance window, it can protect Tier 1 workflows first, document the residual risk, and schedule the remaining validation. The ranking should be approved by process owners, not assigned by IT alone, because technical teams may not know which seemingly small action closes a financial period or releases a customer commitment.
Design the sandbox before applying the patch
A sandbox is valuable only when it represents the production conditions relevant to the change. Confirm that it uses the intended Acumatica build, customization packages, ISV components, authentication method, browser policies, and representative roles. Refresh data when necessary to reproduce critical transactions, while following the organization's privacy and data-handling rules.
Freeze the test baseline before patching. Record the current browser version and execute a small set of control tests so the team knows which issues already exist. Then apply the candidate patch using the same documented sequence planned for production. Capture start and finish times, installer output, service status, application startup behavior, and any manual configuration changes.
After patching, confirm basic health before business testing begins. Verify login, navigation, background processing, scheduled jobs, integrations, printing, email, and access to both Modern and remaining Classic UI screens. If the sandbox contains unrelated experimental changes, identify them clearly or create a cleaner environment. Otherwise a failed test can lead to hours of investigation against the wrong cause.
Build browser coverage around the real desktop estate
Chrome and Microsoft Edge are the most visible Chromium-based browsers in many organizations, but the testing scope should come from the managed desktop estate. Record supported browsers, release channels, update policies, virtual desktop images, kiosk devices, remote-access platforms, and any embedded browser components used by companion applications. Confirm whether updates are centrally controlled or can arrive independently on user devices.
Use the current corporate browser version for the main regression cycle and include the next available managed version when practical. This is especially important when the organization delays browser updates, because a sandbox tested on an administrator's current browser may not represent a warehouse workstation or remote desktop pool. Capture the full browser version in every result, not simply Chrome or Edge.
Do not use compatibility modes or alternate browsers as invisible permanent fixes. A temporary workaround can protect continuity, but it should have an owner, an expiration date, a deployment method, and security approval. The supported application patch and the Modern UI transition remain the durable paths. Browser exceptions that outlive the incident can create a second unmanaged dependency.
Test authentication session and navigation behavior
Begin the functional test pack with the path users take before they reach a transaction. Validate single sign-on or native login, multifactor redirects, tenant selection, company and branch selection, session timeout, logout, and reauthentication. Confirm that bookmarked Classic UI URLs, navigation favorites, and links from notifications still land on the intended page.
Mixed-interface environments deserve special attention. Test navigation from a Modern UI page to a Classic-only page and back again. Verify that the user's role, branch, locale, and session context remain correct. If the organization uses multiple tabs, confirm that common tab patterns do not produce stale sessions or unexpected redirects after the patch.
Record any difference between a direct URL, a site-map link, and a workflow action that opens another screen. A page may render successfully when opened directly while a contextual action passes parameters differently. Tests should therefore begin from the same starting point users follow in normal work rather than launching every screen from an administrator's saved link.
Validate data entry and transaction completion
For each critical workflow, test the transaction from creation through its business endpoint. Confirm field defaults, selectors, date and quantity entry, validation messages, saves, releases, approvals, reversals, attachments, notes, and follow-up navigation. Use realistic roles and data conditions so field security and automation behave as they do in production.
Include positive and negative cases. A successful order entry proves only the normal path. Test missing required fields, credit holds, inventory shortages, approval rejection, failed integrations, duplicate references, and other exceptions the team resolves in Classic UI. These paths often open additional dialogs or screens and are more likely to expose a hidden dependency.
Reconcile the result in the database-facing application screens and downstream business records. For example, confirm that a released document has the expected status, related batch, inventory effect, and audit trail. Browser compatibility testing is not complete if the page looks correct but the transaction produces incomplete or duplicated business data.
Test reports dashboards pivots and exports
Reporting components deserve their own workstream because they combine browser rendering, parameters, data retrieval, printing, and export behavior. Inventory Classic dashboards, pivot tables, report forms, inquiry exports, and links distributed by email or documentation. Identify which ones support executive, compliance, customer, and month-end decisions.
For each report, test parameter entry, date ranges, branch restrictions, drill-down links, pagination, printing, PDF output, Excel export, and scheduled delivery where applicable. Compare totals and row counts with a known baseline. Visual success is not sufficient if the exported file changes columns, formats dates differently, omits rows, or loses filters.
Acumatica's 2026 R2 transition guidance specifically calls out Classic dashboards and pivot tables among the items organizations should prepare for Modern UI. Use the browser-readiness exercise to decide which assets should be rebuilt, replaced with Generic Inquiries, moved to a supported dashboard experience, or retired because no one uses them. Confirm ownership before deleting or redesigning anything.
Validate customizations and ISV solutions
Customizations can preserve business value while also increasing uncertainty during a platform change. Build a list of customization projects, custom screens, modified actions, JavaScript, themes, external widgets, and ISV packages that touch the Classic UI. Record the publisher, source repository or package location, current version, and support contact.
Ask each owner whether a Modern UI version is available and whether the current package has been certified for the target Acumatica patch. Do not treat the absence of a vendor warning as confirmation. Request written compatibility guidance for components that affect Tier 1 workflows, and retain that response with the change evidence.
Regression tests should cover both the visible customization and its side effects. Confirm custom fields, selectors, calculations, actions, pop-up dialogs, file handling, automation schedules, and data sent to integrations. If a workaround requires temporarily disabling a customization, document the business consequence and the precise steps for restoring it. Avoid making emergency production edits that cannot be reproduced in source control.
Protect integrations and automated processes
Many integrations run without a browser, but their configuration, monitoring, and exception handling may still rely on Classic UI pages. Inventory API connections, import and export scenarios, scheduled processes, email processing, commerce connectors, bank feeds, tax services, document capture, and robotic automation. Identify the screen an administrator uses when a job fails.
Test routine execution and at least one controlled exception. Confirm credentials, endpoint behavior, queues, retry logic, logs, and reconciliation. If users normally open a Classic screen to correct a rejected record, validate that recovery path explicitly or provide a Modern UI alternative before the browser change reaches production.
Desktop automation deserves special scrutiny because it may depend on page structure rather than supported APIs. A patch or interface change can break selectors even when a human user sees a functional screen. Record every bot or script that interacts with the browser, rerun it in the patched sandbox, and prefer a supported integration approach when redesign is practical.
Define evidence and acceptance criteria
A readiness decision should be based on evidence that another reviewer can understand. For each test, store the environment, Acumatica build, browser version, user role, test data, steps, expected result, actual result, screenshots when helpful, defect reference, tester, and date. Link the evidence to the change ticket rather than leaving it in personal notes or chat.
Acceptance criteria should describe business completion. Replace vague results such as screen opens with outcomes such as warehouse user creates and confirms a shipment, prints the required document, and verifies the released status using the assigned role. This wording makes it harder to close a test before the transaction reaches its real endpoint.
Classify defects by operational impact and assign a disposition: fix before production, accept temporarily with a documented workaround, remove the dependency, or defer with business approval. Re-run failed tests after any patch or configuration change. A final readiness summary should show passed Tier 1 workflows, unresolved risks, owners, and the explicit go or no-go decision.
Plan backup rollback and recovery
The production plan should state what is being backed up, who verifies the backup, how long restoration would take, and what data could be created between the change and a rollback decision. Coordinate application, database, file storage, customization, and configuration backups according to the hosting model and established support procedures.
Define rollback triggers before the maintenance window. Examples include failed login for a critical population, inability to complete a Tier 1 transaction, widespread Classic UI rendering failure, corrupted output, or integration backlog beyond an approved threshold. Name the person authorized to call the rollback and the latest time that decision can be made safely.
A browser workaround can be part of recovery, but it is not identical to restoring the application. If Firefox is approved as a temporary path, prepare installation, security policy, bookmarks, user instructions, and support ownership in advance. Test the workaround with the same critical roles. Remove the temporary configuration once the supported patch path is stable.
Communicate with users before and after the change
User communication should be specific enough to change behavior without overwhelming people with browser-engine detail. Tell affected users which workflows are in scope, the maintenance window, what normal behavior should look like, how to report a blank or incomplete screen, and whether a temporary browser is approved. Include screenshots or screen IDs when teams use similar names for different functions.
Ask department leads to nominate testers and confirm availability during the validation window. For shift-based operations, include warehouse, field, or production users who may not read the same channels as office teams. Provide a short script for the service desk so reports are tagged consistently with browser version, screen ID, time, user role, and business impact.
After deployment, send a clear completion notice only when the smoke tests pass. If risk remains, state the affected workflow, workaround, owner, and next update time. During the first full business cycle, monitor tickets and transaction queues. Close the change after process owners confirm that operations are stable, not immediately after the technical installation finishes.
Coordinate finance operations IT and leadership
The deadline crosses organizational boundaries. IT owns browser deployment, infrastructure coordination, backups, and technical change control. Acumatica administrators own version verification, patch planning, security roles, and application evidence. Process owners define critical transactions and acceptance. Leadership resolves schedule conflicts and accepts residual business risk.
Finance should identify period-close, payment, billing, and reconciliation windows that restrict change timing. Operations should identify shipping, receiving, manufacturing, field, and customer-service peaks. Security should review temporary browser exceptions and access implications. The service desk should know how to distinguish a browser-rendering issue from authentication, network, or application availability problems.
Use one readiness meeting with a concise decision pack rather than several disconnected technical updates. The pack should show environment status, critical workflow results, open defects, rollback readiness, user communication, and the Modern UI follow-up plan. That structure keeps the immediate patch decision focused while making long-term dependencies visible to leaders who control resources and priorities.
Move from emergency patching to Modern UI readiness
The patch reduces the immediate Chromium risk, but organizations should use the resulting inventory to plan Modern UI work. Acumatica's direction is clear: Modern UI is the default in 2026 R2, users cannot normally switch interfaces when a Modern version exists, and Classic-only functionality is moving toward retirement. A successful patch should therefore buy controlled migration time, not justify indefinite delay.
Group remaining items into standard screens, configuration differences, custom screen conversions, dashboards and pivots, training gaps, ISV dependencies, and process redesign. Estimate each group separately because the skills and validation effort differ. A custom screen may require TypeScript and layout work, while a familiar standard screen may need only role-based testing and training.
Set milestones around business workflows rather than raw screen counts. Completing ten low-value screens does not reduce risk if the only shipping exception process remains Classic-only. Prioritize items by the same operational tiers used for browser testing, and require a business owner to accept the Modern UI result. Update process documentation and support materials as each dependency is retired.
Measure readiness with useful operational metrics
Metrics should reveal whether risk is shrinking. Track the number of Classic UI dependencies by tier, percentage with a confirmed Modern UI path, percentage of Tier 1 tests passed, environments on the approved patch, open defects by severity, users trained, and workflows still dependent on a temporary workaround. Report trends and owners, not only a single green status.
After production deployment, measure failed-page incidents, service-desk volume, transaction backlog, workaround usage, and time to resolve browser-related reports. Compare these results with the baseline. A low ticket count can indicate success, but it can also mean users created manual workarounds without reporting them, so check with process owners during the first critical cycle.
For the Modern UI program, add adoption and quality measures: active users by interface, custom screens converted, acceptance tests completed, unresolved behavior gaps, and time spent supporting legacy paths. Review the metrics monthly until Tier 1 Classic dependencies reach zero. Retire emergency browser policies and temporary documentation as soon as the supported operating model is stable.
Common mistakes that increase deadline risk
The first mistake is assuming that an automatic SaaS update removes the need for testing. Delivery responsibility and business acceptance are different. The second is checking only the home page. A mixed-interface tenant can appear healthy while a specific Classic workflow fails. The third is recording a major version without the full build and current patch evidence.
Other common failures include testing only with an administrator, excluding exception paths, overlooking Classic dashboards and pivots, forgetting third-party add-ons, and using a temporary browser without security approval. Teams also lose time when results are stored in chat messages instead of a shared test record, or when no one has authority to decide whether a defect blocks deployment.
The most expensive mistake is treating the compatibility fix as the end of the project. That leaves the organization exposed to the next browser or platform change and compresses the Modern UI migration into a later upgrade window. Use the November deadline as a forcing function to create accurate ownership, reusable tests, and a funded retirement plan for the remaining legacy dependencies.
Executive decision checklist
Before approving production work, leaders should be able to answer the following questions. Do we know every production and sandbox version? Have we confirmed the current Acumatica patch guidance? Are all Tier 1 Classic workflows identified and tested in the managed browser estate? Are customizations, ISV products, reports, integrations, and exception paths included? Is the backup and rollback decision documented? Are users and the service desk prepared?
They should also ask what remains after the patch. Which Classic dependencies lack a Modern UI path? Which items block a future 2026 R2 or later upgrade? Who owns each conversion, validation, or vendor escalation? What is the target date for removing temporary browser workarounds? How will progress be measured and reported?
A responsible go decision does not require zero defects, but it does require transparent residual risk, named owners, workable contingencies, and business acceptance. If those conditions are absent, the correct action is to adjust the window or reduce risk before proceeding. The November date is important, but an undocumented emergency change can create more disruption than the browser change it is intended to prevent.
Production cutover runbook
The cutover runbook should convert the approved plan into a timed sequence that anyone on the change team can follow. Begin with a readiness checkpoint confirming the maintenance window, backup completion, patch package, administrator access, tester availability, communication status, and rollback authority. Record the starting Acumatica build and browser versions before anyone changes the environment.
During implementation, log each action and its result. Typical steps include pausing scheduled work when required, applying the approved patch, restarting relevant services, confirming application availability, validating login, and releasing the environment to smoke testers. Avoid adding unrelated configuration or customization changes to the same window. A narrow scope makes troubleshooting and rollback decisions faster.
The smoke-test order should follow business risk. Test authentication and one high-value transaction first, then complete the remaining Tier 1 scenarios, integrations, reports, and exception paths. Establish a time limit for investigation so a difficult defect does not consume the rollback window. Record whether the team proceeds, pauses, uses a temporary contingency, or restores the previous state.
Close the maintenance window with a formal handoff. Confirm the final build, browser results, open issues, workaround status, monitoring owners, and next communication time. Preserve the runbook and evidence because the same tests can support a later patch, browser release, or Modern UI conversion. A reusable runbook turns one deadline response into a stronger operational control.
First business day monitoring plan
The highest-value monitoring occurs when users resume normal work. Staff the service desk and application team around the first order cycle, shipment wave, approval run, scheduled integration, and financial processing period. Ask process owners to report both failures and unexpected manual steps. A workflow can technically complete while taking much longer or forcing users into an undocumented workaround.
Create a focused incident category for Classic UI and Chromium reports. Collect the user, time, browser version, Acumatica build, screen ID, navigation path, screenshot, and business impact. Compare similar reports before changing the system; several departments may be seeing one shared issue. Separate browser rendering problems from access rights, network latency, stale cache, customization defects, and unrelated application errors.
Monitor server and application indicators alongside user feedback. Review error logs, background job status, integration queues, email processing, scheduled reports, and transaction backlogs. If the organization deployed a temporary alternate browser, track who uses it and for which workflows. That usage is a measurable residual dependency and should decline after the supported fix is confirmed.
At the end of the first business day, issue a concise status summary: transactions tested, incidents received, resolutions, outstanding risks, and the next review point. Continue monitoring through the next critical weekly or month-end cycle if those processes were not exercised during the initial window. Do not close the change solely because the maintenance period ended without an alert.
Long term governance for browser dependent ERP features
Browser dependencies should become part of the ERP governance model. Add supported browsers and managed versions to the platform standard, identify who reviews browser deprecation notices, and connect that review to Acumatica release and patch management. Include browser changes in the same calendar used for operating-system, identity, database, and integration dependencies.
Maintain a reusable compatibility test pack with role-based transactions, reports, customizations, and exception paths. Run a focused subset before major browser deployment and the full pack for high-risk application or platform changes. Automate evidence collection where it is reliable, but retain human acceptance for workflows whose success depends on business judgment, usability, or printed output.
Governance should also prevent new Classic dependencies. Require new customizations and ISV purchases to state their Modern UI support, browser requirements, upgrade policy, and test responsibility. Review existing custom work during each Acumatica upgrade cycle and remove assets that no longer have an owner or business purpose. This reduces the volume of emergency analysis during future deadlines.
Finally, keep leadership informed through a small set of operational measures: unsupported environments, Tier 1 legacy dependencies, patch compliance, open vendor gaps, and Modern UI conversion progress. The purpose is not to create more reporting. It is to make hidden platform risk visible early enough that the organization can schedule work before an external vendor date controls the timetable.
Patch validation checklist
Confirm the target Acumatica version and exact patch against the latest vendor notice. Verify backup and rollback ownership. Test a Chromium browser in sandbox. Exercise each critical Classic UI workflow from login to completion. Validate custom screens, reports, dashboards, pivot tables, attachments, exports, and approval steps. Record results. Communicate the production window and contingency browser. Complete production smoke tests and keep the evidence with the change record.
Frequently Asked Questions
Will the November 17, 2026 date affect every Acumatica customer? The exposure depends on version, patch level, browser, and whether users still rely on Classic UI. Verify the current Acumatica notice for your environment.
Does applying the patch remove the need to move to Modern UI? No. It addresses browser continuity; it does not replace the migration and customization work required for the Modern UI direction.
Can Firefox be the permanent answer? Treat it as a temporary contingency only. It may preserve access in some scenarios while you complete the supported patch or upgrade path.
Which items need the most careful testing? Custom screens, Classic-only forms, dashboards, pivots, workflow exceptions, ISV components, and actions used during time-sensitive business cycles should be explicit test cases.
What should a PCS customer do? Confirm the applicable patch and installation process with Acumatica or your partner, then patch and validate before the deadline.
What should a SaaS customer do? Confirm the delivered patch status and validate business-critical workflows in your tenant; automatic delivery does not replace acceptance testing.
Can an organization still use Classic UI in 2026 R2? The current documentation says Classic UI is disabled by default in 2026 R2, with limited legacy access mechanisms and remaining Classic-only functionality warned for later retirement. Confirm the exact release guidance before planning.
When should the work start? Immediately. The October 2026 browser behavior change described in Acumatica's updated notice means waiting until November can leave too little time for a controlled regression cycle.
Sources
Biz-Tech Services can help teams inventory Classic dependencies, validate patches, and plan a controlled Modern UI transition without losing sight of business-critical workflows.
