Marty Zigman - The NetSuite Expert

Conversations with Marty Zigman

Certified Administrator • ERP • SuiteCloud

Prolecto Labs Accelerator Templates

Best Practices for Addressing NetSuite’s Easily Accumulated Technical Debt

ERP Infrastructure Management NetSuite Strategy



This article is relevant if you see performance issues in NetSuite and are concerned that changing the configuration will introduce software instability or errors.

Background

The NetSuite ERP system is not unique in its tendency to accumulate technical debt (tech debt). Technical debt represents the hidden cost of past decisions, which later emerge as obstacles to adaptability, performance, and user trust.

Understanding this phenomenon is critical for organizations aiming to fully realize NetSuite’s potential. Technical debt poses significant challenges, particularly when adapting the system to accommodate new business logic. As technical debt grows, previously stable processes can become prone to bugs, frustrating users and eroding trust in the platform. Each change requires more extensive testing to ensure stability, increasing costs and slowing the pace of innovation. Additionally, system performance often degrades over time, making the environment feel sluggish and diminishing user satisfaction and confidence in its reliability. Recognizing and addressing these impacts is essential for maintaining a scalable, effective NetSuite environment.

Regular readers of the blog may notice that this article is longer than usual. However, it was essential to delve deeply into the considerations behind this phenomenon, as it drives a complete market cycle that is critical for organizations with meaningful growth ambitions.

Why Does Understanding NetSuite Technical Debt Phenomenon Matter?

Understanding the NetSuite technical debt phenomenon is essential because it directly influences an organization’s ability to grow, innovate, and maintain user trust.  As transaction volumes increase and customer needs become more complex, NetSuite must be flexible enough to accommodate new demands.  When that adaptability is constrained by the symptoms of mounting technical debt, growth is stifled, and the costs of maintaining and updating the system climb significantly.   As organizations begin to understand the phenomenon, they recognize that each change introduces additional risks, prompting NetSuite analysis teams to become more cautious and slowing the pace of progress.

Hence, NetSuite technical debt is the hidden cost of earlier decisions, now manifesting as barriers to adaptability, performance, and user trust.

NetSuite Fundamentals Leading to Rapid Tech Debt Growth

NetSuite’s adaptability is a double-edged sword. Its layered architecture for enhancement enables powerful customizations, but unchecked growth in these layers can create significant challenges, accelerating tech debt.  The things we love about the platform come with the responsibility of care and maintenance, a cost that ensures we can continue to rely on and benefit from it.

Let’s examine the NetSuite architecture and consider the hidden concerns:

NetSuite’s Core Product

The base system of NetSuite, often referred to as “The Core Product,” is configured using switches and options (e.g., Setup, Company, Enable Features).  This platform area is crafted and offered entirely by the Oracle NetSuite team. To keep things streamlined, it is best to activate only the essential switches and features, minimizing complexity and ensuring the system operates efficiently to meet the direct business requirements.  Our firm has often encountered new clients with configurations bloated with meaningless (at best) or potentially conflicting (at worst) optionality.  Once things are on, it becomes risky or impossible to deactivate.

NetSuite Point-and-Click Customization

This first layer of innovation enables flexibility but begins to introduce possible complexity.  I call these Hells, which NetSuite Administrators will recognize when they are in them:

  1. Business Form Hell:  the proliferation of forms to meet varied needs, such as customized PDF outputs.  Once you have more than 3 forms for the same function, changes to logic or field displays require updates across multiple form definitions, making testing cumbersome and error-prone.  Depending on the approach, users may be confused about which one to use.  One begins to understand the power of one or two forms with centralized logic and tools such as our license-free Content Renderer Engine, which breaks out of the one-to-one relationship between the related PDF definitions.
  2. User Role Hell: here, role definitions lose clarity with an explosion of user roles that lack meaningful structure or alignment within the business context and the functional groups of users in the organization. This can easily happen during mergers and acquisitions or simple requests to secure a new business function for a limited number of people in the organization.  The fear of deactivating roles due to potential business disruptions compounds the problem basically making it fester.
  3. Report, Saved Search, and SuiteAnalytics Workbook Hell: end users create numerous reports, searches, and workbooks without organizational oversight.  These outputs lack business alignment and thus create confusion, mistrust in data accuracy, and difficulty in retiring obsolete structures that may be tied to scripts or workflows.  A growing list of “who knows what does what and who uses it” structures exist in the environment—administrators tiptoe nervously, hesitant to act. At worst, business users develop conflicting interpretations of common business metrics.
  4. Custom Fields/Record Types Hell: unmanaged custom fields and table growth increases system complexity.   Poor documentation and alignment lead to bloated maintenance efforts and harder debugging.   More objects are carried around at the risk of worrying about breaking anything by removal or change.

