Converting Acumatica Custom Screens to Modern UI: Extension vs New-Screen Decision Guide

October 26, 2026
|In Blog
|By Gary

Centered blue-and-gold enterprise interface scene showing two paths converging on a Modern UI dashboard, illustrating the choice between extending a standard Acumatica screen and building a new custom screen.

Converting Acumatica Custom Screens to Modern UI Extension vs New Screen Decision Guide

A practical architecture and validation guide for Acumatica 2026 R2

Prepared for Biz-Tech Services | Last verified 26 October 2026 | Practitioner review required before publication

The safest way to convert an Acumatica custom screen to Modern UI is to decide first whether the screen is a customization of an Acumatica form or a screen your team owns end to end. Extend the supported Modern UI form when the business process still belongs to a stock Acumatica screen; build or convert a custom form when the screen, its navigation, and its user experience are genuinely yours. In both cases, treat generated TypeScript and HTML as a starting point, then validate the result in a development environment with real roles, workflows, and exception paths. [1] [2]

That distinction prevents two expensive mistakes: replacing a supported screen with a parallel copy that becomes difficult to maintain, or forcing a deeply owned application experience into a narrow extension that cannot express the workflow. The immediate reason to resolve the question is Acumatica 2026 R2: Modern UI is the default experience, while Classic UI-only forms remain a transition concern rather than a stable future design. This guide provides an architecture decision process, a conversion workflow, and an acceptance model for technical teams, application owners, and implementation leaders. [1] [6]

Table of Contents

What the extension versus new screen decision really means

The decision is not a preference between two frontend technologies. Both paths use Modern UI concepts and both may involve TypeScript, HTML, a customization project, publishing, and verification. The architectural question is ownership. A customized stock screen begins with Acumatica’s form, graph, security model, navigation, actions, and expected behavior. A fully custom screen begins with a business capability your organization or ISV owns, even when it works with Acumatica data. [2] [5]

Choose an extension when the primary user task is still a standard Acumatica task and the change is additive or localized. Examples include exposing a custom field, adding a tab, changing a small portion of layout, or adding an action that belongs in the context of an existing stock form. The Modern UI extension preserves the original form as the base and expresses the difference. That keeps future product behavior and the customization visibly separate. [2] [3]

Choose a new screen when the solution needs its own screen identity, workflow, and interaction model. The decision is stronger when the team owns the data-entry sequence, task-specific navigation, nonstandard work queue, visual layout, and lifecycle rather than merely one extra panel on a stock screen. A custom screen may consume standard data and still be fully owned from a UI perspective. The goal is not to maximize custom code; it is to align the implementation boundary with the business boundary. [4] [5]

Back to Table of Contents

Why this choice matters in the 2026 R2 transition

Acumatica’s 2026 R2 guidance says Modern UI is the default experience. It also explains that Classic UI-only forms can remain accessible during the transition with a warning, while 2027 R1 is the stated next milestone for removing Classic UI-only forms. That makes a screen inventory a roadmap activity, not a cosmetic cleanup. A screen that users can still open today may nevertheless be an unsuitable dependency for the next upgrade cycle. [1]

The practical takeaway is not to rush every screen through a converter. Prioritize by operational consequence. Start with the screens that stop quoting, shipping, invoicing, receiving, production reporting, project billing, or financial control when they fail. Then identify who owns the underlying process, what integrations and reports touch it, and what evidence proves the Modern UI version works. A visible screen is rarely a standalone asset; it is usually one step in a larger workflow. [1] [7]

The transition also raises the cost of ambiguity. If a customization has no technical owner, source location, documentation, or test evidence, no one can confidently decide whether to extend, rebuild, retire, or replace it. Treat missing ownership as a discovery item before it becomes a production outage. A short inventory done early is less disruptive than trying to reconstruct a screen’s purpose under an upgrade deadline. [7]

Back to Table of Contents

Start with a screen ownership inventory

