Modern UI Migration Readiness
Prepared for Biz-Tech Services | Last verified 13 October 2026
Acumatica Modern UI migration readiness is the discipline of proving that your people, processes, customizations, and dependencies can operate safely in the modern interface before a production upgrade makes it the default. This guide explains what to inventory, test, train, remediate, and measure so the migration supports the work that matters most.
Table of Contents
- Why Modern UI readiness is now a business priority
- What changes with Acumatica 2026 R2
- Build a Modern UI inventory before changing settings
- Assess customizations and custom screens
- Audit integrations, ISV products, and embedded experiences
- Decide the future of dashboards, pivot tables, and inquiries
- Map end-to-end workflows by role
- Set up a safe, representative test environment
- Create a role-based testing strategy
- Plan user adoption around recurring work
- Protect security, personalization, and controls
- Measure performance and accessibility in real conditions
- Sequence remediation and make tradeoffs explicit
- Run a rehearsal and production cutover
- Define readiness metrics and the next practical step
- A practical four phase migration plan
- How finance operations should validate the new experience
- How operations teams should validate warehouses and production
- Common readiness mistakes and how to avoid them
- Modern UI migration readiness checklist
- Frequently Asked Questions
- Sources Used
Why Modern UI readiness is now a business priority
Modern UI migration readiness is no longer a cosmetic ERP initiative. It determines whether people can complete the work that creates invoices, receives goods, closes jobs, posts time, releases payments, and answers customers. Acumatica 2026 R2 makes Modern UI the default experience and removes the normal ability to switch an otherwise available form back to Classic UI. Acumatica also states that Classic-only forms are planned to become unavailable in 2027 R1. The practical implication is simple: an organization that still depends on Classic-only assets must treat them as a visible operating risk, not as a future enhancement backlog.
The leadership question is not whether users prefer a familiar layout. It is whether every business-critical path has a supported, tested Modern UI route. The migration affects finance, operations, IT, reporting, internal controls, external integrations, and adoption. A good program gives each of those groups a role: business owners define the essential outcomes, IT validates technical compatibility, developers remediate UI-specific work, and executive sponsors decide which risks are acceptable.
This guide is a readiness framework, not a claim that every Acumatica tenant has the same gaps. Feature coverage, custom packages, ISV products, deployment model, version, and business process all matter. Use it to create an evidence-based inventory and a go/no-go decision before a release window is fixed.
What changes with Acumatica 2026 R2
In 2026 R2, Modern UI is the standard user experience. When a form has a Modern UI version, Acumatica opens it in Modern UI. The ordinary UI-selection options are no longer presented in the installer, system menu, Site Map, or Site Preferences. Administrators can temporarily enable legacy behavior through a web.config setting, but that is a troubleshooting measure, not a migration strategy.
The release still allows access to some Classic-only functionality, but it warns that the capability is being retired. Acumatica specifically identifies unmigrated dashboards and pivot tables, wizard forms, the Customization Editor Layout Editor, custom forms that have not been converted, and other Classic-only forms. Teams should record each of these items, identify its business owner, and decide whether to migrate, replace, retire, or defer it with documented risk acceptance.
Do not confuse an interface transition with a data conversion. Acumatica describes the switch as an interface change: records, transaction history, and configurations remain in the same application. However, an unsupported UI customization can make data difficult to view, enter, or act on. Readiness therefore focuses on business behavior and usability, not on moving master data between systems.
Build a Modern UI inventory before changing settings
Start with discovery, not conversion. Build one inventory covering standard forms, custom and customized forms, dashboards, pivot tables, generic inquiries, reports, mobile projects, embedded links, personalization, browser scripts, code-behind files, third-party extensions, and documented workarounds. Include the screen ID, purpose, business process, frequency, criticality, owner, current UI behavior, dependencies, and proposed disposition.
Use a tiering model that reflects operational consequence. Tier one includes steps that affect cash, shipment, production, safety, statutory reporting, customer commitments, or an active project billing cycle. Tier two covers important management, analysis, and supervisory work. Tier three includes occasional or replaceable conveniences. Tiering prevents a long list of minor layout issues from obscuring a single payment, warehouse, or compliance blocker.
Inventory evidence must be observable. A screenshot, a saved test case, a package name, an ISV confirmation, a user interview, or a record of usage provides better evidence than a spreadsheet cell that says ready. Ask super users where they leave Acumatica, reopen old bookmarks, use a browser favorite, or ask another user to complete a task. Those informal detours often reveal the Classic UI dependencies that configuration lists miss.
Assess customizations and custom screens
Most backend business logic does not automatically become a Modern UI problem. The higher-risk items are the portions of a customization that assume Classic UI page markup, control IDs, JavaScript behavior, fixed dimensions, code-behind files, or browser-side manipulation. Acumatica notes that forms with inline JavaScript or ASPX.CS code may require additional migration work; Modern UI recalculates controls according to its design guidelines and screen size rather than preserving Classic UI size calculations.
Run compatibility validation on a copy of each package in a sandbox that matches the intended target version. Treat a successful validation as the beginning of testing, not sign-off. For every package, record the validator result, conversion work performed, published version, affected screens, source repository reference, regression cases, test owner, and remaining limitations. Do not rely on an old package file or a verbal statement that it worked on another tenant.
The Customization Project Editor includes a Convert to Modern UI command for selected screens. It can generate source files for custom screens or extension files for customized screens. Use tooling to accelerate analysis, then review the generated result against the actual workflow. Conversion cannot decide whether a legacy dialog, layout, or client-side behavior remains the right interaction for a modern responsive application.
Audit integrations, ISV products, and embedded experiences
A Modern UI project can fail through a dependency that is not visually obvious. ISV solutions can open a custom form, inject a toolbar action, rely on legacy behavior, or publish a customization package at upgrade time. External systems may target a screen, launch an embedded page, parse an exported view, or depend on an operator following an old navigation route. Give every vendor and internal product owner a concrete compatibility questionnaire and a due date.
Request the exact supported version, prerequisite patches, installation order, Modern UI limitations, known issues, test guidance, support contact, and cutover coverage. Ask whether the vendor has tested your target Acumatica build rather than asking whether the product supports Modern UI in general. Record the answer and test the most consequential transaction in the sandbox. A statement of compatibility without a repeatable test is incomplete evidence.
Review bookmarks, deep links, browser extensions, iframe content, scanning and printing workflows, and automated browser steps. Replace brittle screen-driven automation with supported integration patterns where possible. When a dependency cannot be modernized before the release, document the business impact, temporary procedure, monitoring, owner, and date for removal. This makes technical debt a managed decision rather than an invisible production dependency.
Decide the future of dashboards, pivot tables, and inquiries
Dashboards and pivot tables often contain operational knowledge that is not captured in a formal customization project. In 2026 R2, existing Classic dashboards and pivot tables can still be accessed while teams migrate what they need, but new Classic dashboards and pivot tables cannot be created when Classic UI is disabled. The useful question is not whether every artifact should be copied; it is which decision or daily action each one supports.
Classify each asset as keep and migrate, redesign, replace with a generic inquiry or report, consolidate, or retire. Then test it with the audience who uses it. Check security, filters, saved views, export, drill-down behavior, shared versus personal settings, and performance at realistic volume. A modernized dashboard that loads but provides the wrong role with the wrong slice of information has not met its purpose.
Use this work to reduce duplication. When five teams maintain similar inquiries with slightly different calculations, establish a governed owner and a clear definition. Modern UI migration is an opportunity to improve information architecture, but it should not become an unbounded analytics redesign. Keep required operational assets in the critical path and schedule broader reporting rationalization as a separate, owned initiative.
Map end-to-end workflows by role
Screen-level testing is necessary but insufficient. A user experiences an order, purchase, work order, project, or close as a chain of steps across screens, approvals, attachments, reports, devices, and integrations. For each tier-one workflow, map the trigger, inputs, roles, decision points, exception paths, outputs, control evidence, and downstream system effects. This establishes what “ready” means in business terms.
Finance should trace payables, receivables, cash, tax, period close, approvals, and financial reporting. Distribution should trace promise dates, allocation, warehouse execution, shipment, invoice, return, and inventory adjustment. Manufacturers should trace planning, release, material, labor, completion, quality, and cost. Project and construction teams should trace commitments, changes, time, billing, retainage, and compliance. Use your actual configuration rather than a vendor demonstration path.
Include exceptions deliberately: an approval rejection, a partial shipment, an expired lot, a failed payment, a missing attachment, a late timecard, a reopened project, or a duplicate integration message. Exception handling exposes navigation, permissions, messages, and recovery work that happy-path demos leave untouched. It also gives the business a way to decide whether a changed interaction is acceptable before it happens under pressure.
Set up a safe, representative test environment
A productive migration sandbox resembles production in version, configuration, packages, security, tenant structure, report definitions, data volume, and devices without creating real-world transactions. Refresh responsibly, protect sensitive data, and isolate email, payment, carrier, tax, commerce, and file-transfer endpoints. Test credentials and certificates with nonproduction endpoints wherever the provider offers them.
Establish a baseline before changing anything. Capture key financial totals, inventory quantities and valuation, open orders and commitments, scheduled jobs, integration queues, user counts, response times, and critical report output. Record filters and time stamps. The same evidence becomes the comparison pack after an upgrade or customization publication. A total without the date, branch, company, ledger, or report parameters is difficult to audit.
Promote packages in a controlled sequence and preserve source control references. Use a clean test run after each major remediation wave. If an error is discovered, log the exact build, package version, role, browser, inputs, expected result, actual result, evidence, and owner. Reproducing a defect is far less expensive than rediscovering it at cutover.
Create a role-based testing strategy
Write test cases in the language of work. “Open the screen” is a smoke test; “receive a serialized item, resolve a quantity exception, print the label, release the receipt, and confirm inventory and AP consequences” is a meaningful business test. Each test should name the role, preconditions, data, steps, expected result, evidence, and pass/fail owner.
Separate technical checks from business acceptance. Technical checks cover publication, login, permissions, performance, errors, supported browsers, and dependent services. Business acceptance confirms that a role can complete its recurring work and that results are accurate. Both are needed. A developer should not be the only person to certify a controller’s close workflow, and an end user should not be asked to diagnose a package publication error.
Set entry and exit criteria. A tier-one test must pass in the target version; severity-one defects must be resolved or formally rejected; reconciliations must meet agreed tolerances; vendors must confirm essential components; and training must be complete for affected roles. Use defect severity based on business impact, not on how quickly an issue seems fixable. This prevents false readiness caused by optimistic labels.
Plan user adoption around recurring work
People do not need a catalogue of every design change. They need to know how to complete their own work, recognize a changed behavior, and get help without inventing an uncontrolled workaround. Build short role-based learning paths around daily tasks: navigation, search, inquiries, entering and releasing documents, working with attachments, approvals, personal settings, and exception recovery.
Use current screenshots from the approved target environment. A job aid copied from Classic UI is itself a migration defect. Give super users hands-on practice before their teams and assign them a clear escalation route. Their feedback should distinguish a genuine defect from a preference, a training gap, a configuration decision, and a process problem. Each category needs a different response.
Stage communication by business rhythm. Finance may need dedicated practice ahead of close, warehouse users ahead of a peak shipping window, and project teams ahead of billing. Publish the planned switch, what users will see, the support channel, any temporary limitations, and the decision owner. Adoption becomes manageable when people see a direct connection between the training and the work waiting on their desk.
Protect security, personalization, and controls
Modern UI readiness must preserve least privilege. Re-test role access, branch restrictions, approval maps, workflow states, sensitive fields, attachments, report access, inquiry visibility, and exported information. Do not assume a screen that renders correctly respects the same operational boundary. Use separate roles to prove both allowed and denied behavior.
Personalization deserves deliberate governance. Users may tailor screens, fields, tabs, and layouts, but critical controls must remain discoverable and consistent. Define what is centrally managed, what is role-specific, what can be personalized, and how a user requests a correction. Preserve the evidence needed for audit and make sure job aids point to the approved workflow rather than a particular individual’s personalized view.
Review browser policies, multifactor authentication, session timeouts, shared-device behavior, and attachment handling. Work with compliance and security leads when data is exposed through embedded services, analytics, automation, or customer-facing experiences. A migration that simplifies navigation while weakening a segregation-of-duties control is not ready for production.
Measure performance and accessibility in real conditions
Modern UI is responsive by design, so test the real mix of workstations, display sizes, browsers, warehouse devices, and network conditions. Observe load time, search behavior, scrolling, filters, grids, popups, file upload, printing, and keyboard use during normal volume. Fixed-size Classic UI assumptions frequently surface when a screen is used on a smaller display or with a different zoom level.
Measure a small set of representative tasks instead of relying only on an overall page-load impression. For example, time how long it takes to find an order, enter a receipt, open an inquiry, approve a bill, attach a document, and release a transaction. Compare the user experience with baseline expectations, and investigate whether a gap is caused by data, configuration, customization, network, browser policy, or a third party.
Accessibility and usability are operational quality concerns. Check readable labels, focus order, error messages, keyboard navigation, contrast, responsive reflow, and the clarity of actions. Invite users who work at different experience levels to perform realistic tasks. The best migration is one in which a new user can understand the next correct action without depending on a legacy layout.
Sequence remediation and make tradeoffs explicit
Use the inventory and test evidence to create a risk-ranked backlog. Fix tier-one blockers first, then high-frequency pain points, then strategic enhancements. For every item, state the decision: migrate, redesign, replace, retire, defer, or accept risk. Include an owner, target date, test case, dependency, estimate, and a measurable completion condition.
Avoid a big-bang scope that combines interface conversion, an ERP version upgrade, new AI functionality, report redesign, data cleanup, process reengineering, and a new commerce connector unless there is a compelling business reason. A stable base release makes later improvement safer. Where a combined release is unavoidable, give each component its own disable path, owner, and acceptance evidence.
Escalate uncertainty early. Missing vendor confirmation, a legacy script without source, a failing high-volume inquiry, or an untested device integration is not a minor observation. It is a decision point. Executive sponsors should resolve scope, funding, timing, or risk acceptance while alternatives remain available rather than after a production window has begun.
Run a rehearsal and production cutover
A timed rehearsal turns a plan into evidence. Use the intended upgrade route, target packages, configuration steps, integration holds, communications, smoke tests, reconciliations, and support model. Record actual duration, deviations, dependencies, and decisions. Improve the runbook until each task has an owner, start condition, expected duration, evidence, and fallback.
The production runbook should include user communication, backup and restore verification, interface pause or queue management, the upgrade, package publication, authentication checks, smoke tests, business-process validation, reconciliation, release of integrations, and monitoring. Define exactly who can declare a hold, who can authorize rollback, and what triggers that decision. A successful installer message is not a go-live decision.
During stabilization, monitor business outcomes as well as technical telemetry. Review errors, job failures, queue backlog, failed sign-ins, support tickets, print and email activity, payment and banking flows, performance, and critical document counts. Hold short cross-functional triage sessions. Make every emergency fix traceable, tested where possible, and visible to the people responsible for the affected workflow.
Define readiness metrics and the next practical step
A useful dashboard reports evidence, not optimism. Track the percentage of tier-one workflows passed, number of unresolved blockers, customization and ISV confirmation status, training completion, reconciliation differences, rehearsal duration, support coverage, and known exceptions. Pair each metric with an owner and a threshold. “Green” should mean that a documented condition has been met, not that a meeting felt positive.
After release, measure adoption and value separately from readiness. Look at task completion, support demand by role, workaround use, close duration, inquiry response time, transaction exceptions, and the business measures the migration was intended to protect. Review at 30, 60, and 90 days. This prevents the organization from declaring success at cutover while recurring users struggle with a slow or inconsistent process.
The next practical step is a facilitated readiness assessment that produces a screen and workflow inventory, risk-ranked backlog, test plan, training plan, and cutover decision criteria. Biz-Tech Services can help teams assess Modern UI coverage, customizations, integrations, ISV dependencies, business processes, and adoption risks—then turn the findings into an executable migration plan.
A practical four phase migration plan
Phase one is discovery and alignment. Confirm the target Acumatica version and the reason for the migration; nominate process owners; inventory screens, packages, dashboard assets, ISVs, integrations, and user groups; and tier the workflows. The output is a shared fact base, not a promise that all issues are easy. Leadership should approve the critical workflow list and the decision rules before conversion work begins.
Phase two is remediation and sandbox validation. Convert or redesign screen-specific work, obtain partner and vendor confirmations, replace unsupported behavior, and run technical regression tests. Keep a daily list of new defects and decisions. Where a remediation affects a workflow, give the business owner an early opportunity to see it; waiting until the final user-acceptance session makes even a small design decision feel like a surprise.
Phase three is role-based acceptance and rehearsal. Train super users, execute the tier-one test pack, reconcile data and documents, run the cutover script end to end, and verify the support model. Phase four is production and stabilization: communicate clearly, execute the approved runbook, monitor the agreed indicators, triage issues visibly, and turn deferred improvements into an owned release plan. The phases may overlap, but each needs explicit exit evidence.
How finance operations should validate the new experience
Finance should establish a baseline that makes discrepancies observable. Capture trial balances by company, branch, ledger, and period; AP and AR aging; cash positions; tax reports; inventory valuation where relevant; unreleased batches; and selected financial statements. Preserve the report parameters and as-of time. This provides a stable comparison after sandbox migrations and again after production cutover.
Test complete control chains. For procure-to-pay, enter and approve a bill, process payment, handle a void or adjustment, and reconcile the result. For order-to-cash, include credit review, shipment, invoice, payment, adjustment, refund, and aging. Exercise approval paths, multiple branches, currencies, tax settings, and restricted roles that reflect production. Confirm not only that a document saves, but also that it posts and appears correctly in the reports that people rely on.
The controller or a named delegate should sign a concise acceptance pack. It should show control totals, exceptions, selected transaction evidence, payment and bank-interface outcomes, and a list of any accepted differences with an owner and due date. This is a better go-live control than a generic confirmation that finance users could sign in.
How operations teams should validate warehouses and production
Distribution and warehouse teams should follow inventory from demand to fulfillment and return. Test availability, allocations, purchasing, receiving, replenishment, picks, packing, shipment, invoicing, returns, transfers, cycle counts, and valuation with real item classes, warehouses, units, kits, serial or lot controls, and partial shipments. Validate labels, printers, scanners, carrier connections, and actual workstations rather than only a developer laptop.
Manufacturing teams should connect planning, scheduling, execution, material movement, labor, completion, quality, and costing. Use representative calendars, work centers, alternate resources, bills of material, routings, scrap rules, subcontract steps, and backflush behavior. A work order that looks correct on one screen may fail in the shift-level sequence that operators use, so involve the people who record labor, issue material, and resolve exceptions.
For both teams, write a manual fallback for the few processes where an external device or service could fail during cutover. Define who records the temporary transaction, how it is reconciled, and when the fallback ends. A contingency that cannot be reconciled is simply deferred risk.
Common readiness mistakes and how to avoid them
One common mistake is treating a compatibility check as full acceptance. Validators and converters are valuable, but they cannot prove that a role can complete an exception-heavy process or that a custom report still supports a decision. Avoid the mistake by linking each technical artifact to one or more business tests and naming a business owner who can accept the result.
Another mistake is trying to preserve every legacy interaction exactly as it was. Some behavior was designed around fixed Classic UI layouts and no longer makes sense in a responsive interface. Instead, identify the underlying business need, then choose a design that meets it in Modern UI. This reduces rework and produces a process that is easier to maintain than a screen full of special cases.
A third mistake is scheduling training after the production change. Users discover real process gaps when they practice their own work, and those discoveries need time for remediation. Begin targeted super-user practice early, use final target-version screens in materials, and reserve time between user acceptance and production for corrections.
Modern UI migration readiness checklist
Before approving a production move, confirm that the target version and build are recorded; Classic-only assets are identified; tier-one workflows have named owners; customizations and ISV packages have target-build evidence; integrations have been tested for normal and exception behavior; dashboards, pivots, inquiries, reports, and mobile experiences have a documented disposition; and security roles have been revalidated.
Confirm that representative sandbox data and safe endpoints are available; pre- and post-change reconciliations are defined; role-based test cases have passed; defects are categorized and either resolved or accepted; user aids and training are current; production support coverage is scheduled; a cutover rehearsal has been timed; rollback criteria and authority are known; and communications say what changes and where users get help.
Finally, make the decision explicit. The executive sponsor, IT lead, and affected business owners should review the evidence and record go, no-go, or conditional go. A conditional decision must name the condition, owner, verification method, and deadline. This last step keeps readiness from becoming an ambiguous feeling and makes the migration accountable.
Frequently Asked Questions
Is Modern UI mandatory in Acumatica 2026 R2?
Modern UI is the default experience in 2026 R2 and ordinary switching options are removed. Classic-only assets can still be accessed temporarily with warnings, but Acumatica says they will no longer be available beginning with 2027 R1.
Will switching to Modern UI change our Acumatica data?
The UI transition does not convert or remove business records. The risk is operational: a customization, screen, report, or workflow may need work before users can interact with data correctly in the new experience.
Do all customizations need to be rewritten?
No. Backend logic can often remain intact. Review and test UI-specific customizations, especially JavaScript, ASPX.CS code-behind, fixed layout behavior, custom screens, and client-side manipulation.
How should we test Modern UI?
Test complete role-based workflows in a representative sandbox. Include normal and exception paths, permissions, integrations, reports, devices, reconciliations, and business-owner acceptance.
What should we do with Classic dashboards and pivot tables?
Inventory them, identify the decision they support, and choose to migrate, redesign, replace, consolidate, or retire each one. Existing Classic assets remain temporarily available in 2026 R2, but new Classic dashboards and pivot tables cannot be created when Classic UI is disabled.
Can we rely on EnableLegacyUI as our long-term solution?
No. Treat it as a short-term diagnostic or transition option. A sustainable plan removes reliance on Classic-only functionality before it becomes unavailable.
Who should own the migration?
IT owns environment and technical compatibility; business owners own workflow acceptance; developers own remediation; change leads own adoption; and an executive sponsor owns priorities, risk acceptance, and the final go/no-go decision.
What should block a production cutover?
A failed tier-one workflow, unsupported dependency, unresolved security issue, material reconciliation difference, unproven recovery procedure, missing vendor support, or incomplete business acceptance should block release.
How long does Modern UI migration take?
The answer depends on the number and complexity of customizations, third-party products, workflows, users, environments, and unresolved legacy dependencies. A discovery inventory and timed rehearsal provide a more reliable estimate than a generic timeline.
What is the most important first step?
Build a risk-ranked inventory of business-critical screens, customizations, dashboards, integrations, ISV products, and workflows. Then verify every tier-one item in a target-version sandbox.
Sources Used
- Acumatica 2026 R2 Classic UI retirement guidance
- Acumatica announcement: Classic UI deprecation in 2026 R2
- Acumatica 2026 R2 release announcement
- Migrating custom frontend code to the Modern UI
- Acumatica Customization Project Editor: Screens
- Acumatica 2025 R2 release announcement
- Modern UI features overview 2025 R2 announcement
- Acumatica support and documentation portal
