What NetSuite Retiring SuiteScript 1.0, 2.0 and 2.x Means for Your Company

Oracle published the retirement timeline for the older versions of SuiteScript, the language used to program NetSuite customizations. The final milestone is version 2028.2.

If your company runs NetSuite, this article covers the decisions ahead and when to make them. If it does not, the article still applies, because the underlying problem is not a NetSuite problem. It affects any company that built part of its operation on a piece of software, and most of them find out when something fails and nobody can explain why.

This is not a technical article. If what you need is the detail of how a script gets migrated, we wrote that separately in Action Required, Update Scripts to SuiteScript 2.1. Here we cover the other half of the problem, the half that does not get solved by writing code.

The essentials, in four points

• There is a specific deadline. In NetSuite version 2028.2, scripts using SuiteScript 1.0, 2.0 or 2.x stop running.
• Nothing breaks this year. The timeline is gradual and the first change with real effect arrives in 2027.
• The problem is not technical. Moving the code onto the new version is the mechanical work. The hard work is knowing which customizations exist, which processes they support, and who understands them.
• Two years is more than enough. Six months is not. That is the entire difference between planning and firefighting.

The timeline, version by version

Each milestone is tied to a NetSuite release, and releases reach each account at different times. That is why there is no single calendar date that applies equally to every company.

This is the plan Oracle publishes today and it may be adjusted in the future, but the direction is clear and there is no reason to count on an extension.

Why this looks very little like a software problem

The usual reaction to an announcement like this is to pass it to the systems team or to the provider, which is reasonable. In practice, though, the bottleneck shows up somewhere else.

A customization gets written to solve something the business was asking for at the time. An approval flow built around the amounts the company handled six years ago. A validation that exists because one large customer insisted on a particular field. A calculation that mirrors a commercial rule nobody ever wrote down anywhere else.

That code is still running. The reason it exists, on the other hand, usually left with the person who requested it or the person who wrote it.

So the real work is not translating syntax. It is reconstructing intent. And that is precisely the work that gets more expensive the longer it waits, because every year that passes leaves fewer people who remember why the system does what it does.

Where the risk tends to hide

Customizations are invisible. A script runs when someone saves a transaction, when a nightly process executes, or when another system exchanges data with NetSuite. Nobody notices it until it fails.

Across the accounts we review, the risk shows up in almost the same four places every time.

• Finance and compliance. Documents in the format each country requires, tax calculations, close-period validations. This is the group where a silent failure costs the most, because it surfaces late and with the month already closed.
• Sales. Pricing rules, volume discounts, commissions, order approval flows. These tend to be the scripts modified most often over the years and the ones with the least documentation.
• Purchasing and operations. Approvals by amount, goods receipt, inventory movements, stock reservations.
• Integrations. Everything connecting NetSuite to e-commerce, the logistics operator, the bank, or an in-house system. There is an extra point here, these integrations often also rely on authentication methods that have their own retirement timeline, so they deserve to be reviewed with that double lens.

This is not a claim that all of these processes will fail. It is where it pays to look first.

The question almost no company can answer today

If we had to reduce this whole topic to a single question, it would be this one.

Who maintains each of the customizations holding up your operation, and what happens if one of them stops working tomorrow?

Most companies cannot answer it. Not out of carelessness, but because that information was never centralized. It accumulated across implementations, provider changes, consultants who came and went, and urgent requests that got solved and never documented.

Answering that question is, in itself, the most valuable deliverable of this entire process. It serves the SuiteScript 2.1 migration, but it also serves the rest of the time, when there is an improvement to decide on, a provider to evaluate, or a number that does not add up.

If your company does not use NetSuite

The SuiteScript case is a well documented example of something that happens on every platform. Your ERP, your CRM, your billing system or your e-commerce platform will retire versions, APIs and authentication methods, and they will do it with a notice that probably never reaches the leadership team.

There are three questions worth being able to answer about any software your company rests an important process on.

1. What is customized? Not which features we use, but what was built specifically for us.
2. Which version is it written on, and how long does the vendor support that version? This is the one almost nobody asks, and it is the one that anticipates the problem years in advance.
3. Who maintains it today? By name. If the answer is "whoever implemented it for us", it is worth confirming that they are still around and still hold the knowledge.

If you can answer those three about your critical systems, retirement announcements stop being uncomfortable news and become tasks with a date on them.

What we are doing at Deimos Solutions

