NetSuite SOAP Deprecation: What to Review Now?

NetSuite SOAP Web Services are going away. But the first step is not to rebuild every integration in REST.

It is to understand what is using SOAP today, which business processes depend on those connections, who owns them, and which migration paths need to be validated.

Oracle NetSuite has confirmed that the 2025.2 SOAP endpoint is the last planned endpoint and that SOAP Web Services will be removed with the NetSuite 2028.2 release. Existing SOAP integrations will then stop working. 

For European companies running NetSuite across several entities, countries and applications, this makes SOAP migration more than an API project. A connection may support billing, order processing, CRM, banking, tax or reporting workflows.

The right starting point is visibility.

‍

What is changing with NetSuite SOAP Web Services?

Oracle is gradually retiring SuiteTalk SOAP Web Services and positioning SuiteTalk REST Web Services as its replacement. Oracle recommends that all newly built integrations use REST Web Services with OAuth 2.0. 

The transition can be summarised as follows:

There is an important distinction between supported, available but unsupported, and retired.

A supported endpoint can still receive bug fixes from Oracle. An unsupported endpoint may remain technically available but is no longer supported. A retired endpoint is disabled and can no longer be used. Oracle’s SOAP Removal Plans FAQ shows this progression release by release.

Oracle’s documentation currently contains a small timing difference: several WSDL documentation pages state that only the 2025.2 endpoint will be supported from 2027.1, while the SOAP Removal Plans FAQ states 2027.2. Customers should therefore verify their endpoint against Oracle’s latest documentation when planning their migration.

It is also important to note that 2028.2 refers to a NetSuite release, not a fixed calendar date. The actual timing depends on Oracle’s release schedule for each account.

‍

Why is NetSuite moving from SOAP to REST?

Oracle is investing in REST Web Services and OAuth 2.0 as the strategic integration model for NetSuite.

SuiteTalk REST Web Services is the intended replacement for SOAP, and Oracle recommends that customers with custom SOAP integrations start planning their migration to REST.

Where a specific requirement cannot be covered directly through REST Web Services, a SuiteScript RESTlet may be an alternative.

This is why a SOAP migration should not be treated as a simple endpoint replacement. Each integration needs to be reviewed against the process it supports.

‍

What should NetSuite customers review now?

A SOAP readiness review should answer one simple question:

Where does SOAP sit in our NetSuite architecture, and what would happen if each connection stopped working?

That requires more than an integration count.

‍

1. Identify every active SOAP integration

Create an inventory of integrations communicating with NetSuite through SOAP.

For each connection, capture:

• integration or application name;
• current SOAP endpoint;
• authentication method;
• recent activity;
• source and destination systems;
• integration owner;
• business process supported;
• implementation partner or software provider, where relevant.

Activity data is useful, but it is not enough. An interface that runs once a month or once a year may still support an essential finance process.

Usage tells you what is running. Business validation tells you what matters.

‍

2. Understand the business process behind each connection

Technical names rarely tell the full story.

For every SOAP integration, determine:

• What process does it support?
• Which teams or subsidiaries depend on it?
• What data enters or leaves NetSuite?
• How frequently does it run?
• What happens operationally if it fails?

This is especially important for European groups with multiple entities. A low-volume connection may still be business-critical for one country or finance process.

‍

Not every SOAP integration has the same migration path

Different integrations can require very different actions.

‍

Customer-owned integrations

If your team or implementation partner developed the integration, assess the existing SOAP operations and determine how they map to SuiteTalk REST Web Services or RESTlets.

Oracle recommends that customers running custom SOAP applications start planning the move to REST as soon as possible.

‍

Partner-managed applications

If the integration is maintained by another software provider, the key question may be:

When will the provider deliver a REST-based version, and what do we need to test before moving to it?

Oracle recommends consulting the provider of partner-developed SOAP applications to confirm the availability of a REST-based replacement.

External dependencies should be identified early. Otherwise, an apparently simple migration can remain blocked by a vendor roadmap.

‍

NetSuite-provided applications

Where the SOAP-based application is provided by NetSuite, Oracle states that a REST-based application will be provided. Customers should still monitor the replacement path and plan testing around the change.

‍

Review the endpoint version, not only whether SOAP is used

Knowing that an integration uses SOAP is not enough.

You also need to know which WSDL endpoint it uses and whether that endpoint is:

• supported;
• available but unsupported;
• or already disabled.

Older endpoints will progressively move from supported to unsupported before being disabled completely. Oracle’s Support for Existing WSDL Versions documentation should therefore be checked as part of every SOAP assessment.

This creates two separate questions:

1. Is the current endpoint still supported or available?
2. What is the long-term REST migration plan?

Updating an old SOAP endpoint may reduce short-term risk, but it does not replace the need to move away from SOAP before the 2028.2 release.

‍

Review authentication at the same time

The SOAP transition is also an opportunity to review authentication and integration governance.

For each integration, consider:

• integration records;
• authentication flows;
• roles and permissions;
• credentials and secrets;
• environment-specific configuration;
• monitoring and error handling.

Oracle recommends REST Web Services with OAuth 2.0 for newly built integrations.

Changing the API without reviewing the surrounding integration setup would leave part of the technical debt untouched.

‍

