How to Audit and Clean Up Unused NetSuite Customizations
Introduction
Every NetSuite account accumulates customizations over time. Scripts are added to solve problems. Custom fields are created for one-time data needs. Workflows are built for processes that later changed. Saved searches are created by users who leave, and the searches remain. SuiteApps are installed to evaluate capabilities that were never adopted.
The accumulated weight of unused customizations has real costs: scripts that still execute on every page load even though no one uses their output, custom fields that clutter every transaction form, workflows that evaluate conditions on every save event for a process that no longer exists, and SuiteApps that consume license seats and introduce upgrade complexity without delivering business value.
A systematic customization audit identifies what can be safely removed, what should be consolidated, and what needs to be refactored to remain upgrade-safe. Our NetSuite customizations services and NetSuite optimization services teams conduct this type of audit as a standalone engagement or as part of a broader performance improvement project.
Why Customization Audits Are Overdue in Most Accounts
Customizations are almost always added but rarely removed. The incentive to add is clear — someone has a need, a customization solves it. The incentive to remove is weak — no one tracks whether an existing customization is still in use, and removing something functional risks breaking something, so the default is to leave it.
NetSuite accounts two to four years old typically have several hundred custom scripts, fields, workflows, and searches — a meaningful fraction of which are either unused or duplicative. Each one contributes to slower page loads, harder upgrade management, more complex onboarding for new administrators, and a codebase that becomes progressively more difficult to understand and maintain.
Auditing Script Deployments
Script deployments are the highest-impact area to audit for performance. Every deployed script — whether it does anything useful or not — executes when its trigger conditions are met. A script deployed to "All Transactions" that was built for a process that ended two years ago still runs on every transaction save, consuming governance and adding latency.
Start by pulling a complete list of script deployments (Setup > SuiteCloud > Scripts). For each script, identify: when it was last executed (Script Execution Log), which users or processes trigger it, what business process it supports, and whether that process still exists. Scripts with no recent execution history and no documented owner are strong candidates for deprecation.
Before removing any script, disable the deployment and monitor for reported issues over one to two business cycles. This staged approach prevents the risk of removing something that turns out to be load-bearing but infrequently triggered.
For ongoing management, implementing SuiteCloud Development Framework version control ensures that scripts are tracked in source control and can be restored if a removal turns out to be premature.
Auditing Custom Fields
Custom fields are among the most pervasive sources of clutter in a mature NetSuite account. Transaction body fields, line fields, and entity fields accumulate as each project team creates the fields they need without a central review process. The result is transaction forms with 50 or 100 fields, most of which are empty on most records.
To audit custom fields, run a saved search across the relevant record type that includes each custom field as a column. Filter for records where the field has a value. A custom field with no values on any record — or values only on a handful of records from years ago — is a strong candidate for removal.
Also look for custom fields that duplicate standard NetSuite fields. A custom "Customer Notes" field on the transaction form may duplicate the standard Memo field. A custom "Expected Ship Date" may duplicate the native Ship Date field. These duplicates create data entry confusion and data integrity problems.
Removing custom fields permanently deletes their data. Before any field removal, export the data for any fields that have values, confirm that the data is not needed, and archive it appropriately.
Auditing Workflows
Workflows should be audited for both activity and relevance. The Workflow Action History (Setup > SuiteCloud > Workflow Action History) shows recent workflow executions. A workflow with no recent activity may be dormant — either because it has no eligible records or because the process it supports no longer generates triggering events.
For each inactive workflow, trace back to the business process it was designed to support. If that process no longer exists or has been replaced by a different workflow, the old workflow should be disabled and documented before removal. Workflows that are partially superseded — where some states are still in use but others are dead ends — need to be restructured rather than simply removed.
Workflow auditing is closely connected to workflow optimization — the same review that identifies unused workflows also surfaces opportunities to consolidate redundant ones and improve the ones that remain.
Auditing Saved Searches
NetSuite accounts accumulate saved searches rapidly because they are easy to create and there is no friction to their persistence. A user creates a search for a one-time project, saves it publicly, and it remains indefinitely — consuming no server resources at rest, but cluttering the search list for everyone and potentially being called from scripts or workflows that later break when the search is modified.
Audit searches by owner and last-used date. Searches owned by inactive users that have not been accessed in over a year should be evaluated for removal. Public searches should be reviewed for whether they contain sensitive data that should not be broadly accessible. Searches used in scripts or workflows should be documented so that dependencies are understood before any cleanup occurs.
Auditing Installed SuiteApps and Bundles
SuiteApps and bundles installed during evaluation or early implementation sometimes remain in the account long after the decision was made not to adopt them. Each installed bundle may add scripts, custom records, custom fields, and workflow components that contribute to the account's customization footprint even if no one actively uses the application.
Review installed bundles (Setup > SuiteCloud > Installed Bundles) and identify any that are not actively used in a business process. Uninstalling a bundle removes its associated components, which can have significant cleanup value. Always test bundle uninstallation in a sandbox first — some bundles create dependencies in scripts or workflows that are not immediately obvious.
Documenting What Remains
A customization audit is most valuable when it produces not just a cleaner account but better documentation of what remains. Every script, workflow, and custom field that survives the audit should have a clear record of: what business process it supports, who owns it, when it was last reviewed, and what the impact would be of removing it.
This documentation prevents the next audit from starting at zero. It also provides the context that new administrators need to make safe configuration changes — and that auditors need when reviewing the account's customization architecture for compliance purposes. Pairing documentation with SDF version control creates a complete, auditable record of the account's configuration state.
The Performance Impact of Cleanup
The performance gains from a thorough customization audit can be significant. Removing ten script deployments from a high-traffic record type eliminates ten sources of page load latency. Removing dozens of custom fields from transaction forms reduces the data the server must load and render on every form open. Disabling dormant workflows eliminates condition evaluation overhead on every relevant save event.
These gains compound. Each removed customization makes the account faster, simpler, and easier for subsequent administrators to understand and modify. For accounts that have never had a systematic cleanup, a customization audit often produces performance improvements comparable to targeted script performance optimization — with less risk, because the work is removal rather than modification.
Why Work with SixLakes Consulting
A customization audit requires deep familiarity with NetSuite's architecture and the confidence to distinguish between a customization that is safe to remove and one that appears dormant but is actually load-bearing. SixLakes Consulting brings experience conducting customization audits for accounts of varying complexity, with a methodology that stages removal carefully to prevent disruption.
We deliver a cleaner, faster, more maintainable account — with documentation that gives your team the context to manage it going forward. Our NetSuite customizations services cover both the cleanup work and the rebuild or refactoring of customizations that need to be improved rather than removed.
Conclusion
Unused customizations are a hidden tax on every user in your NetSuite account. They slow pages, complicate upgrades, confuse new administrators, and accumulate over years without anyone noticing because their individual cost is diffuse.
A systematic audit and cleanup engagement concentrates that diffuse cost into a one-time project — and delivers a lasting performance improvement, a cleaner codebase, and a documented customization inventory that makes every future change faster, safer, and less expensive to implement.