We decided to treat this as a project of our own rather than an inquiry we wait to receive.

• We verified the timeline against Oracle's documentation, not against third-party summaries, and we list the sources at the end of this article so anyone can check them.
• We wrote the full technical guide to the migration process and published it openly, including the part explaining why changing the version tag is not enough.
• We are reviewing our clients' customizations account by account, with a plan per client rather than a general notice.
• We opened the inventory at no cost to any company that has NetSuite, whether they work with us or not, because a diagnosis should not depend on buying a service.

We say this with a specific point in mind. A provider who brings you this topic in 2026, with sources and a plan, is a different proposition from one who brings it in 2028 with an emergency quote.

What a plan that does not end in a scramble looks like

The window Oracle gave is wide, so none of this has to happen at once. Spread out, the work looks roughly like this.

2026, the year of knowing. A complete inventory of customizations, with the real version of each one, the business process it serves, and the person responsible for maintaining it. This is the cheapest stage and the one that enables every decision that follows.

2027, the year of deciding and testing. With the inventory in hand, each customization gets a route. It is updated, its compatibility is tested, or it is retired if it is no longer used, which turns out to be a more common outcome than people expect. Testing happens in sandbox, with real transactions, starting with anything that touches money.

2028, the year of closing out. A staged move to production, with the critical processes already migrated and validated the year before. What is left are the secondary customizations and the edge cases.

Compared with resolving everything between two financial closes, the difference is not in total effort. It is in risk.

Frequently asked questions

Our company does not use NetSuite. Why should we read this?

Because the pattern repeats on every platform. Any company that customized its software accumulates development work that keeps running without anyone reviewing it, until the vendor retires the version it was written on. NetSuite gave two years of notice. Not every vendor does.

What happens if we do nothing until 2028?

In the short term, nothing. The risk is concentration. Work that can be spread across two years, with unhurried testing and corrections made without pressure, instead gets executed in a few months while competing with the financial close. That is where the errors come from.

Who should lead this inside the company?

It should not sit with the technical team alone. Deciding what gets migrated, what gets retired and in which order depends on business impact, and that is known by the people who use the process every day. The setup that works best pairs a technical owner with a finance contact and an operations contact.

Our NetSuite provider has not mentioned anything. Is that normal?

It is common, and it does not always signal a lack of interest. The notice arrives with version 2026.2 and accounts are upgraded on a staggered basis, so many teams have not seen it yet. It is still worth asking, because the answer tells you a lot about how your account is being managed.

How do we know whether our integrations are affected too?

They need to be reviewed separately. Integrations with external systems tend to rest on older development work and, on top of that, they have their own timeline of changes to authentication methods. These are two distinct topics worth covering in the same review.

When should we start?

The inventory is worth doing this year, because it is inexpensive, it interrupts nothing, and it is the only data that makes every other decision possible. The migrations themselves can wait until 2027. What is not worth doing is reaching 2028 without knowing how many customizations exist or which processes depend on them.

The inventory, at no cost

The first step in all of this does not require buying anything, and we do not think it should.

At Deimos Solutions we run the initial diagnosis and inventory at no cost, whether you work with us or not. It includes a full identification of the affected scripts, the actual version each one executes under, and a report written so that non-technical readers can follow it too.

With that report you can prioritize, plan, request quotes from whoever you like, or simply file it knowing your account is in order. If you then want us to handle the migration, we will send a proposal. No commitment, and the inventory is yours either way.

Conclusion

Oracle gave an unusually wide window for a change of this size. What it could not give, because nobody can, is the map of your own account.

That map is what ends up being worth something well past 2028. A list of what is customized, for which process, on which version and under whose care does not get used once. It gets used every time there is an improvement to decide on, a provider to evaluate, or a number that does not add up.

And it is worth repeating, what runs out while this sits waiting is not the years on the clock. It is the number of people who still remember why the system does what it does.

Sources

• Oracle NetSuite, Transitioning To SuiteScript 2.1. docs.oracle.com
• Oracle NetSuite, Identifying Scripts That Are Not Using SuiteScript 2.1. docs.oracle.com
• Oracle NetSuite, Choosing A Migration Path. docs.oracle.com
• Oracle NetSuite, Enabling SuiteScript 2.1 at the Account Level. docs.oracle.com
• Oracle NetSuite, NetSuite 2026.2 September Minor Release Notes. docs.oracle.com