SOAP to REST is not always a one-to-one conversion

One common mistake is assuming that every SOAP operation has an identical REST equivalent.

For each integration, validate the records and fields involved, the operations performed, the expected transaction volumes and the way errors are handled.

Testing should cover the complete business process, not only successful API responses.

‍

What should CTOs and technology leaders review?

For a CTO or technology leader, the SOAP deprecation is not only a technical migration question. It creates a planning and business continuity issue.

The main areas to review are:

• Business exposure: Which revenue, finance or operational processes would be affected if an integration stopped working?
• Budget and capacity: What development, testing and project capacity will be required before the relevant NetSuite releases?
• Vendor dependencies: Which migrations depend on external software providers or implementation partners?
• Ownership: Is there a clear technical and business owner for every SOAP integration?
• Delay risk: What would happen if a migration is postponed until close to the final SOAP removal release?

The earlier these points are understood, the easier it becomes to allocate resources and avoid multiple migrations becoming urgent at the same time.

‍

What should European finance teams pay attention to?

European NetSuite groups often depend on integrations across multiple systems and countries.

SOAP connections may support:

• CRM-to-order processes;
• subscription and usage billing;
• expense platforms;
• banking and payments;
• tax and e-invoicing;
• procurement;
• BI and data warehouses;
• local operational applications.

This means priority should not be based on technical complexity alone.

A small interface supporting a country-specific finance process may carry more operational risk than a much larger data sync.

A useful prioritisation model combines business criticality, migration complexity, ownership and deadline risk.

‍

How should you prioritise SOAP integrations?

Rather than putting every interface into one migration backlog, divide them into clear categories:

• Business-critical: supports a process that cannot tolerate significant downtime.
• Active, lower-risk: still required but with limited operational impact.
• Needs investigation: usage, ownership or replacement path is unclear.
• Vendor-managed: depends on an external software provider.
• Candidate for retirement: inactive, duplicated or no longer required.

This avoids spending time migrating integrations that should simply disappear.

The goal is not to convert the highest number of SOAP connections. It is to make sure the integrations the business still needs have a safe path forward.

‍

Should you migrate directly to REST or use an iPaaS?

For a small number of simple interfaces, direct REST integration may be appropriate.

For a more complex application landscape, the SOAP deprecation can also be an opportunity to review whether point-to-point integrations still make sense.

An Integration Platform as a Service (iPaaS) can centralise integration flows, transformations, monitoring and error handling instead of distributing that logic across multiple custom connections.

The decision should be architectural rather than automatic.

‍

Why start before 2028?

The main challenge is often not the technical conversion itself. It is coordination.

Before an integration can be replaced, someone may need to:

• identify its owner;
• confirm whether it is still used;
• validate the business process;
• contact a vendor;
• assess REST functionality;
• develop and test the replacement;
• schedule a production cutover.

Across several subsidiaries and systems, that takes time.

Starting now does not mean replacing everything now. It means removing uncertainty while there is still time to make informed decisions.

‍

Build a NetSuite SOAP migration roadmap

Once the assessment is complete, turn the findings into a practical roadmap.

Phase 1: Discover

Create the integration inventory and validate actual activity.

Phase 2: Qualify

Confirm ownership, business purpose, criticality, endpoint status and dependencies.

Phase 3: Design

Choose the target architecture: REST Web Services, RESTlet, vendor replacement or iPaaS.

Phase 4: Build and test

Develop the new flow and test the end-to-end business process.

Phase 5: Cut over and retire

Move production traffic, monitor the result and disable obsolete SOAP connections.

‍

What does a NetSuite Technical Readiness Assessment deliver?

A NetSuite Technical Upgrade Readiness Assessment should provide more than a technical inventory.

The expected output is:

• A validated inventory of active SOAP integrations and their current endpoint status.
• Risk prioritisation based on business criticality, ownership, dependencies and migration complexity.
• A recommended migration path for each integration, such as REST Web Services, RESTlet, vendor replacement or retirement.
• A practical roadmap showing priorities, ownership and the sequence of remediation work.

This gives technical and business stakeholders a common view of what needs attention and what can wait.

‍

How Novutech can help

Novutech helps European growth companies review their NetSuite architecture and prepare for technical change.

Our teams can assess existing SOAP integrations, endpoint versions, activity, authentication, ownership and dependencies, then help define a practical migration path toward SuiteTalk REST Web Services, RESTlets or an integration platform where appropriate.

With 250+ customers, 65+ consultants and 100+ certifications, Novutech combines NetSuite expertise with integration and finance-process knowledge to support companies from assessment through remediation and long-term support.

‍

Review now, migrate with a plan

NetSuite SOAP Web Services will disappear with the 2028.2 NetSuite release. This is a release milestone rather than a fixed calendar deadline.

The most valuable step today is not mass migration. It is knowing:

• what is connected;
• what is still active;
• which processes depend on it;
• who owns the change;
• which replacement is appropriate;
• and when the work should happen.

Once those questions have answers, SOAP deprecation becomes a manageable migration roadmap rather than a last-minute technical issue.

‍

Ready to assess your NetSuite integrations?

If you are unsure which SOAP integrations are still active, which business processes rely on them or how they should move to REST, Novutech can help you build a clear readiness and remediation plan.