While we love NetSuite’s point-and-click customization, it is no wonder we may eventually drift into hell.

NetSuite Platform Customization

The platform extensibility layer introduces significant capacity for enhanced business logic but also carries significant risks.

  1. Workflows:  designed for business analysts to easily create logic, workflows proliferate rapidly.   Logic elements are difficult to order.  Complexity is a pretty user interface on top of a spaghetti-code-like mess.  Over time, overlapping workflows make it challenging to trace how logic executes across record events (record loading, editing, and updating).
  2. Scripts: the backbone of advanced customizations, scripts provide robust capabilities for developers.  Scripts will generally layer on top of existing logic, creating an opaque and fragile environment where understanding dependencies becomes difficult.  It’s all too easy to introduce a brand new script than to take an existing piece of related code and interweave intelligently the logic we need.
  3. External Applications: as more external applications get bolted onto NetSuite via REST(lets), SOAP, or other, it may become difficult to understand if a change will break a dependent application.

The platform is clearly one of NetSuite’s strengths (our business depends heavily on it) for addressing and adapting to business requirements. Yet, a growing responsibility for managing that logic lies within the organization — and many are not prepared.

Why is Tech Debt So Easy to Create in NetSuite?

Managing NetSuite effectively requires vigilance, strategic planning, and a disciplined approach to customization.  However, with none of that in mind, consider these situations:

  1. Ease of Adding Logic: NetSuite’s innovation layer simplifies the process of embedding logic — most often without thoroughly considering existing workflows or dependencies.
  2. Lack of Coordination: Multiple parties (e.g., developers, administrators, consultants) can independently introduce logic without a unified strategy or respect for pre-existing configurations.
  3. Application Add-Ins Growth: Third-party add-ins (even all those that are “Built-for-NetSuite”) can quickly inflate technical debt. While they are often better isolated, these applications still introduce complexity and should not be blindly trusted to align with long-term goals.
  4. An Invisible Problem: technical debt sneaks up, staying hidden until system inefficiencies or outright failures bring it to light. It is the classic “out of sight, out of mind” mindset of the inexperienced and short-term oriented. While performance issues are usually the first red flag, the real challenge lies in the system’s dwindling ability to adapt.

NetSuite’s SuiteSuccess and Early Out-the-Gate Tech Debt

Oracle NetSuite’s SuiteSuccess approach to offering their customers “quick to market” solutions often accelerates tech debt from the start:

  • Irrelevance and Bloat: Pre-installed add-ins and configurations may not be relevant to the customer’s needs.  It’s the bloat problem right for the start.
  • Ignorance: Customers typically lack NetSuite’s architectural awareness (like the outline above), contributing to poorly informed decisions.

When our firm leads a NetSuite implementation, we carefully craft the NetSuite account activation and request full rights to third-party add-ins that would typically be included in a standard SuiteSuccess configuration.

Possible Paths Forward: Every Choice Has a Cost

