NetSuite Change Management—2023 Guide

NetSuite is a wonderfully powerful system. One in eight businesses with an ERP rely on it to manage their finances. But despite plenty of new tools and resources from NetSuite (now Oracle) over the past few years, deploying customizations and configuration changes is still a bit of a challenge.

In particular, deploying new features and customizations takes time and is prone to error. But with the right process, it doesn’t have to be.

In this guide, we explain the pros and cons of deploying scripts and object changes with the three available options, as well as DevOps best practices for keeping those deployments error-free.

‍

1. Things to know about deploying in NetSuite

When the software development world took to DevOps (a fusion of development and operations), NetSuite followed by launching SuiteCloud Development Framework, or SDF for short. This was its answer to the DevOps question. And while it offers lots of useful tools, it doesn’t provide everything you’d need to practice DevOps.

What SDF does do well is it lets you access your NetSuite configuration through either a command line interface (CLI) or integrated developer environment (IDE). That offers lots of the benefits of working directly with code. But, let’s pause there.

If you’re not immediately sure what a CLI and IDE are, neither are many NetSuite admins, and that presents a learning barrier that sometimes keeps everyone from getting involved. (SDF all but requires you have prior experience as a developer managing resources as code.)

And even then, SDF was also built to help teams deploy changes, but not necessarily plan or test them before launch. And even a NetSuite expert who knows that armed with SDF, they’ll face certain limitations.

What’s more, in a modern DevOps environment, you’d expect to be able to automate much of the above. You’d want the system to automatically run quality tests on the configuration once it was moved into the testing environment, and clear error messages on what’s not working, and how to fix it. (NetSuite’s error messages are still notoriously opaque.)

Instead, NetSuite admins are left to set up many of these DevOps elements themselves. This guide will explain how they do it, so you too can follow the current best practices as closely as possible.
‍

2. Planning

Many NetSuite admins are so used to making updates directly in production that their proposed customizations don’t flow through a series of stages—they just get implemented.

That’s far from ideal. As a system scales and the complexity grows, it creates technical debt. That’s one of many reasons why software developers use a strict process for building and testing things. One way they represent that process is the application lifecycle (or software development lifecycle), and it applies just as well to managing change in NetSuite.

By following a clear process, you improve the quality of those customizations, reduce bugs, and build trust with users. You also leave a paper trail so you or anyone can understand why changes were made. As you grow, having that record becomes invaluable for training new people and maintaining the system.

But there is no singular tool that allows you to follow a complete software development lifecycle within NetSuite. And so the question is, how does one act upon this knowledge? Below are best practices for coming as close as is currently possible.

‍Stop making changes in production—perhaps even ban itThe production environment is too critical for you to risk making direct changes there. Also, in the event of an audit, auditors will likely focus there, and if you can’t prove that you tested or reviewed something prior to releasing it, you may run into trouble. Small customizations can affect revenue and a habit of making direct changes may appear indefensible. (Especially if it goes to court.)

Instead, always test configuration changes or customizations in the sandbox first.

‍Create a change pipeline where you move changes through a series of sandboxesIdeally, each sandbox will be progressively more and more like the production environment. True software development teams have the luxury of many different sandbox types to choose from. Whereas in NetSuite, you only have two—a developer sandbox and a full sandbox. But those are enough. Start changes in one, move them to another to test, and only then, deploy things to production.

Three pipeline test environments you should have:

• Development (or “dev”)—For building configuration changes
• Integration (if you can afford multiple sandboxes)—For initial tests, and to see how changes will affect customizations
• User acceptance testing (UAT)—For realistic tests with actual users

Read: How to refresh your sandbox in NetSuite.‍

‍Use a version control system like Git
‍NetSuite’s SDF converts your configuration and customizations into code. XML, to be specific. That opens up a whole bunch of possibilities for managing it, including syncing your entire set of scripts and custom objects to a Git version control system such as GitLab, GitHub, or Bitbucket.

What that means is, in essence, you can store a “snapshot” of your environment every time you edit SuiteScripts and other components, and so preserve a history of changes. That lets you go back and see who made changes, which is helpful if you want to reverse them. (Complete rollbacks are technically impossible in NetSuite—SDF doesn’t let you “undo” or delete configuration updates—but you can make new updates over those old updates. For example, if you changed the name of a form, you can submit a new change to overwrite it back to its original state. But if you added a new form, you cannot delete it.)

