Your Script List Says 2.1. Your Code Might Not Agree.

I've put SuiteScript 1.0 code inside 2.x scripts. On purpose. At three different clients.

Here's one of them. A client needed users to enter serial numbers for a transaction line from a popup. A client script on the transaction opens a Suitelet in a child window. The user pastes in serials, hits submit, and the serials land on a sublist on the parent transaction.

The parent transaction is still open in edit mode. Nothing has been saved.

That's the whole problem.

The serials can't be saved server side, because the parent record might not exist yet, or it's mid-edit. They have to land on the form sitting in the user's browser.

SuiteScript 2.x can't reach it. N/currentRecord gives you the page your script is running on, and nothing else. When the Suitelet handles the POST, its response is a new page in the popup. No 2.x module hands that page the record open in the parent window.

So the Suitelet doesn't return a page. It returns a small script. That script reaches through window.opener and calls the 1.0 client API, which NetSuite still loads on record pages today. Find the line, select it or start a new one, set the values, commit. Popup closes. Serials are on the line.

Everything else in that solution is 2.x. Form building, searches, record logic. The 1.0 is fenced into one write-back step, and at the time it was the right call.

It's also exactly the kind of code this migration is going to trip over.

Where things stand

When I wrote about this in July, there was no deadline. Now there is. SuiteScript 1.0 drops to critical-issues-only support in 2027.1. In 2028.1, 2.0 and 2.x scripts start running as 2.1 by default. By 2028.2, everything has to be on 2.1.

Oracle has also been clear about this specific pattern for years. Their own API map says NetSuite does not support calling 1.0 APIs from 2.x scripts. That was a tolerable risk when nothing was being retired. It's a different risk now.

Why your inventory won't find it

Oracle's recommended way to find legacy scripts is to go to Customization > Scripting > Scripts and filter by API version.

Run that on the account with this Suitelet and it shows up as 2.x. Change the annotation to 2.1 and it shows up as 2.1. The filter reads the version on the script record. It doesn't read the code.

So you can do the inventory correctly, convert every script on the list, get a clean report, and still have nlapi calls running in production.

All three of mine were annotated 2.x. The version filter would have called every one of them done. And I'd bet the most common version out there is sitting in client scripts, where someone needed a sublist operation that 2.x made awkward, and the 1.0 functions were right there in the browser.

To be straight about what I don't know: Oracle hasn't said the 1.0 client functions will stop loading on record pages, or when. They might keep loading for a long time. But "unsupported, and tied to a version being retired" is a bad place to keep something your team uses every day. And when it breaks, it won't be an error in a log someone's watching. It'll be a button that quietly stops working in somebody's browser.

How to check

The version filter is step one. Step two is reading the code.

Pull your script files down from the File Cabinet and search every file for "nlapi" and "nlobj," no matter what version it claims to be.

Look hard at anything that writes script tags into a response, and anything that touches window.opener or window.parent. That's where bridges like mine live.

For every hit, write down what it does and why it's there. Some will be old habits that convert in minutes. Some will be bridges where 2.x has no direct equivalent. Those need a design decision, not a translation.

The fix isn't find-and-replace

For most nlapi calls, Oracle's API map gives you the 2.x equivalent. The same map admits some 1.0 APIs don't have one. A bridge like this falls in that bucket. That's why it was written in 1.0 to begin with.

The direction I'd take here: move the write into a 2.1 client script on the parent transaction, and have the popup pass it the data with standard browser messaging instead of reaching in and calling 1.0 functions itself. Same experience for the user. No 1.0, and the part that touches the record runs entirely on supported 2.1 APIs.

That's a redesign. It gets tested in a sandbox against the real transaction flow, with real serials, before it goes anywhere near production. Which is the honest shape of this whole migration. The syntax is the easy part, and AI handles a lot of the mechanical translation now. The decisions are where the work is.

If your inventory came back clean

Good. That's the first half.

The second half is finding the 1.0 code hiding inside scripts that say they're 2.x. If you want a second set of eyes on that, I'm glad to look. We only do SuiteScript, and this is the code I'm reading every week.