Once the NetSuite-driven team fully acknowledges the technical debt, management starts to recognize that the costs will persist. Here are three common approaches we observe for addressing it.

  1. Live with It (default): let’s ignore the growing technical debt and continue using the system as it is. The system’s inefficiencies persist, causing the business to struggle with adapting to growth or evolving needs. Users grow increasingly frustrated, and NetSuite’s reputation within the organization suffers, as it becomes the scapegoat for a poor experience.  As I will explain in the next section, NetSuite does not deserve the blame; this is simply a common reaction from those who lack proper understanding.
  2. Remediation:  we identify and address specific areas of poor performance or functionality.  While this can bring some pin-pointed relief, it is often a temporary solution if underlying practices aren’t addressed.  In the ideal case, wisdom suggests that we step back to assess overall business objectives and evaluate how well the system aligns with them — significant effort is then needed to study the existing architecture and establish a new standard for improvements.  This may be slow but the least disruptive to existing business and practices.
  3. Reimplement:  we start fresh with a new implementation.  Since, in the ideal case, we review business goals and processes to ensure alignment with best practices, we can begin to analyze the current system to map what’s embedded through configurations, add-ins, or customizations to confirm we have the totality of the requirements.  However, we can now design a new implementation roadmap with a focus on managing technical debt proactively as part of ongoing system governance.  While this is resource-intensive, it offers an opportunity to reset and future-proof the system.

Each path requires trade-offs in terms of cost, effort, timing and long-term impact. The right choice depends on the organization’s capacity to adapt, its tolerance for disruption, and its commitment to aligning technology with strategic goals.

Standards to Manage Tech Debt Growth in NetSuite

Managing technical debt requires a deliberate approach that balances the urgency of business needs with the foresight to maintain system integrity. By adopting responsible practices, organizations can reduce the hidden costs of technical debt and enjoy NetSuite’s promise of a system that supports both current operations and future growth.   Here are the five areas that require organizational leadership:

  1. Business System Leadership: often a CIO (or CTO) acts as a dedicated leader valued by the business team to ensure alignment between organizational strategy and system capacity.  The leader will assess the organization’s capabilities and technical requirements in light of its ambitions to educate stakeholders on the obligations necessary to maintain and enhance system performance.  When well done,  thoughtful guidance is offered to maintain system integrity and support execution goals.
  2. Change Management:  the idea is to introduce changes carefully to consider their impact on technical debt and to build organizational maturity to recognize patterns and establish practices that anticipate challenges.  We slow down just enough to maintain reliability and track the system’s evolution for better future ongoing refinement.  Here, a class of tools becomes meaningful, such as NetSuite’s SDF, Strongpoint, or Salto, to inspect, document, and track customizations.  Note: while these tools provide visibility, they are no substitute for leadership’s nuanced understanding of business strategy, system architecture, and long-term goals.
  3. Investing in Scalable Solutions: we recognize that solutions need to work well under load and stress.  Here, we need to go the extra step to observe what happens under load by testing — because if we don’t, we may find that we have to introduce reactive patches and address eroding user trust and satisfaction.
  4. Proactive Documentation:  we recognize human fallibility and the need to hold all the complexity in the environment.  Maintaining a comprehensive knowledge base for configurations, customizations, and decision-making processes allows for multiple parties to share mental models which then allows for aligned action.  We recognize that AI-driven tools can help us, more now than ever, to inspect and document structures nearly automatically.  But we need the judgement to ensure documentation is clear enough for others to act upon effectively.
  5. Regular Reviews and Refactoring:  we accept that we need to continuously improve and work to simplify system architecture where we can to enjoy a cleaner, more maintainable system that adapts to evolving needs.  This may mean that we must plan for periodic refreshes to maintain performance and reduce complexity.  This often looks like planned infrastructure uplift projects to address legacy components and modernize the system.  For example, all those SuiteScript 1.x scripts are probably candidates for a refactor.

Possessing the above practices is a hallmark of a more capable and mature organization.  Effectively managing technical debt requires discipline, foresight, and deliberate practices.

How the ERP Tech Debt Cycle Works in Oracle’s Favor

For platform publishers like Oracle NetSuite, success hinges on keeping the core product stable  while driving  innovation capacity to remain competitive. NetSuite continues to lead as a formidable ERP solution, maintaining its edge over competitors.  They are doing the right thing — but they don’t have an incentive to talk about this general phenomenon as it may slow the adoption cycle.

Key Dynamics of the Tech Debt Cycle