Create a record for every custom or customized screen before design begins. Capture the screen ID, title, customization package, repository location, graph and DAC dependencies, fields and actions added, JavaScript or CSS assumptions, import or export scenarios, integrations, reports, security roles, business owner, technical owner, and last known test result. Include whether the screen is stock with additions, wholly custom, or uncertain. The uncertain category is useful because it prevents teams from guessing. [1] [7]

Then follow one representative transaction from entry to its downstream effect. For a custom order screen, the trace may include validation, approval, shipment, invoice creation, connector messages, and reporting. For an inquiry, it may include data joins, branch restrictions, filters, exports, dashboards, and a manager’s decision. This trace reveals whether a seemingly simple UI change is actually coupled to controls, automation, or user expectations.

Do not judge ownership from the screen’s appearance. A screen with a stock-style layout can still be fully custom because its business logic, views, and navigation are bespoke. Conversely, a heavily rearranged stock screen can remain a good extension candidate when the standard form still owns the job-to-be-done. Ownership follows responsibility for behavior and evolution, not the number of controls visible on the page.

Back to Table of Contents

When an extension is the maintainable choice

An extension is normally the right starting point when users need a stock form to behave mostly as Acumatica intended. The team may need a custom field, a focused tab, an adjusted section, a contextual dialog, a validation cue, or a purpose-built action. In that situation, the stock form remains the source of truth for lifecycle, standard commands, and navigation. The customization adds a deliberate difference rather than recreating the entire experience. [2] [5]

Acumatica’s Modern UI documentation describes a customized form through TypeScript and HTML extension files. The TypeScript side mixes into the original screen class, while the HTML extension uses a top-level template and places customization tags at the same level. That pattern matters because it makes the relationship explicit: the extension depends on a known original rather than pretending to be an independent application. [2]

Extensions are especially valuable when product upgrades should continue to contribute improvements to the base form. They reduce duplicated layout and allow the team to review a smaller, more meaningful diff during future upgrades. They are not automatically low risk, however. An extension that assumes a particular element ID, field location, workflow state, or untested side effect can still fail when the base form changes. Small scope should lead to disciplined testing, not casual testing. [3] [5]

Back to Table of Contents

When a new custom screen is the better boundary

A new custom screen is appropriate when the business process is not simply an altered version of a stock form. A dispatcher workbench, a specialized pricing review, a field-service intake workflow, or a multi-step operational queue may need its own task flow, layout, and language. In these cases, trying to attach every interaction to a standard screen can make the customization hard to understand and harder to validate.

The Customization Tool Reference Guide distinguishes new screens from customized screens. Creating a new screen establishes a screen ID, source files, business logic code, and a site-map node; converting a custom screen to Modern UI generates source files, while converting a customized screen generates extension files. Those are useful technical signals, but they should follow the business architecture decision rather than replace it. [4]

A new screen creates a larger ownership commitment. The team must define its navigation, user permissions, data views, actions, error states, localization needs, test coverage, documentation, support path, and upgrade policy. That additional work is justified when it produces a coherent solution. It is not justified merely because the existing stock form feels unfamiliar or because copying it seems faster in a single sprint. [4] [5]

Back to Table of Contents

Use decision rules instead of a feature checklist

A feature checklist can produce a false sense of certainty because the same requirement may be implemented differently in different environments. Use a sequence of decision rules instead. First ask whether the primary task is standard Acumatica work. If the answer is yes, begin with an extension hypothesis. Next ask whether the user needs a distinct workflow, distinct navigation, and a layout that cannot be expressed cleanly as an addition to the stock screen. If the answer is yes, investigate a new-screen hypothesis.

Then test the hypothesis against change ownership. Who will decide when the workflow changes? Who will approve a change to a validation rule? Who will maintain customer-specific fields? Who will own support when a user cannot complete a task? A decision that has no named owner is not ready for implementation. It usually points to a business process that needs clarification before the UI is designed.

Finally, compare the operational impact of both designs through a representative task. Have a user complete the work from a realistic starting condition, including an exception. If the extension forces excessive navigation, hidden assumptions, or mental translation, the new-screen option may be clearer. If the new screen duplicates standard actions and causes reconciliation questions, the extension option is likely safer. This is a usability and control decision, not a contest between code styles.

