NetSuite Is Killing SOAP. Here's the Timeline, and the Trap.

If your business talks to NetSuite through SuiteTalk SOAP web services, you are on a clock, and it is a specific dated one that ends with those integrations no longer functioning. Per Oracle’s published deprecation plan, SOAP web services go away entirely at the 2028.2 release, and existing SOAP integrations stop working at that point.

I have spent a lot of my career wiring systems into NetSuite, so let me save you the research and the surprises. Here is what is happening, when, and the one migration mistake that will bite you even if you hit every deadline.

This is already happening

The engine behind the whole schedule is simple. Every SOAP endpoint has a three-year support lifecycle from the release it shipped in, and with each new release the oldest endpoint gets switched off. The 2019.1 endpoint is already dead as of 2026.1. This retirement has been underway for a while. Most people just haven’t looked at the calendar yet.

The rough runway, from Oracle’s published SOAP deprecation plan, as of early September 2026:

• 2025.2 was the last regularly scheduled new SOAP endpoint. It is supported through 2028.2.
• 2026.1 stopped including new SOAP endpoints by default.
• 2027.1 blocks building any new integration on SOAP, and per Oracle’s current overview also narrows support to just the 2025.2 endpoint. Existing integrations keep running. Earlier versions of Oracle’s FAQ placed that endpoint narrowing at 2027.2, so verify the exact release against your account’s SuiteAnswers before you plan around it.
• 2028.2 is the end. SOAP is removed, and anything still on it stops.

Two years sounds like plenty until you remember that the replacement work has to compete with everything else on your roadmap, and that every other NetSuite customer’s integration team will be booking the same consultants in 2028.

The trap: REST is not a drop-in

Here is where teams get hurt. They assume swapping SOAP for SuiteTalk REST is a find-and-replace on the endpoint. That assumption is wrong, and the reason is how REST returns data.

REST collection endpoints are built on a hypermedia model. Ask for a list of sales orders and you get back a page of record IDs and links, and then you make another call to read each actual order. So pulling 100 orders with their line items becomes one list call plus a hundred detail calls, roughly 101 requests, where your old SOAP integration got the same data back in a single fat response. You cannot expand the sublists on the list request either, which is exactly the thing you want to do. There is a partial fix on the record side: the REST batch record-collection call can fetch a set of IDs in one request with expandRecords, and expandSubResources pulls the sublists in with them, which shrinks the parade considerably once you already know the IDs. It does not help you find them in the first place.

Now combine that with the concurrency ceiling, and a naive port will fail outright at volume.

The escape hatch is SuiteQL, NetSuite’s SQL-like query language exposed through the REST query endpoint. Instead of the 101-call parade, you write one query with the joins you need and get back a flat, fully populated result set. If you take one technical thing from this post, take that. For any bulk read, reach for SuiteQL rather than the record list endpoints. It is the difference between a migration that works at volume and one that spends its life throttled.

The ceiling nobody budgets for

NetSuite governs how many requests you can run at once, and the limit is per account and shared across SOAP, RESTlets, and REST web services together. The base number depends on your service tier: five concurrent requests on Standard, fifteen on Premium, twenty on Enterprise and Ultimate. Each SuiteCloud Plus license adds ten, up to a per-tier cap. Go over and you get an HTTP 429, request throttled.

The reason this matters for a SOAP migration is that the REST N+1 pattern above spends concurrency like water. The old integration made one call. The lazy replacement makes a hundred, in parallel, and eats the whole account’s budget while it does. The number that matters for your integration is how many concurrent requests it fires, and whether that fits under a ceiling every other integration shares.

The second migration hiding inside the first

Everyone talks about SOAP to REST. Fewer mention that it is really two migrations, because the auth changes too.

OAuth 2.0 only works with REST. SOAP cannot use it, which is a structural reason SOAP is going away at all. So your SOAP integrations are almost certainly on token-based auth, OAuth 1.0a, or old login credentials, and those are being phased out on their own clocks. Reported dates put the end of the old credential login and the block on new token-based-auth integrations around 2027.1, while existing token-based integrations keep working for now under current guidance. Treat that as a reprieve, not a plan. If you plan the API swap and skip the auth swap, you are only half done, and the half you skipped is the one that fails silently in production.

Before you assume REST covers you

One more honest caveat. Oracle is closing the gap between SOAP and REST every release, but it has not promised full parity. Reported thin or missing areas in REST include some legacy tax data, certain translation sublists, complex account-specific saved searches, and a few file cabinet operations. The 2026.1 release did add batch operations and a pile of newly supported record types, so it is improving fast. Still, the move that saves you is boring. Inventory first. Map every app, every custom record, and every field that touches NetSuite, note which auth each uses, and confirm REST actually supports what you need before you commit a timeline to it.

What I would do right now

You have a little time and a real amount of work ahead. In order:

1. Inventory. List every integration hitting NetSuite, its API, and its auth type. You cannot plan what you have not counted. This is the same discipline that keeps you out of integration debt in the first place.
2. Find the SOAP and the old auth. Those are your migration targets. Old iPaaS connectors and bespoke SDK jobs are the usual suspects.
3. Redesign, do not port. For every bulk read, plan SuiteQL instead of list-then-loop. Model the concurrency cost before you build.
4. Migrate auth to OAuth 2.0 in the same pass. Client credentials flow for the unattended jobs.
5. Upgrade your connectors. If you run Celigo, Boomi, Workato, or similar, newer versions handle REST and OAuth 2.0 for you. This is also a fine moment to ask whether the platform you are on is still the right one.

None of this is dramatic on its own. It is inventory, redesign, and testing, done before a deadline instead of during an outage. I have spent enough of my career on the cleanup side of other people’s integrations to know which of those two versions I would rather be part of. Do the boring one. Your 2028 self will owe you a beer.