Netsuite Suitescript Version Control

2026-10-04

Netsuite is a total pain for version control. One can edit Suitescript directly in the browser, or write script locally and then upload en masse. You can also develop code in sandbox instances and bundle over to production. None of these include any kind of version control. Netsuite will show that a file hash has changed but not what has actually changed.

Due to an incident where I deleted a load of undeployed code permanently, I now have a version control process in place. It's not perfect, in that it's possible to circumvent, but certainly a lot better. We currently hold all the code we're responsible for in a single repository, then create pull requests to bring in new developments.

The process is:

Create a new customisation project linked to a ticket
Write some code
Add new project as remote
Create project branch in main repository
Merge new-project-remote into new-project-branch
Resolve merge issues
Create a pull request for new-project-branch to main-branch
Get approval and merge to main
Deploy to production via Suitecloud Development Framework (SDF)

I've had this in place for around a year and seems to be working well. It certainly gives us a lot more comfort that we can roll back deployments if they get awry, and allowing us to really reduce the code base within our instance of Netsuite. There's a lot of rubbish, unmaintainable code in our instance so this really helps. The "version control" used by staff before I took over management was just a set of notes at the start of script file. Something like this:

VERSION   CASE   DATE         AUTHOR         DESCRIPTION
1.0       1029   2021-10-12   some.guy       I wrote this!
1.01      1299   2021-10-13   some.guy       Oops, made a mistake
1.10      1300   10/01/2024   some.new.guy   Added a bunch of "functionality"

The trouble was that these notes didn't actually show the changes. Occasionally, where there's new functionality the code has a start case 1029 and end case 1029, but that only covered new functionality.

Currently, we only track script changes in version control. We could potentially track objects: custom records, custom lists, etc. However, as there's a functional/technical split in my team, it's prudent to keep these separate. Whilst I was developing some functionality, I kept deploying local objects over the remote objects in Netsuite, when I'd made changes in the UI.

I think one of my main annoyances with using SDF to deploy script is that if you rename or move a file locally, SDF won't delete or move the file remotely. This needs to be done manually. On the one hand, this is the lower risk option as SDF "only" pushes code to the Netsuite script directories. However, it's very annoying to had to separately control a lot of the scripts. We have a lot of duplicate or undeployed scripts, so tidying (deleting) them up is a super tedious project.

This setup goes a long way to keeping our auditors happy that the changes to the system are well controlled.