Back to Table of Contents

Inspect the Classic UI source before you convert

Conversion should start with evidence, not with the Convert to Modern UI command. Inspect the screen in its current environment and record what users actually do. Capture its entry points, search behavior, filters, mandatory fields, calculations, dialogs, attachments, long-running actions, imports, exports, browser assumptions, screen-specific security, and error messages. Compare these observations with the customization package and repository rather than relying on screenshots alone.

Pay close attention to behavior that is easy to miss during a visual review: ASPX or ASPX.CS code, JavaScript, CSS, automation steps, import scenarios, mobile definitions, hidden fields, graph events, workflow conditions, and integrations that target a screen or view by name. Acumatica’s converter guidance explicitly notes that JavaScript in ASPX files and code in ASPX.CS files are ignored by the customization project converter. Those items need a separate review and migration plan. [3]

Identify the acceptance conditions before any generated files are produced. For example, the condition for a sales-order extension might be that an authorized user can save a valid order, an unauthorized user cannot see a protected field, a custom action produces the right outcome, and a downstream connector receives exactly one message. Clear conditions make the generated result testable instead of merely inspectable. [3]

Back to Table of Contents

Use the converter as a baseline not as a production answer

Acumatica provides tools for converting custom and customized forms to Modern UI. For a customized form, the customization project converter compares the modern version of the original form with the modern version of the customized form and generates extension files that represent the differences. For a custom form, the converter produces TypeScript and HTML source files. The generated output is valuable because it gives the team a starting structure tied to the source screen. [2] [3]

It is equally important to respect the documented limitation: the converter does not guarantee a perfect conversion. Acumatica recommends backups, development-environment use, review of generated files, required corrections, and full testing before production publication. Treat the tool as an accelerator for an engineering review, not an approval mechanism. A clean conversion log proves less than a user completing a critical task correctly. [2] [3]

For a stock-screen extension, inspect whether the converter placed fields and layout changes at stable, intentional points. For a custom screen, inspect the resulting screen identity, view names, template configuration, IDs, and declared behavior. In either path, remove accidental complexity before adding new enhancements. Migration is the moment to clarify the design, not to carry forward every historical workaround unexamined. [2] [5]

Back to Table of Contents

Build an extension around the original screen contract

When extending a stock form, begin by reading the base form as a contract. Understand the user task, standard actions, view names, workflow states, security behavior, and the part of the layout being changed. Make each customization narrow and explainable. A reviewer should be able to answer what the extension adds, why it belongs there, what it depends on, and how it is tested.

Use the Modern UI Editor and extension files to make changes that preserve the base form’s intent. Acumatica’s UI Development Guide includes patterns for adding elements and tabs, including source-file and customization-project workflows. Follow the conventions documented for the target version rather than copying older Classic UI markup into a new template. The source form may evolve, and conventions are part of the upgrade surface. [5]

Avoid using an extension as a hiding place for unrelated process design. If a tab becomes a complete workflow with its own navigation, persistent state, queue, and support model, pause and reassess the boundary. The immediate code may still compile, but the implementation may no longer be easy for users or maintainers to reason about. Good extensions are focused differences with a clear business owner.

Back to Table of Contents

Design a new screen as a product surface

A fully owned screen deserves a brief product definition even when it serves only internal users. State the user role, trigger, task, success outcome, exceptions, data classification, permissions, performance expectation, related standard screens, and support owner. This concise definition turns a custom screen from a collection of controls into a maintained business capability.

Use a screen ID and site-map location that help users and support teams find the function. Keep the initial scope focused on the job users must complete. A custom screen does not need to expose every related field just because the underlying data model permits it. Favor a short, understandable task flow over a surrogate of several standard forms. [4] [5]

The source code should make responsibility visible. Separate data views, UI layout, actions, validation, and integration boundaries so a later maintainer can determine why an interaction exists. Write brief operational documentation alongside the package: what the screen owns, what it delegates to Acumatica, what it must never bypass, and how to recover from a partial failure. That documentation is part of the modernization investment.

