NetSuite SOAP End of Life: 5 Migration Gaps to Check Before 2028

🚨With the NetSuite 2028.2 release, scheduled for the second half of 2028, SOAP Web Services will be removed completely. The exact cutoff date will depend on when each NetSuite account is upgraded to 2028.2.

How to find hidden SOAP connections, test the replacements, and explain the risk to management

Most NetSuite administrators already know that SuiteTalk SOAP Web Services is being retired. The difficult question is not whether you need to migrate. It is whether you can find every affected integration—and prove that its replacement works correctly.

A REST request can succeed while an order is missing a line or another system receives the wrong status. A quarterly integration may not appear during a short review. A supplier-managed connector may use SOAP without your team knowing.

With NetSuite 2028.2, all SOAP endpoints will be disabled and remaining SOAP integrations will stop working. From 2027.1, new SOAP integrations can no longer be created. Oracle says SuiteTalk REST Web Services is the intended replacement, but it also says that REST will not replace every SOAP feature in the same way.

The deadline is known. The real risk is what your organisation does not yet know.

Gap 1: An empty usage log does not prove you are SOAP-free

Start with

Setup > Integration > SOAP Web Services Usage Log.

It shows synchronous SOAP requests and lets you filter by date, record type, and operation.

However, a quiet log is not proof that SOAP is no longer used. Oracle says the log does not show asynchronous requests. Request and response details are normally available for 21 days and may be removed earlier when activity is high. Monthly, quarterly, annual, or exception-based jobs can therefore stay hidden.

You cannot build a complete list from one NetSuite screen. Check four areas:

Inside NetSuite: Review the SOAP Usage Log, the Execution Log on each Integration Record, and the Integration and Automation Usage reports.

Outside NetSuite: Check middleware, Celigo flows, scheduled jobs, custom applications, and scripts hosted elsewhere.

With suppliers: Ask connector and application vendors whether their products use SOAP and when they will provide a replacement.

Across the business: Speak with finance, operations, ecommerce, and logistics teams about processes that run only at certain times.

Each area shows a different part of the picture. Put the findings into one list with the owner, connected system, WSDL version, login method, frequency, supplier, and business impact.

Do not ask only, “Where is SOAP being used?” Also ask, “Which business process would fail if this connection stopped?”

Need help with migration? Schedule a free quickscan. Click Here.

Gap 2: One SOAP workflow may need several replacements

The risk appears when a team finds a REST version of one SOAP operation and assumes the full workflow has been replaced. The API call may work while a saved search, custom rule, order line, confirmation, or update to another system is missing.

SOAP and REST handle searches, multiple pages of results, errors, record lines, and supported records differently. One SOAP workflow may therefore need a combination of:

• SuiteTalk REST Web Services for supported record actions
• SuiteQL for searching and combining NetSuite data
• SuiteScript RESTlets for custom logic that REST does not support
• Celigo for connecting systems, changing data formats, monitoring, and error handling
• A redesigned process when copying the old setup would keep unnecessary complexity

This is why you must map the business result, not only the SOAP method. “Create a sales order” may sound like one action. In practice, it may also require the right customer, price, tax, custom fields, stock allocation, ecommerce confirmation, and warehouse update.

If the team replaces only the SOAP add operation, NetSuite may create the order while the full order process remains incomplete.

This is where an outside review can help. Teknuro’s NetSuite SOAP Exposure Quickscan links technical calls to the business processes behind them, so missing steps can be found before go-live.

Gap 3: Login and permission problems can appear late

OAuth 2.0 should be planned as part of the integration, not added just before go-live. Integration Records, roles, permissions, stored credentials, tokens, and environment settings all affect whether the connection works.

An old SOAP integration may use a role with very broad access. Copying that role gives the new integration more access than it needs and can make problems harder to find.

Create a role with only the permissions required. Test it in Sandbox with the same record types, subsidiaries, custom fields, scripts, and workflows used in production. Also decide how credentials will be stored, changed, monitored, and removed.

Gap 4: A successful API response does not prove the process works

Technical testing often checks that the connection succeeds and REST returns a successful response. Business testing must go further.

Where possible, run SOAP and the new integration at the same time and compare:

• Record and line counts
• Quantities and financial totals
• External IDs, statuses, and linked records
• Tax, currency, subsidiaries, custom fields, and record lines
• Results received by other systems
• Duplicates, retries, and partial failures

Test realistic volumes and problems—not only perfect transactions. Interrupt a connection, create a duplicate, remove a permission, or send invalid data. Check that the error is visible, understandable, and safe to retry.

The test should prove that “the business result is correct and errors can be recovered,” not only that “the API call succeeded.”

Gap 5: Nobody owns the integration after go-live

An integration can pass testing and still become a problem if nobody owns its alerts, errors, credentials, or supplier questions.

Before go-live, agree on:

• Who monitors alerts
• Who investigates and fixes errors
• How records and totals will be checked
• Who manages credentials
• What the internal team and suppliers each support
• When to roll back a failed release
• What documentation and training are needed

The technology does not remove the need for ownership. Whether you use NetSuite REST, middleware, custom APIs, or an integration platform, you still need error handling and a clear support process.

A practical NetSuite SOAP exposure check
Ask these eight questions:

1. Have we reviewed SOAP activity across a normal business period?
2. Have we checked every Integration Record and its API version?
3. Have we included asynchronous, low-frequency, and external jobs?
4. Have all suppliers confirmed their migration plans?
5. Do we know the owner and business impact of every SOAP process?
6. Has every process been mapped to the right replacement?
7. Can we prove that the replacement gives the correct business result?
8. Is someone responsible for monitoring and support after go-live?

If several answers are “no” or “unknown,” you do not yet have a migration plan. You have a business risk that has not been measured.

How Teknuro can help

You may know NetSuite very well. However, this migration also requires knowledge of APIs, OAuth, Celigo, SuiteQL, SuiteScript, testing, monitoring, and business processes across several systems.

Teknuro’s NetSuite SOAP Exposure Quickscan can provide:

• A clear list of SOAP integrations and owners
• Business impact and migration risk ratings
• Hidden jobs and supplier dependencies
• The best replacement approach for each process
• A phased roadmap and management summary

As a Celigo partner, Teknuro can rebuild integrations on Celigo when it is the right choice. We can also combine Celigo with NetSuite REST services, SuiteQL, RESTlets, or custom APIs. We choose the solution based on the business process—not on one tool.

We can support discovery, design, implementation, security, testing, go-live, documentation, monitoring, and ongoing support. Most importantly, we check that the whole process works—not only the endpoint.

Can you prove your integrations are ready?
The organisations most at risk are those that cannot see their dependencies, do not know who owns them, or have not decided how to test their replacements.

Starting early gives you time to investigate unknowns, work with suppliers, and move one process at a time. It can also improve security, visibility, documentation, and reliability.

Sources
Oracle NetSuite: SOAP Removal Plans FAQ
Oracle NetSuite: Using the SOAP Web Services Usage Log
Oracle NetSuite: Creating Integration Reports
Oracle NetSuite: SOAP Web Services Execution Log

Not sure where SOAP is still being used or whether the replacements will work in production?

Schedule a free Integration Quickscan with Teknuro to measure the risk and create a practical migration roadmap.

Fill in the form: