↓

Getting reliable NetSuite support: who does what after go-live

NetSuite support splits between Oracle, which runs the platform and its twice-yearly releases, and your integrator, which looks after your configuration, scripts, integrations and users.

Last updated 28 October 2026

Going live is not the end of a NetSuite project. It is the point where the system starts to carry real payroll runs, real VAT returns and real month-end closes, and where questions of NetSuite support and NetSuite maintenance stop being theoretical. Many UK businesses discover only after go-live that nobody has defined who answers the phone when a script fails on the last working day of the month.

This page sets out who is responsible for what, what a sensible support and application maintenance contract looks like, how release upgrades should be handled, what to budget for, and how to move to another provider when the relationship no longer works.

What Oracle covers, and what it does not

NetSuite is delivered as a cloud service. Oracle runs the platform, the infrastructure and the release process; you do not patch servers or schedule database upgrades. The scope of Oracle's own support is defined by your subscription, so read that document rather than relying on a sales conversation. Our NetSuite cloud and hosting page explains the underlying model in more detail.

What sits outside the platform is just as important:

  • the configuration of your subsidiaries, roles, workflows and saved searches;
  • custom records, forms and SuiteScripts written for you;
  • integrations with your bank, e-commerce site, payroll bureau or warehouse system;
  • user questions such as "why does this invoice not post to the right period?".

In practice, these belong to your integrator or to an internal administrator. If you have commissioned bespoke work, as described in our page on NetSuite customisation, someone must own it for as long as you use it.

Who does what: a simple responsibility table

Area Oracle Integrator Your team
Platform availability and infrastructure Yes No No
Delivery of planned releases Yes No No
Release testing of your customisations No Usually, if contracted Business sign-off
Incident handling on scripts and workflows No Yes, if in scope First-line triage
Integration monitoring and repair No Yes, if in scope Report anomalies
Roles, permissions and user changes No Can assist Administrator decides
Small enhancements and reports No Yes, quoted or from a day bank Prioritise requests
Training of new joiners No Optional Line managers

The table shows why vague contracts hurt. Every line marked "if in scope" should be settled in writing before you sign.

Support and application maintenance: three layers

Providers use different vocabulary, so it helps to separate three layers.

Support: incidents and questions

This is reactive. A user cannot post a journal, an approval routing is stuck, a saved search returns the wrong records. The provider receives the ticket, diagnoses it and either fixes it or explains what the user should do. Good support includes a first diagnosis that tells you whether the cause lies in your data, your configuration, a script or the platform itself.

Maintenance: keeping the system healthy

Often called TMA (tierce maintenance applicative) in French practice, and managed application maintenance or application management services in English, this layer is proactive. It covers fixing scripts that a release has affected, reviewing roles when staff change, cleaning up unused customisations, watching integration failures and keeping documentation current. A TMA NetSuite contract is worth having when the system carries many customisations or integrations.

Evolution: change requests

New requirements arrive constantly: a new sales channel, a new subsidiary, a new approval rule, a revised report for your accountant. These are projects, large or small, not incidents. Agree how they are estimated, approved and invoiced, whether through a pool of days or case-by-case quotes. For larger changes, the approach in NetSuite implementation applies on a smaller scale.

Releases: the part you cannot ignore

NetSuite's documentation describes its releases as planned version upgrades delivered twice a year, bringing new features, enhancements and changes across the platform. The release notes for NetSuite 2026.2 are organised into three families: the notes for the planned release, the notes for the monthly releases that deliver improvements after the upgrade, and the notes for SuiteApps published separately. Among the areas covered by 2026.2 are Ask Oracle, the Intelligent Close Manager and support for IFRS 18 in accounting, passwordless sign-in with passkeys, bank reconciliation, capacity planning in manufacturing, event subscribers and the LLM module of SuiteScript, and .xlsx export from SuiteAnalytics.

You do not need to adopt every new feature. You do need to know which of them touch what you use. Our overview of NetSuite versions and editions helps you place a release in context.

Use the Release Preview account

Oracle provides a Release Preview account: a temporary, isolated test account, separate from production, that runs the new version of the software. It lets you test customisations, SuiteScripts, web services integrations, online stores and SuiteAnalytics Connect access before your own account is upgraded.

Three practical points from the documentation are worth building into your process:

  • the account remains available until the source account is upgraded, or until it has gone 14 consecutive days without a login, after which it is purged;
  • it is first accessible only to administrators, who can then open it to other users;
  • it is for testing only, not for live work.

A good support provider will run a structured regression test in this environment, list what failed, fix it and tell your finance team what to retest. Ask for that commitment explicitly. If your provider only tells you about a release once it has happened, you have a reactive contract, not a managed one.

What to ask for in the contract

Whether you are negotiating with your implementation partner or a specialist support firm, check these points.

  1. Scope. List what is included: incidents, user questions, script fixes, integration monitoring, release testing, small changes. List what is excluded.
  2. Severity levels. Define what makes an incident critical, for example a failed payroll posting before a pay date or a blocked VAT return, and what response and resolution targets apply at each level. Do not accept "best efforts" for critical cases.
  3. Hours. Match cover to your calendar. A business with a Friday payroll run and month-end close needs help on those days. Where cover is limited, ask what out-of-hours arrangements exist and what they cost.
  4. Named contacts and continuity. You should know who will pick up your ticket and what happens when they are on leave.
  5. Release commitment. Testing in Release Preview, a written outcome, and fixes within the contract or at a stated rate.
  6. Reporting. Regular summaries of tickets, root causes and recurring problems so you can fix causes, not symptoms.
  7. Documentation. The provider keeps a current record of customisations, scripts, integrations and roles, and you own it.
  8. Exit terms. Notice period, handover pack and access to everything created on your behalf.