Back to Table of Contents

Map TypeScript and HTML deliberately

Modern UI forms are defined through matching TypeScript and HTML files. For extensions, Acumatica documents a TypeScript mixin of the original screen class and an HTML template for UI changes. For custom forms, the TypeScript and HTML files define the form’s views and layout. The file pair should be treated as one design unit: a data view or action with no clear UI use is a maintenance question, and a control with no clear data or security contract is a defect risk. [2] [5]

Use TypeScript for the view model and behavior that belongs at the UI layer, and use HTML for a semantic, accessible layout. Name views, fields, and control IDs consistently. If the conversion tool generated IDs or template names that do not follow current conventions, correct them while the change is still isolated. Acumatica’s conversion guidance specifically calls out reviewing tag IDs, template configuration, and view-related names after generation. [2] [3]

Do not recreate backend business rules in the frontend merely to make a screen feel responsive. The Modern UI should communicate intent, availability, and feedback, while the application still enforces the authoritative rule. Test stale data, concurrent updates, invalid values, and unavailable dependencies. A pleasing interface that accepts an invalid transaction is more dangerous than a visibly unfinished layout.

Back to Table of Contents

Keep business logic and UI migration separate

A screen conversion can expose business logic that was previously hidden in Classic UI artifacts. Separate the question of how the form looks from the question of where business rules execute. Graph extensions, DAC extensions, workflow logic, data validation, integrations, and authorization controls may need their own reviews. Do not treat a UI conversion as proof that the underlying behavior remains correct. [7]

This separation makes troubleshooting more efficient. If a user cannot see a control, investigate the UI definition and permissions. If a control is visible but an action fails, investigate the action’s conditions, graph logic, integration, or data state. If a result saves but produces an incorrect downstream document, investigate business logic and reconciliation. Keeping these hypotheses distinct prevents teams from changing layouts to mask deeper defects.

It also improves deployment decisions. A team can validate the Modern UI layout in one development cycle while preserving a known business-rule baseline, or it can deliberately schedule a rule change with its own acceptance criteria. Bundling unrelated changes makes the eventual defect difficult to reproduce and obscures whether a migration or a new feature caused it.

Back to Table of Contents

Plan for security roles and data exposure

A conversion is complete only when the right people can perform the right task and the wrong people cannot access protected data or actions. Inventory roles, branches, companies, restrictions, approval conditions, attachments, and reporting paths before testing. A developer or administrator account can conceal defects because it sees controls and records that ordinary users should never see. [7]

Test the Modern UI screen with production-like roles. Confirm that fields appear or remain hidden intentionally, selectors are scoped correctly, actions respect approvals, and error messages do not reveal sensitive data. If a custom screen has a distinct security model, document it in user language as well as technical configuration. Security is easier to support when users understand why a control is unavailable.

Treat integrations and exports as data-exposure paths too. A screen may appear secure while an export, generic inquiry, API endpoint, or downstream connector makes data available elsewhere. The custom-screen inventory should note each of these paths and the owner responsible for reviewing them when a new field or action is added.

Back to Table of Contents

Test work not just screens

A Modern UI screen that opens successfully has passed a smoke test, not acceptance. Build test scenarios around user work. Include a normal path, a validation error, an approval or security exception, a concurrent-edit situation, an integration or reporting consequence where relevant, and a recovery step. Capture expected results and evidence for each scenario so the team can distinguish a retest from an assumption. [2] [7]

For an extension of a stock order screen, test more than the custom tab. Create, edit, copy, hold, release, cancel, print, import, export, approve, and integrate as the production process requires. For a custom screen, test its own flow plus the standard data it reads or writes. This approach exposes problems that a control-by-control test misses, including workflow state changes and downstream side effects.

Include browsers, devices, record volumes, and user roles that match the operating environment. If the screen supports a warehouse, manufacturing, construction, finance, or field process, observe a knowledgeable user completing a real scenario. Their hesitation, workarounds, and misinterpretations are design findings. Address them before go-live rather than documenting a workaround after it.