Here are ways that the industry stays quiet about the technical debt phenomenon — which frankly is in their favor:

  1. Platform Stickiness: once an organization adopts NetSuite (or any ERP), switching costs are high. The investment in setup, fitting and training makes it difficult to leave.
  2. Hardware as a Band-Aid:  publishers often suggest solutions like adding “threading” (SuiteCloud+) or increasing hardware capacity to address performance concerns.  While this can temporarily alleviate issues, it does not address the fundamentals.
  3. Organizational Challenges, Not Platform Limitations: the true source of tech debt lies in how businesses are structured to govern their ERP implementations. While Oracle NetSuite provides the tools and infrastructure, it cannot dictate how they are used or enforce best practices within an organization.

Oracle NetSuite will continue to thrive as long as it maintains its value proposition as a leading ERP platform.  The burden of managing tech debt ultimately falls on the organization. Publishers understand this dynamic and may benefit from the cycle, but the root challenge is much less about platform limitations and much more about the disciplined and strategic use of the tools provided.

Situations We See with Our Clients

In our client environments, we consistently observe patterns in how organizations respond to the challenges of managing their NetSuite environments and the associated technical debt.   Here are three customer mentalities we observe:

  1. Deflectors: Investment Costs Too Great:  these clients are smaller and scrappy with their NetSuite configuration.  They usually lack the financial capacity or appetite for significant investments.  While they appreciate our expertise, they are cautious about committing resources.  They often delay necessary investments in the hope of avoiding or deferring costs indefinitely.
  2. Grinders: Living with Tradeoffs:  these clients aim to keep their systems functional and have an understanding of the tradeoffs involved.  They wish for improvements but are generally hesitant to commit to larger investments.  They value having us as a trusted partner who can step in to address issues as they arise but their deeper desire is a hope for new tools or solutions that might “make it better” without significant disruption or cost.
  3. Investors: Proactive and Strategic:  these clients understand the challenges of technical debt and prioritize making investments to stay ahead as outlined above.  They value us because we bring them strong and thoughtful guidance to balance innovation and stability.  They see us as an integral part of their executive decision-making process.   They adopt a healthy attitude toward ongoing maintenance recognizing it as a cost of doing business effectively to unlock NetSuite’s potential.

How our Clients value Prolecto’s Distinguished Leadership

Our clients fall into distinct categories based on their approach to managing NetSuite and technical debt.  Whether they deflect, grind, or invest, we tailor our expertise to meet their unique needs. For deflectors and grinders, we offer practical solutions that respect their constraints.   For investors, we deliver strategic insights and leadership that align with their forward-looking ambitions.

We specialize in serving larger organizations under the “Investor” category above.  These clients value high-caliber expertise and are committed to the ongoing care and optimization of their NetSuite environments.

Our Firm’s Role in Our Clients’ Growth

As our clients mature, they develop internal capabilities to manage NetSuite and its technical debt, as outlined above.   In this process, our firm helps them with the following:

  • Provide marginal capabilities to complement their internal teams.
  • Advises on current trends and emerging patterns in the NetSuite ecosystem.
  • Shares generalized cross-client experiences to offer a broad sense of wisdom in business systems strategy.

Our Exception Processing Paradigm: The Record State Manager

A cornerstone of our approach is the Prolecto Record State Manager framework — universally valued by our clients.  The key tenants include the following:

  1. Reveals Business Rules: it moves business logic from hidden workflows and scripts into a centralized transparent framework.
  2. Centralized Rule Management:  centralizes all business rules into a processing engine to make them easier to manage, scale, and maintain.
  3. Scalable Background Processing: leverages NetSuite’s threading capabilities for true scalability.  Work is processed via queues to truly enable efficient exception handling and operational growth which then can take advantage of NetSuite’s SuiteCloud+ threading options.
  4. Exception Management:  we shift the business focus from managing routine operations to managing exceptions to enable faster response times and better resource utilization because we only touch things that don’t pass business rules.

Depending on how we work with clients, we see applications as follows:

  1. New Implementations: the Prolecto Record State Manager is incorporated as a foundational element to ensure scalable and transparent business logic from the start.
  2. Existing Systems: for clients with complex or outdated configurations, the framework is used to regain control over business logic and to help reduce technical debt and establish a clearer path forward.

