The Legacy ERP Sunset Countdown 2027-2035 — SAP, Microsoft, Oracle Are Moving On

Who Ends Support First — Timeline to 2035

2026 is the year three major vendors all started announcing sunset dates together. Enterprise customers who have relied on legacy ERP for decades are being forced to choose: move to the vendor's cloud, or diversify elsewhere.

Notice that PeopleSoft is the "loosest" — Oracle has chosen not to set a fixed endpoint, instead committing to support at least 10 years forward ("rolling 10-year"). SAP and Microsoft, in contrast, are firm on their deadlines. Organizations need to start migration planning now, because ERP migration typically takes 12-36 months (see ERP Implementation Planning).

The Real Cost of Migration — Beyond Licensing

Liz Herbert of Forrester has analyzed large-enterprise migration costs and reports that they can reach "a billion dollars" — including data migration, software licenses, consulting, and training. That number sounds extreme, but for a Fortune 500 running SAP ECC for 15-20 years with heavy customization, it is not unrealistic.

When you break migration cost down by category (approximate weightings from real projects), licensing is actually the smallest slice — the biggest slices are "people + time":

• Data migration + cleansing — clean 15-20 years of legacy data, map fields, validate integrity, reconcile balances
• Consulting / System integrators — SAP/Oracle/Accenture/Deloitte partners charge premium rates
• Customization rebuild — custom ABAP, PeopleCode, and Dynamics Extensions all have to be rewritten on the new platform
• Training + change management — thousands of end users plus business-process re-engineering
• Downtime + parallel run — running old + new systems side-by-side for 3-6 months to validate data consistency

And none of that includes the "postponement premium" some organizations end up paying. Greg Leiter of Gartner warns that vendors "will not offer further extensions, but one can expect if they do, it will come at higher costs." If you want extended support, expect to pay a steeply rising premium for it.

The 3 Paths Vendors Are Pushing — Compared

When vendors force you to move, they have destinations ready for you. All three vendors point to the same place — their own cloud. Here is a side-by-side comparison of the three paths:

The notable pattern is that all three paths carry high vendor lock-in risk — not because cloud is inherently bad, but because each vendor designs their architecture to make leaving difficult. SAP binds the application layer to HANA, Oracle binds middleware to Oracle Cloud Infrastructure, Microsoft binds integration to Azure AD + the Power Platform.

The New Lock-in Hiding Inside "Cloud"

A common misconception is that "move to cloud = freedom to move anywhere." The reality is often the opposite — cloud migration frequently makes it harder to leave than before. Several reasons:

• Data residency + compliance — your data lives in the vendor's data center, and the export format is usually proprietary, not standard CSV/SQL
• Proprietary APIs — integrations written against vendor-specific APIs (Oracle REST, SAP OData) cannot be reused with a different vendor
• Licensing bundles — cloud ERP purchases often force you to also buy the vendor's database, identity provider, and BI tooling
• Custom code "locked" in the sandbox — extensions written on cloud platforms (SAP BTP, Oracle APEX) will not run outside the cloud

The author's position here is not "lock-in equals bad" — every platform has some degree of lock-in, even Linux distributions have lock-in. The real question is "choose the vendor wisely." Pick a vendor that does not hold your data hostage, allows free export, and does not weaponize sunset dates to coerce customers (see a deeper treatment at Vendor Lock-in).

Cloud is fine and often inevitable. But before committing to a migration, answer three questions: (1) Can data be exported in a standard format? (2) Are the APIs open standards (REST + JSON schemas) or proprietary? (3) If I want to move off this platform in 5 years, how long will it take?

Option 4 — Thai-Built ERP With No Forced Sunset

Beyond the three paths the big vendors point you toward, there is a fourth — ERP built in Thailand, where there is no "vendor-imposed sunset date" because the vendor is local, not a multinational HQ in Germany or California dictating end-of-support dates.

Saeree ERP is developed in Thailand by Grand Linux Solution Co., Ltd. — you can deploy it on-premise or in the cloud (the customer decides, not the vendor), upgrade on your own schedule, and the codebase uses open standards (Java + PostgreSQL) with no proprietary runtime.

To be honest: Saeree ERP is not a drop-in replacement for SAP S/4HANA at Fortune 500 scale with 50-country manufacturing footprints. Saeree's strength is with mid-to-large Thai enterprises that want:

• Vendor sovereignty — a vendor who is local, responsive, and understands the Thai context (VAT, tax invoices, e-Tax, GFMIS)
• Data sovereignty — data stays in Thailand 100%, no cross-border servers required
• No forced cloud migration — on-premise is available indefinitely, and you can move to cloud later when you are ready

For a detailed Saeree vs SAP comparison, see Saeree ERP vs SAP, and for a broader Thai-vs-foreign comparison see ERP Thai vs Foreign.

Suitable / Not Suitable — When Saeree ERP Fits

To keep the decision grounded, here is a plain "fit / no-fit" table — because knowing when Saeree is not the right answer matters just as much as knowing when it is.

If that table reads as a fit for you, the articles ERP Pricing Tiers and How to Choose an ERP will help you size the budget and build a selection checklist. Government agencies should also see ERP for Thai Government.