Back to Table of Contents

Publish through controlled environments

Keep the conversion in a development environment until generated files have been reviewed and task-based testing passes. Acumatica’s documentation advises backups, development use, review of generated output, corrections, and full testing before production publication. Follow that sequencing even when a conversion seems small; production risk is determined by the business process around the screen, not the number of files changed. [2] [3]

Use a controlled package set and record the target Acumatica build, customization versions, dependencies, publication order, build logs, test evidence, known limitations, rollback point, and approvals. When a package is updated, retest the workflows it touches rather than assuming a successful publication means a safe release. The same discipline helps when the next Acumatica upgrade changes a base form or behavior. [7]

Have an explicit decision for defects found late in testing: fix and retest, disable the new function, accept a documented risk with a business owner, or defer the upgrade. Do not rely on temporary Classic UI use as the standard contingency for a screen that is moving toward Modern UI. A supported fallback is valuable during diagnosis, but it is not a long-term design strategy. [1] [6]

Back to Table of Contents

Make the migration easy to support next year

A readable implementation is the best upgrade preparation. Store source files in version control, document screen ownership, use descriptive names, keep a current package manifest, and record why extension or new-screen was chosen. Link test scripts and acceptance evidence to the screen inventory. A future team should not have to rediscover whether a change was intentional, accidental, or obsolete.

Review every custom screen after a major Acumatica release or a major change to the affected business process. The review should ask whether the original ownership decision still holds, whether the base form now provides a supported option, whether the extension depends on changed UI elements, and whether the test pack covers current roles and integrations. Retirement can be a valid outcome when the original need has disappeared.

Add a lightweight feedback loop for users. Ask where they leave the screen, what they export to spreadsheets, which fields cause repeated questions, and which exceptions require support. These observations help distinguish a true missing capability from a training or naming problem. They also make the next modernization decision evidence-led rather than opinion-led.

Back to Table of Contents

A practical conversion sequence

First, inventory and classify the screen. Confirm whether it is a stock-form customization, a fully custom form, or an unknown asset requiring discovery. Name the business and technical owners, capture dependencies, and state the acceptance conditions. This is the architecture gate; do not start conversion until it is complete.

Second, prepare a safe development environment with a representative package set and data conditions. Run the appropriate Acumatica conversion workflow, then review generated TypeScript and HTML alongside the source behavior. Correct conventions, layout assumptions, and migration gaps. Keep a change log that identifies generated output versus deliberate edits. [2] [3]

Third, validate business behavior through task-based testing with realistic roles and data. Confirm security, workflow, integrations, reports, exception handling, performance, and recovery. Publish to the next controlled environment only when the evidence supports it. Finally, update documentation and training so users know the Modern UI path before production cutover. [1] [7]

Back to Table of Contents

Common conversion mistakes to avoid

Do not choose a new screen because the stock screen is complicated. Complexity may be a reason to improve training, simplify an extension, or limit the user task. A parallel screen creates a new lifecycle and reconciliation risk unless it genuinely owns a distinct workflow.

Do not assume the converter handles every old artifact. Review JavaScript, ASPX.CS, external calls, import scenarios, custom CSS, and automation deliberately. Generated files can provide a strong starting point without preserving every behavior that grew around the Classic UI screen. [3]

Do not test only as an administrator. Modern UI conversion changes how users locate, enter, and recover from work. Role-based testing identifies permissions and usability issues that an elevated account hides. And do not set the final implementation choice in code before a business owner has agreed on the process it is meant to support.

Back to Table of Contents

Establish a conversion backlog that reflects operational risk

Once the ownership inventory exists, turn it into a conversion backlog rather than a list of screens. Each item should state the operational process it supports, the reason it belongs in the release, the proposed implementation boundary, the target environment, dependencies, and a definition of done. A backlog entry that says only “convert INxxxxxx” describes effort but not business value. A useful entry says which role must be able to complete which task and which evidence will prove it.

