Practical guide to managing NetSuite upgrades, SuiteScript customisations, integration maintenance, and support for Australian businesses.
IT managers, finance managers, and business owners running NetSuite who need help managing upgrades, customisations, or integrations.
How do we manage NetSuite's automatic upgrades, keep customisations working, and maintain integrations?
NetSuite is Oracle's cloud ERP platform, widely used by mid-market businesses in Australia for financials, inventory, e-commerce, and CRM. It's a true cloud system — everything runs in Oracle's data centres, and Oracle controls the release cycle.
That cloud-native architecture is both its strength and its challenge. You get automatic updates and no infrastructure to manage. But you also get upgrades you didn't ask for, at times you didn't choose, that can break customisations you depend on.
Forced upgrade cycle. NetSuite releases two major updates per year. Unlike on-premises ERP, you can't stay on an old version indefinitely. You get a sandbox preview period, then the update rolls to production whether you're ready or not.
SuiteScript deprecation. Customisations built with SuiteScript 1.0 are increasingly at risk. Oracle has been pushing migration to SuiteScript 2.x, and older APIs are gradually being removed. If your environment has significant 1.0 code, this is a growing risk.
Saved search fragility. Many NetSuite implementations rely heavily on saved searches for reporting, workflows, and dashboards. These can break when Oracle changes field names, adds new fields, or modifies search behaviour.
Support gaps. NetSuite's standard support can be frustrating for complex issues. Australian businesses often need local partners for responsive, knowledgeable support, especially around BAS, PAYG, and Australian compliance requirements.
Release management process. The most important thing you can do is establish a testing process for each release. Use the sandbox preview to test all critical customisations, workflows, saved searches, and integrations before the production update.
SuiteScript migration. If you have SuiteScript 1.0 code, plan to migrate it to 2.x. This isn't just a syntax change; it's an architecture change. Budget for proper development and testing time.
Configuration optimisation. Many NetSuite environments have been configured ad-hoc over years. A configuration review can identify inefficiencies, unused features, and misconfigurations that cause ongoing headaches.
Platform extension. Rather than over-customising NetSuite, build external applications that connect via API. Customer portals, mobile apps, advanced reporting, and specialised workflows often work better as separate applications that integrate with NetSuite.
SuiteScript maintenance. Every custom script needs an owner and a maintenance plan. Undocumented scripts from departed developers are a major risk. We recommend a full script inventory with owners, purposes, and test cases.
Workflow complexity. NetSuite workflows can become deeply nested and difficult to debug. As business processes change, workflows accumulate conditions and branches until nobody fully understands what they do.
Integration methods. NetSuite supports several integration methods:
The biggest integration risk is sprawl: connections built by different people at different times using different methods, with no central documentation or monitoring.
Deprecation risk is real. Plan migration proactively.
Document all integrations centrally. Test all of them during each release.
Heavy customisation means heavy upgrade cost. Evaluate whether standard features have caught up.
If one person built most of the customisations, that's a business risk.
Without a structured testing process, upgrade breakage goes undetected.
Yes — NetSuite pushes two major releases per year that you can't opt out of. But "automatic" doesn't mean "safe." Customisations, workflows, and integrations can break during these releases if they rely on features or behaviours that change. You need a testing process in place for every release cycle.
SuiteScript 1.0 code is at particular risk — Oracle has been deprecating older APIs. SuiteScript 2.x code is more future-proof but still needs testing. We recommend auditing all customisations and migrating 1.0 scripts to 2.x before they break in a future release.
We provide a fixed-price quote after scoping. Ongoing support is sized to the system's complexity and the volume of changes. Custom development projects are scoped per-engagement — no hourly billing.
Usually not — NetSuite is a strong platform. The pain is usually in how it's been configured and customised, not in the platform itself. Fix the configuration, modernise the customisations, and improve the integrations before considering a platform change.
Yes. We build and maintain integrations between NetSuite and other systems using RESTlets, SuiteTalk (SOAP/REST APIs), and middleware. We can also replace fragile CSV import workflows with real-time API connections.
Tell us what you are comparing, replacing, or trying to improve. We will come back with a practical recommendation and realistic scope.