Two UK-specific points deserve attention. First, compliance deadlines drive urgency: a failure in the VAT submission flow described in our guide to Making Tax Digital and ERP is not an inconvenience, it is a deadline risk. Second, if payroll runs through connected software, incident handling must account for the timing of Real Time Information submissions, as explained on payroll software and RTI. Your contract should reflect those moments, not generic office hours.

What to budget for

We do not quote prices here, because they depend on scope, the number of users, the complexity of your account and the provider. What you can do is understand what drives the cost.

  • Scope of cover. Incident-only support costs less than a contract that includes proactive maintenance and release testing.
  • Volume of customisation. Every script and workflow is something to maintain. A lean account is cheaper to look after.
  • Number of integrations. Each connector is a point of failure that needs monitoring.
  • Number of subsidiaries, currencies and users. More complexity means more questions and more testing.
  • Response targets. Faster guaranteed response normally costs more.
  • Enhancement volume. Decide whether you want a pool of days, a retainer or case-by-case quotes.

Separate three budget lines: Oracle's subscription (see NetSuite pricing for how that works), the support and maintenance contract, and a change budget for enhancements. Mixing them hides the true cost of running the system. Training also reduces ticket volume; well-trained users raise fewer avoidable questions, which is a good reason to revisit NetSuite training when staff change.

Keeping your own side strong

Even an excellent provider cannot compensate for a system with no internal owner. Appoint an administrator, ideally in finance or operations, who triages tickets, approves role changes and joins release testing. Keep a short change log. Ask your accountant to sign off any change that affects VAT codes, period locking or posting rules before it goes live.

Review the account at least once a year. Which scripts are unused? Which saved searches are duplicates? Which integrations fail repeatedly? A tidy account is faster to support and cheaper to upgrade. Where integrations are the main source of tickets, our page on NetSuite integrations lists the common patterns.

Changing support provider

Companies change provider for understandable reasons: slow response, loss of the consultants who knew the account, a provider that has moved away from NetSuite, or a merger that changes your needs. A move is manageable if you handle it in order.

  1. Read your current contract. Check notice periods, ownership of documentation and any access that is tied to the provider's own tools.
  2. Request a handover pack. It should list customisations, scripts, workflows, integrations, roles, open tickets and known issues.
  3. Commission an independent check. An audit of your NetSuite account tells you what is actually there, which is often different from what the documents say.
  4. Select the new provider carefully. Use the criteria in our guide to choosing a NetSuite partner, and ask for a described onboarding plan.
  5. Overlap the two. Keep the outgoing provider available during the first weeks, and avoid starting right before a month-end close, a year-end or a release.
  6. Review after the first period. Compare tickets, response and satisfaction against the contract.

If the new provider is critical of the earlier work, ask for evidence and a prioritised plan rather than a proposal to rebuild everything.

How we help

ERP Integrator is a free service that puts you in touch with a NetSuite integrator suited to your project. We are not affiliated with Oracle, and we do not carry out the work: the integrator does. Tell us whether you need first support, a managed maintenance contract, release testing or a takeover from another provider, and we will match you with firms that handle that work for businesses in your region. You can see how the process works on our how it works page.

Frequently asked questions

Does Oracle provide NetSuite support for my customisations?

Oracle operates the platform and delivers its releases, but your own configuration, SuiteScripts, workflows and integrations are specific to your account. Day-to-day help with those normally comes from your integrator or an internal administrator. Check exactly what your Oracle subscription includes before you assume anything is covered.

What is NetSuite maintenance (TMA) and how is it different from support?

Support answers incidents and questions: something is broken or unclear. Maintenance, often called TMA or managed application maintenance, is the continuing care of the system: adjusting workflows, fixing scripts after a release, adding fields or reports, and keeping integrations healthy. Many providers sell both in one contract, but the scope of each should be written down separately.

How should we prepare for a NetSuite release?

Use the Release Preview account to test your customisations, SuiteScripts, web services integrations and SuiteAnalytics Connect access before your production account is upgraded. Agree in advance who tests, who signs off and who fixes what is found. Do not wait for the upgrade date to discover a broken script.

What should a NetSuite support contract include?

At minimum: a clear scope, named contacts, response and resolution targets by severity, working hours that match your payroll and VAT calendar, a release testing commitment, reporting on tickets, and exit terms. Ask how work outside the scope, such as small enhancements, is quoted and approved.

Can we change our NetSuite support provider without disruption?

Yes, if you plan it. Ask your current provider for a handover pack covering customisations, scripts, integrations, roles and open tickets, have an independent audit confirm the real state of the account, and overlap the two providers around a release or a quiet period rather than a month-end close.

Sources

  1. Oracle NetSuite Help Center : NetSuite 2026.2 release notes
  2. Oracle NetSuite Help Center : Release Preview

Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.