Rank items by consequence and exposure. A customization used once a quarter may still outrank a daily screen if it controls a major payment, compliance action, period close, or incident response. Conversely, a visually prominent screen may be a low priority if it is a convenience view with a safe workaround. Capture frequency, business impact, data sensitivity, integration coupling, user count, and availability of a manual fallback. These factors make sequencing defensible when time is limited.

Separate modernization work from new feature requests in the backlog. A migration may reveal a chance to redesign a queue, add a dashboard, or simplify a workflow, but a large enhancement can obscure whether the Modern UI baseline is stable. Where possible, first establish an accepted conversion that preserves the required business outcome; schedule optional improvement with its own business case and test scope. This produces clearer diagnosis and more honest delivery commitments. [7]

Back to Table of Contents

Handle actions dialogs and asynchronous work explicitly

A screen is more than fields and grids. Inventory every action, dialog, confirmation, file operation, long-running process, and status message that users rely on. For each, state the preconditions, success signal, error behavior, security requirement, and downstream result. This is especially important when users trigger a task that continues after the screen stops responding synchronously; the Modern UI needs to make it clear whether the request started, completed, failed, or needs follow-up. [5]

Avoid replacing a well-understood business action with a generic button that conceals its outcome. If an action releases documents, opens a processing queue, creates a record, or starts an integration, the UI should guide the user to the appropriate evidence: a document number, status, exception view, or confirmation with next step. A success toast by itself is rarely enough for a financial or operational action. The design should support the user’s responsibility to verify the outcome.

For dialogs, test both the happy path and interruption. Users may close a dialog, submit incomplete values, lose a network connection, reopen the same record, or trigger the operation twice. Define idempotency and recovery behavior with the backend owner where the action touches an integration or creates a transaction. That discussion belongs in the conversion design even when the visible UI change is small.

Back to Table of Contents

Treat data views and performance as design decisions

The right screen boundary also depends on how much data it needs. An extension that adds one calculated field to a supported view is fundamentally different from a new workbench that loads high-volume operational data, combines multiple data sources, and drives repeated updates. Before implementation, define the record volume, common filters, sort order, branch or company scope, expected concurrency, and the maximum response time that keeps the process usable.

Measure performance with representative data and a repeatable task. Record screen load, search or inquiry execution, action completion, dialog responsiveness, and any downstream processing time. Capture the filters, row counts, role, browser, and time of test so a later result can be compared fairly. Avoid promising a generic speed improvement; a result observed on one tenant or dataset may not carry to another. [7]

Use the measurement to choose a user-centered design. A workflow may need a narrow initial query, explicit search criteria, a summarized queue, or a drill-through path rather than a single screen that attempts to show every record. Performance changes behavior: users work around slow screens by exporting, refreshing, or maintaining shadow data. A modernized screen should reduce those incentives, not simply change the presentation layer.

Back to Table of Contents

Preserve auditability and financial controls

For screens that affect money, inventory, approvals, or regulated records, define the control evidence alongside the UI acceptance criteria. Confirm which fields are authoritative, what values are calculated, who may override a result, where approvals occur, what event history is retained, and which report or inquiry reconciles the output. A conversion can preserve the visible layout while breaking a reviewer’s ability to understand what happened.

Test the complete control chain. A user may enter a record correctly but create a downstream posting, release, tax result, allocation, or integration message that is incorrect or incomplete. Include report review and reconciliation in the test case where they are part of the business control. Document acceptable differences and the role authorized to accept them. This gives the go-live decision an evidentiary basis rather than a collection of screenshots. [7]

Be careful with convenience features that bypass normal review. A custom action that updates multiple records, changes a status, or sends a message can save time, but it needs explicit authorization and recoverability. Design confirmations, restriction checks, history, and exception handling to match the action’s consequence. In a Modern UI conversion, retaining a control intentionally is often more valuable than reproducing a legacy shortcut exactly.

Back to Table of Contents

Plan user adoption as part of the technical release

Users judge the conversion by whether they can finish their work, not by whether the project generated TypeScript and HTML. Start role-based readiness early. Identify the first screen each role opens, the records they need to find, the decisions they make, the actions they can take, and the exceptions they must recognize. Translate this into brief task guides and practice scenarios that use the final Modern UI configuration rather than draft screenshots. [1] [7]