The bottom line is that the processing paradigm is an uncommon approach valued by our more ambitious clients who recognize the immense capacity that opens when thinking and designing with this pattern in mind.

Contain Technical Debt to Scale NetSuite and Drive Business Ambition

I hold that NetSuite is a scalable business application and that technical debt is a fundamental responsibility of professionally led organizations.  Our firm’s expertise and the adoption of frameworks like the Record State Manager empower clients to confidently manage their NetSuite environments.   By combining strategic guidance, scalable solutions, and proven methodologies, we help clients balance innovation with stability, ensuring their systems evolve alongside their business needs.  This happens when we work closely to plan and build capacities together to maintain scalability and adaptability — a key capacity for ambitious organizations.

If you found this article relevant, feel free to sign up for notifications to new articles as I post them.  If you seek more decisive leadership to tackle NetSuite technical debt challenges, let’s have a conversation.

Marty Zigman

Holding all three official certifications, Marty is regarded as the top NetSuite expert and leads a team of senior professionals at Prolecto Resources, Inc. He is a former Deloitte & Touche CPA and has held CTO roles. For over 30 years, Marty has produced leadership in ERP, CRM and eCommerce business systems. Contact Marty to set up a conversation.

More Posts - Website - Twitter - Facebook - LinkedIn - YouTube

About Marty Zigman

Marty Zigman

Holding all three official certifications, Marty is regarded as the top NetSuite expert and leads a team of senior professionals at Prolecto Resources, Inc. He is a former Deloitte & Touche CPA and has held CTO roles. For over 30 years, Marty has produced leadership in ERP, CRM and eCommerce business systems. Contact Marty to set up a conversation.

Biography • Website • X (Twitter) • Facebook • LinkedIn • YouTube

6 thoughts on “Best Practices for Addressing NetSuite’s Easily Accumulated Technical Debt

  1. Jarrod Tuxworth says:

    Great article, Marty!

    A good analogy is to regulations generally, where almost every governing body on planet Earth has rules and regulations that were necessary at a point in time, but are seldom removed when no longer relevant, or seldom even have their relevance assessed at all.

    One client has a ‘add a feature, remove a feature’ mindset, whereby any new customization is roughly married to a similarly sized de-customization. They also provide just as much incentive and recognition for the implementation of new functionality, as they do for the de-implementation of old functionality.

  2. Roy says:

    This article precisely and poignantly outlines the double-edged sword of Netsuite’s “flexibility.” Sure, you can add a field on the fly, create a basic workflow, or install a publicly shared/free bundle from a 3rd party. That’ll work just fine for 5 minutes and probably 5 months from now, but in 5 years, the business will wonder what that field, workflow, or bundle is for and why it was created.

    I enjoy being a reference call for Netuite. The Netsuite prospect is usually excited about “customizing” the system “on the fly”, maybe without needing a full-time developer. While I agree, I caution that without taking the time to document BRDs, FRDs, and user guides, they may see the “dark side” of its flexibility.

    Incredible write-up.

  3. Marty Zigman says:

    Thank you Roy. This article took more time to produce but is very important to our clients that are working to scale NetSuite.

    Marty

  4. Marty Zigman says:

    Jarrod, that’s a great practice I haven’t seen implemented before. It reminds me of when my wife wanted a new pair of shoes, I would ask her what she might be willing to donate to charity in exchange to keep things balanced and sane.

    Marty

  5. Roy says:

    An article on how to remove technical debt would be excellent! Should you inactivate or delete? What about the dependencies and data? Does it make a difference if it is a 3rd party bundle you no longer use? I use Strongpoint and a Sandbox, but it is a journey each time.

  6. Marty Zigman says:

    Hi Roy,

    I accept. As offered in the article, we have a pattern (Accelerator Template) that can be used to help with better scalable long-term processing to incrementally improve the situation. But we don’t believe there is a silver bullet. The challenge demands good assessments.

    Marty

Leave a Reply

Your email address will not be published. Required fields are marked *