Sage 100 sData was removed in 2025. What replaces it?

What exactly changed in 2025

• The Sage 100 2025 "What's New" page lists the removal: the SData Security tab is gone from Role Maintenance, the Enable Native SData Provider checkbox is removed, and the Native SData Provider Adapter is no longer an install option.
• A Sage staff answer on the Sage community confirmed that sData support ends with the Sage 100 2025 release, and named BOI as the path forward.
• Sage 100 2026 is 64-bit only. If you replace sData with a program that loads BOI or the ODBC driver, build it 64-bit from the start.

If you stay on a version before 2025, sData still runs there, but Sage supports only the current and two prior versions. That buys time, not a solution.

Your four options

1. Build on BOI yourself

Write a small Windows service next to Sage 100 that calls BOI for writes and ODBC for reads, and exposes what you need over HTTPS. This is the sanctioned route. The service signs in as a Sage 100 user, and that session usually takes a license seat; confirm the licensing for your version with your reseller. You own retries, error mapping, version upgrades and the network path (an outbound connection is easier for the customer's IT than an open inbound port). See the BOI guide for the code.

2. eBusiness Web Services (SOAP)

Sage's eBusiness Web Services expose a SOAP interface on IIS on the Sage 100 server. Its role security covers create, modify, remove and view for sales orders, customers and contacts, so its scope is narrow. It needs IIS, .NET and an activation that enables it. Check with your reseller that it is still offered for your version before you plan on it.

3. Read-only through ODBC

If your sData use was only reads, the bundled ODBC driver covers customers, orders, items and history with plain SQL. It cannot write. See the ODBC guide.

4. A third-party REST bridge

Several Sage partners sell REST APIs that wrap BOI, for example sage100restapi.com (public price about $2,700 per year), Kissinger's API 100, and DSD's Connector API. Most quote on request. Compare coverage of the modules you use, whether writes go through BOI, and how the product handles Sage 100 upgrades.

Migration checklist

1. List every sData call your integration makes, and mark each as read or write.
2. Map reads to tables in the Sage 100 file layouts (for example AR_Customer, SO_SalesOrderHeader) and writes to business objects (for example SO_SalesOrder_bus).
3. Decide where the replacement runs (the Sage server or a workstation with the Sage 100 client) and how it reaches your application: outbound HTTPS from the customer network is the least friction.
4. Create a dedicated Sage 100 user with a role limited to the tasks you call.
5. Test against a copy of the company on the version the customer will run next, 64-bit.

Sources: Sage 100 2025 What's New, Sage KB: sData, Sage community: is sData still supported, eBusiness Web Services guide.