Train on differences that affect decisions or control, not every cosmetic change. A purchaser may need to know a revised approval cue and a new location for an attachment; a warehouse lead may need to know how a custom queue prioritizes work; a finance reviewer may need to know how to reconcile a converted process. Give each group a safe environment and a realistic task, then capture questions that reveal ambiguous labeling, gaps in permissions, or undocumented exception paths.

Update support materials at the same time. Searchable job aids, service-desk triage notes, escalation routes, and screen-owner contacts reduce the temptation to revert to an older UI or keep a private workaround. Remove instructions that direct people to Classic UI when the Modern UI path is the approved process. Documentation is a migration dependency because stale guidance can create production defects after the code has been accepted. [1]

Back to Table of Contents

Use source control and release discipline for UI files

Store Modern UI source files and the customization package in a version-controlled location with a branch or tagging practice that identifies the Acumatica target version. Review changes in small, explainable units. A reviewer should be able to see whether a commit updates a layout, action, view, permission boundary, or generated baseline. Avoid mixing generated conversion output, unrelated refactoring, and new features in one unreviewable change set.

Document the procedure for moving modified source files between the development folder and the customization project. Acumatica’s guidance describes reviewing and editing generated files, including work performed in the development folder and subsequent detection or inclusion of modified files. The exact practice should follow the current product documentation and the team’s deployment model, but the governing principle is stable: the package published to a test environment must be traceable to reviewed source. [2] [3]

Keep a release note for every screen that records the changed workflow, migration classification, dependencies, target build, evidence links, remaining limitations, and rollback approach. This does not need to be verbose. Its purpose is to prevent future teams from guessing whether an extension may be safely regenerated or whether a custom screen carries hand-authored behavior that needs special care during the next conversion cycle.

Back to Table of Contents

Set concrete exit criteria before the production decision

The production decision should be based on exit criteria that both the business owner and technical owner understand. At a minimum, confirm that the implementation boundary is recorded, source changes are reviewed, the customization publishes in the target test environment, critical role-based tasks pass, material defects have owners and dates, and the release team can explain the fallback or recovery action. A completion percentage is less useful than this evidence because percentages do not reveal which control or process remains at risk.

Make the criteria specific to the screen’s consequence. A simple inquiry may need accuracy checks, role testing, a performance baseline, and user sign-off. A screen that releases documents or affects inventory should additionally have downstream reconciliation, approval checks, duplicate-prevention tests, integration monitoring, and a confirmed recovery path. The goal is to create enough evidence for an informed decision without pretending that every screen requires the same heavyweight protocol. [7]

Agree on severity language before testing starts. A blocker prevents an essential process, security boundary, financial control, or recovery path. A required-before-go-live defect has a planned correction and retest. An accepted risk has a defined impact, a named owner, an approved workaround, and a date for follow-up. An improvement is useful but does not affect safe operation. This vocabulary prevents a late review from treating every finding as either a disaster or an inconvenience. [7]

Preserve the evidence in a place the next release team can find. Link the screen inventory to test records, defect references, package version, review notes, user materials, and final decision. A later upgrade often begins with a question about why a certain implementation was chosen or what it depends on. A compact evidence trail reduces the effort to answer that question and makes the next conversion cycle safer.

Back to Table of Contents

Revisit the decision when the process changes

The extension-versus-new-screen choice is not a one-time label. Revisit it when a stock form receives a major product change, an extension accumulates a separate workflow, a new screen begins to duplicate standard functionality, or a business process changes owner. The review can be brief, but it should answer whether the existing boundary is still clear to users and maintainers. Modernization is successful when the implementation continues to match the operating model, not merely when it once passed conversion tests.

This review should include the people who operate the process as well as the people who maintain the customization. Technical teams see dependencies and upgrade risk; business teams see workarounds, exceptions, and decisions that are not obvious in code. Combining both perspectives makes it easier to retire accidental complexity, preserve necessary controls, and schedule changes before an upgrade turns them into urgent work.