Managed Git service options:

• GitLab
• GitHub
• Bitbucket

Read: A complete beginner’s guide to Git.‍

‍Require peer reviews
‍Because your configurations now exist in a Git tool, you can use that tool’s collaboration features. You’ll be able to maintain one primary branch that represents your production environment, and let individuals make a copy or “branch,” alter it, and invite others to review those changes.

One challenge remains, of course: XML will be gibberish to most of your colleagues. You won’t be able to share it with an administrator or user, for example. But you can explain the change to them and ask for their input, and that’s a lot better than not involving them at all.

‍Automate manual tasks
‍If you choose to practice continuous integration, or frequent, small releases instead of big batches, you’ll probably want to use a continuous delivery tool, also known as a CI/CD tool. Those systems allow you to templatize the release process, so every time you deploy, it goes through the same checks. It’ll allow you to commit frequently, get new fixes and features out to end users quickly, and integrate unit tests into every release.

Automation is great because it both saves people work and reduces the potential for human error. Moreover, it helps developers get feedback earlier on, making it cheaper to fix or change things, and easier to address those problems before they’ve moved on to other things and have forgotten the context.

CI/CD tools you might consider:

• GitLab CI/CD
• Harness.io
• Bitbucket Pipelines

Maintain a full history for auditors
‍Versioning alone is not enough for auditors. You’ll have to link the changes in NetSuite (or your Git tool, rather) back to the rationale for making that change. You can accomplish this by taking the link to the change in Git and adding it to the Jira or ServiceNow ticket where that change was requested.

Project management tools you might consider:

• Jira
• ServiceNow
  ‍

‍Read: How to make NetSuite SOX compliant.

‍Implementing all of the above is not a simple endeavor. It requires a bit more manual work than someone steeped in DevOps principles might prefer. But it’s a huge step up from allowing folks to simply make configuration changes or customizations directly in production.

Next up, we’ll explain how to actually deploy those changes from your test environments to production, and the three mechanisms for doing so.

‍

3. Deploying changes in NetSuite

When it comes to deploying customizations and configuration changes in NetSuite, you have three options. Each has pros and cons.

‍

‍Oracle has actually announced that it no longer plans to maintain bundles. They aren’t going to deactivate it, but they also won’t improve or patch it. At the time of writing, enough individuals are still using bundles that it’s worth covering.

Bundles are the classic way to move components between environments in NetSuite—via a group of changes, or “a bundle.”

• The upside: You can make changes in bulk, which the other interface deployment option, “copy to account,” cannot do.
• The downside: You can’t deploy every type of component. For example, email templates. You’ll have to rebuild those by hand.

It’s also worth noting that the list of components bundles cannot deploy will only grow with time. NetSuite will continue to add support for deploying a wider variety of new and existing object types, but it won’t maintain bundles, so bundles will keep growing more and more out of date.

Bundles also weren’t built with DevOps in mind, exactly. The fact that they’re managed through a point and click interface, and the fact that you could only manage them inside the Netsuite account, make employing DevOps style practices for your Netsuite deployments virtually impossible.

More things you should know about bundles:

• You can’t partially deploy a bundle—It’s all or nothing. You either deploy everything mentioned, or not deploy.
• Bundles automatically include referenced components—You can’t selectively remove them. So, if your bundle includes an email template, you won’t be able to use bundles.
• You can’t preview what the change will look like in production—That makes it difficult to test how deployments will interact with your true production environment.
• May invite human error—Just like any point-and-click interface.
• You can’t automate testing—That’s an SDF-specific feature.
• You can’t manage NetSuite resources as efficiently—The interface doesn’t allow you to do as many things as working with code would.
• Limited customization coverage—You can deploy some configuration changes, but not all.
  ‍

‍The “copy to account” feature is newer than bundles, and in it, NetSuite addressed some complaints people had about bundles. For one, “copy to account” allows you to decide whether or not to include referenced items in a deployment. But that flexibility comes with a tradeoff: You can only release one component at a time. If you’re planning on making bulk changes, best to use the other two options: bundles or SDF.

