NetSuite Next Compatibility Testing: What to Review First

NetSuite Next compatibility testing should start with customizations that directly manipulate HTML or depend on page structure—not a blanket rewrite of custom scripts. Apply this guidance only to accounts whose profile menu includes Exit NetSuite Next.

Most custom scripts do not require changes. The practical priority is to compare affected client scripts, form customizations, and portlet scripts across both experiences, document differences, and decide whether changes are justified.

Key takeaways

Confirm that Exit NetSuite Next is present before applying this switching-specific guidance.
Prioritize HTML and page-structure dependencies, not customization categories alone.
Scripts, custom records, workflows, and other customizations are expected to continue working; that is not a guarantee of identical behavior.
Compare affected forms and portlets through representative user tasks.
Saved transactions and records are visible in both experiences. That assurance does not establish behavior for unsaved changes.

Confirm that this guidance applies to your account

Before creating a compatibility backlog, check the profile menu for Exit NetSuite Next. Record the result with the account and testing context. If the option is absent, this guidance does not establish what switching or compatibility testing applies to that account.

For related navigation and access context, use the NetSuite Next switching and role access guide.

This scope check is not an additional access requirement. Similarly, asking representative users to validate existing roles, permissions, and workflows is a testing recommendation—not a requirement to recreate those configurations.

For administrators, the first planning decision is therefore straightforward: establish the scope, then identify representative work to validate. Avoid turning an interface compatibility review into an account-reconfiguration project without evidence that changes are necessary.

What stays the same in NetSuite Next?

NetSuite Next changes the user experience while using the same underlying account, data, roles, permissions, workflows, and customizations. Treat the switch as a changed interaction experience, not a data migration.

That distinction changes the testing question. Rather than checking whether a second account received the correct records, ask whether users can complete representative tasks through the changed experience using their existing account context.

Area	Grounded expectation	Recommended validation
Data and saved records	The underlying account is shared; saved records are visible in both experiences	Locate a representative saved record in each experience
Roles and permissions	Users continue with the same roles and permissions	Exercise representative work with the relevant existing role
Workflows	Users continue with the same workflows	Include workflow-related tasks in representative testing
Scripts and other customizations	They are expected to continue working; most custom scripts need no changes	Prioritize interface-dependent customizations

Keep the conclusions separate. Finding a saved record in both experiences supports the shared-record expectation; it does not demonstrate that every customized interaction on that record's form behaves identically.

Which customizations should you review first?

Use dependency on interface details as the first sorting criterion. Client scripts, form customizations, and portlet scripts are specifically identified for review when they directly manipulate HTML or page structure. Their category tells you where to look; their implementation determines why they warrant priority.

Ask the customization owner to describe what the implementation assumes about the displayed page. If its intended behavior relies on particular HTML or page structure, place it in the first testing group. If the dependency is uncertain, request an implementation review rather than labeling the customization incompatible.

Review group	Reason for placement	Recommended next action
Known direct HTML or page-structure dependency	Matches the stated review priority	Test the affected form or portlet in both experiences first
Dependency not yet understood	Evidence is insufficient to assign a confident priority	Have the owner identify the implementation's interface assumptions
No direct interface dependency identified	Does not match the primary review boundary	Include in representative validation without assuming a rewrite

Within the first group, use business importance to choose the testing order. An affected interaction that users rely on frequently is a sensible starting point. This is a planning recommendation, not a prediction that the customization will fail.

Client scripts: connect implementation assumptions to user tasks

For each prioritized client script, document the triggering user action, intended result, affected form, and known page dependency. Test the interaction in both experiences.

For example, if an implementation review identifies a dependency on a particular page structure, use that finding to select the interaction for comparison. The dependency is a reason to test—not proof of a defect. Conversely, reading the implementation is not a substitute for observing whether the user can complete the task.

Form customizations: separate presentation from task completion

Define the task before comparing the form. Record a visual difference separately from an inability to complete an intended action. This helps reviewers decide what needs investigation without treating every presentation change as a functional failure.

If the inventory includes customized views, the guide to customizing NetSuite views and UI behavior provides related background. It is not a compatibility verdict for the implementation being tested.

Portlet scripts: define the output and interaction to check

Identify the portlet's intended output and any user interaction included in the test. Prioritize implementations with direct HTML or page-structure dependencies, then compare their behavior across experiences.

Record conclusions at the level actually tested. A successful portlet test does not establish compatibility for unrelated forms or other portlets.

For developers inventorying related form-building work, the Suitelet Sublist object members reference offers implementation background. It does not replace testing the affected interface.

A repeatable compatibility testing procedure

The source recommends exercising affected forms and portlets in both experiences and documenting differences before deciding whether changes are necessary. The following procedure turns that recommendation into a repeatable comparison; it is not a NetSuite-mandated test protocol.

Choose an affected customization. Record its category and known HTML or page-structure dependency.
Define the task. Describe the user action and intended result clearly enough for another tester to repeat the check.
Set a comparable context. Where practical, use the same existing role and a comparable record or task context. This helps keep unrelated differences from obscuring the result.
Exercise the task in NetSuite. Record what happened and whether the intended action could be completed.
Exercise the corresponding task in NetSuite Next. Capture the result independently rather than inferring equivalent behavior from a similar appearance.
Classify the finding. Distinguish presentation differences, task failures, and uncertain results that need investigation.
Decide whether a modification is justified. Use the observed result and implementation review, not the customization category alone.
Repeat the comparison after a change. Reuse the task definition so the results remain comparable.

Keep a compact evidence record for each finding: customization name, affected interface, role context, steps, expected result, actual result in each experience, and owner. These are recommended test-plan entries, not NetSuite field IDs.

For administrators, this evidence connects the review to existing roles and everyday work. For developers, it connects an observed difference to a specific implementation assumption. For business testers, it makes the expected outcome explicit instead of asking whether the interface merely “looks right.”

When a result is uncertain, describe the uncertainty precisely. “The task could not be completed in this comparison” is more useful than a broad declaration that all custom scripts are incompatible. Likewise, a successful comparison supports the tested task, not an account-wide compatibility certification.

Verify saved transactions across experiences

Transactions and other data are stored in the same underlying account. Saved transactions and records are therefore visible in both NetSuite and NetSuite Next.

Include a direct visibility check, but track it separately from interface compatibility findings:

Choose a representative transaction appropriate for your testing process.
Save it in one experience.
Record enough identifying information to locate that exact transaction again.
Find the saved transaction in the other experience.
Record the outcome separately from form or script behavior.

This checks the shared-record expectation. It is not a migration reconciliation exercise, and it does not validate every customization involved in creating or displaying the transaction.

The saved-state boundary matters: the source's visibility assurance does not establish what happens to unsaved changes when switching experiences. Save first when testing cross-experience record visibility. Do not treat an unfinished transaction as evidence for or against the assurance about saved records.

FAQ

Do all custom scripts need changes for NetSuite Next?

No. Most custom scripts do not require changes. Prioritize those that directly manipulate HTML or depend on page structure, and test before deciding on modifications.

Which customizations should I test first?

Start with HTML- or page-structure-dependent client scripts, form customizations, and portlet scripts. Within that group, a practical approach is to test the most business-important interactions first.

Does this guidance apply to every account?

No. It applies only to accounts whose profile menu includes Exit NetSuite Next. Confirm that option before using this switching-specific testing plan.

Are saved transactions visible in both experiences?

Yes. Save a representative transaction in one experience and locate it in the other to check visibility. Keep that result separate from conclusions about customized interactions or unsaved work.