Keep the review factual. Look at support incidents, time spent on rework, unfinished task rates, authorization failures, reconciliation differences, user feedback, performance records, and new product guidance. These are better inputs than a general impression that the screen feels old or new. A small, well-supported adjustment to the architecture can be more valuable than a large visual rewrite that leaves the operating problem unchanged. Review dates should follow real evidence, not a calendar-driven claim of freshness. If a release changes no relevant dependency, record that conclusion clearly and retain the existing test baseline. If evidence shows repeatable confusion or control failure, put a specific corrective action into the product backlog and verify it with the affected role after the change is implemented.

Back to Table of Contents

How Biz Tech can help

Biz-Tech Services can help teams turn a screen inventory into a prioritized Modern UI conversion plan, review extension and custom-screen boundaries, and build a testable release path around real operational workflows. The right starting point is a focused assessment of high-consequence screens and the packages, integrations, and roles that depend on them—not a blanket rewrite estimate. [7] [8]

A useful engagement produces decisions your team can act on: which screens should be extended, which require a new-screen design, which can be retired, what must be tested, and what evidence is needed before the next upgrade. That creates a practical roadmap while preserving the business controls that make the ERP system dependable.

Back to Table of Contents

Frequently Asked Questions

Do all Acumatica customizations need a Modern UI rewrite?

No. Acumatica states that many business-logic customizations can remain relevant, while UI-specific work needs review and validation. Start with an inventory and separate business rules from UI artifacts. Convert or redesign the parts that depend on Classic UI behavior. [1] [6]

What is the difference between a custom form and a customized form?

A custom form is a screen the customization owns, while a customized form changes an existing Acumatica form. In the documented conversion workflow, custom forms produce Modern UI source files and customized forms produce extension files representing their differences from the original form. [2] [3]

Can Acumatica convert a screen automatically?

Acumatica supplies conversion tools for custom and customized forms. They accelerate a baseline conversion, but the documentation says they do not guarantee a perfect result. Review generated files, correct issues, and fully test before production publication. [2] [3]

When should I extend a stock Acumatica screen?

Extend it when users still perform the stock screen’s primary job and the change is focused: a field, tab, action, dialog, localized layout adjustment, or other contextual addition. Confirm the extension does not silently become a separate workflow. [2] [5]

When should I build a new Acumatica Modern UI screen?

Build a new screen when the workflow, navigation, ownership, and user experience are genuinely distinct from a stock form. Plan for the full lifecycle: security, views, actions, testing, documentation, support, and upgrade maintenance. [4] [5]

What should I test after conversion?

Test the work users perform: normal and exception paths, permissions, approvals, validation, downstream documents, integrations, reports, concurrency, performance, and recovery. Include representative roles rather than testing only as an administrator. [2] [7]

Will Classic UI still be available in 2026 R2?

Acumatica’s current 2026 R2 documentation says Modern UI is the default and Classic UI is disabled by default. Classic UI-only forms remain a transition concern with warnings, and Acumatica identifies 2027 R1 as the next milestone for their removal. Recheck official release guidance for the target build before a production decision. [1]

What happens to Classic UI JavaScript or ASPX.CS behavior?

Do not assume it moves automatically. Acumatica’s customization project converter documentation says it ignores JavaScript in ASPX files and code in ASPX.CS files. Review those artifacts separately and decide how each behavior should be handled in the target design. [3]

Can a converted extension be maintained through future upgrades?

Yes, when it is narrow, documented, version-controlled, and tested against the target release. Reassess dependencies on base-form layout, element IDs, workflows, and permissions on each upgrade rather than treating a past conversion as permanent proof of compatibility. [2] [5]

What is the first deliverable for a Modern UI conversion program?

Create a screen inventory with ownership, dependencies, risk, classification, and acceptance conditions. That document makes it possible to prioritize high-consequence work and choose an extension, new screen, replacement, or retirement deliberately. [1] [7]

Back to Table of Contents

Sources

Back to Table of Contents

Privacy Preference Center

Privacy Preferences