It’s worth noting there’s a lot of overlap in what “copy to account” and SDF can do, and that’s because “copy to account” is built upon SDF. It’s an abstraction that makes some of the power of SDF available in an interface.

Consider using “copy to account” if:

• The change is simple and you prefer to use an interface
• You want to deploy an ad hoc customization in isolation, right away
• You want to cross-copy customizations between environments for tests, modifications, extensions, debugging, etc.
• You want to preview a customization in the target environment and understand the dependencies
• You’re unaccustomed to working with NetSuite metadata inside an integrated developer environment (IDE), and so can’t use SDF

But also, here are things you should know about “copy to account” before using it:

‍You can preview some components, but not all
‍“Copy to account” has a nice new preview feature that shows you how things you’ve built will look in the target environment. But it won’t show you what every component looks like—just ones supported by SDF. And often, that can be limiting, because you’ll be missing important pieces.

“Copy to account” won’t let you preview:

• Most preferences—For the company, accounting, and user
• Most files in the File Cabinet—With the exception of a few like SuiteScripts and some templates
• Any record data—From customers, orders to subsidiaries, currencies, departments, etc.

Users say it’s slow
‍Lots of users report that “copy to account” slows down significantly when the change is complex. If it’s just a field change, “copy to account” is great. But if there are lots of dependencies, the checks may run for a long time and encounter errors.

‍There’s no way to cancel your deployment
‍Once you hit “deploy,” there’s no turning back. The deployment will continue until complete. And there’s no simple way to “undo” a change or revert to a prior state. So, review carefully.

‍You can’t move multiple components together
‍We’ve already covered this, but it’s worth stating again, because it’s the biggest limitation. If you create multiple components in the sandbox, you can only move them one at a time. For big or busy teams, that’s a non-starter.
‍

‍For the technically inclined, there’s SDF. It was built for DevOps operations. It extracts your NetSuite instance’s configurations and customizations into XML, giving you a full record of (nearly) everything, and lets you push that code into a Git tool. You can interface with it through an integrated developer environment, or developer command line interface. (An IDE or CLI, for short.)

However, it’s difficult to make the leap from using bundles and “copy to account” to SDF. It can take a significant amount of training to get to the point where you’re able to reliably deploy quality, tested customizations to production in less time than the other two options would take.

Even Oracle assumes that if you’re using SDF, you’re a developer. (Nearly all the help articles begin with the phrase, “As a developer …”.)

Not everyone who builds in NetSuite can devote the time necessary to take a course, teach themselves, or run enough Google searches to make this work. But, for those who do, it’s the most versatile and reliable option, for all the reasons that working with code gives you powers that simply aren’t available in an interface.

All that said, even SDF has limitations you should be aware of:

‍SDF only covers some customizations and configurationsSDF only offers partial access to the File Cabinet, namely for SuiteScripts, templates, and web hosting files. It also isn’t possible to track and compare user or account-wide preferences, and it cannot move any kind of record data between environments, nor address account-specific values. That makes it difficult to compare your production and sandbox environments, or to keep those two synced so you can conduct meaningful tests.

To recap, SDF does not support:

• The entire File Cabinet—only part of it
• Almost any configuration preferences data
• Account-specific values

It often runs into errors when deploying custom objects
‍Deploying complex objects like workflows and forms is quite challenging with SDF. It hides account-specific values, and sometimes doesn’t add all the dependencies you’d need for a successful deployment to the manifest file. That means you'll often have to adjust it manually. That makes automating deployments difficult.

‍The validation tool isn’t always accurate
‍The validation tool inspects the SDF project structure and punches out a success or failure validation result. (Read the full list of checks here.) Only, sometimes it overlooks things and successfully validates a project that then goes on to fail in deployment.

‍No way to delete or completely “roll back” changes
‍At the time of writing, SDF does not offer a way to delete customizations. That means there’s no simple way to undo or “roll back” customizations. (You are limited to overwriting customizations, which makes things much more complicated.)

These are just some of the challenges of working with SDF. Get through all that though, and it provides a foundation for continuous integration and continuous delivery (CI/CD) flows and automated tests. It’s the closest you’ll get to practicing complete DevOps within NetSuite.

‍

SDF is the closest you’ll get to practicing complete DevOps within NetSuite.

‍