SAP Doesn't Lock You In. It Sets a Clock You Can't Turn Off.

Somewhere right now, a CIO is staring at a project plan with a date on it: December 31, 2027. That is the day SAP stops mainstream maintenance on the version of ERP that quietly runs her company's payroll, supply chain, and books.³ The software still works. It will keep working on January 1. Nothing breaks. And yet she is about to spend years and a fortune migrating off it anyway - not because the old system failed her, but because the company that sold it to her decided when its clock should stop.

The popular story is that SAP's hold on its customers is a classic case of switching cost: the software is so embedded, so customized, so wired into every department, that ripping it out is too painful to attempt. That's true, and it's not the interesting part. The real mechanism is sharper and more deliberate. SAP isn't waiting for switching cost to trap people. It is manufacturing a deadline - and then selling the extensions to it.

The moat isn't the difficulty. It's the date.

Here is the thesis a smart friend could repeat at dinner: SAP's lock-in is not primarily switching cost - it's a vendor-controlled deadline cycle. SAP owns the maintenance clock on legacy ECC, and by choosing when that clock runs out, it converts a customer's option to upgrade into an obligation. The migration to S/4HANA and its cloud bundle, RISE with SAP, gets sold as digital transformation. Functionally, it is closer to a toll bridge with a posted closing time. You can take it now, take it later for a premium, or be left on a road that no longer gets repaired.

Look at why that's such a strong position. Switching cost alone is passive - it just makes leaving expensive. A controlled deadline is active. It tells the customer not just that leaving is hard, but when they must move, and it points the only convenient exit toward SAP's own newest, highest-margin product. The same firm that built the dependency also holds the timer. That is the difference between a moat you fell into and a moat the vendor walks you into.

Why the migration genuinely takes years

The years are not a myth, but they're not uniform either. The move from ECC to S/4HANA is, for a large enterprise, a rebuild of decades of accumulated business logic - every custom transaction, every report, every integration touched and tested. Gartner clients with complex environments have anticipated projects of three to seven years; simpler, less customized organisations can be done in as few as 12 months.⁵ Typical enterprise timelines run 12 to 24 months, with complex global multi-entity deployments stretching to 18 to 24 months or more.⁷ The headache is concentrated where the customization is deepest - exactly the customers SAP can least afford to lose.

And these projects miss. A Horváth study of 200 SAP user companies found that more than 60% of ECC-to-S/4HANA migrations deviate significantly from planned budget, schedule, or quality - and only 8% finish on schedule, with the average project running about 30% longer than planned.⁶ Stack that overrun rate against a fixed external deadline and you get the squeeze: the harder a project is to finish on time, the more a hard date works in the vendor's favor. The customer's difficulty is the vendor's leverage.

The cliff is really a staircase of paid steps

The framing you'll see everywhere - '2027 is a hard cliff' - quietly understates the cleverness. Mainstream maintenance for the core Business Suite 7 applications, including ECC 6.0 EHP 6-8, ends December 31, 2027. After that, SAP sells optional extended maintenance through the end of 2030, at a two-percentage-point surcharge on the maintenance base.³ It is not a wall. It is a staircase, and SAP charges admission on each step: pay to migrate now, or pay a premium to delay. Either way the meter runs toward SAP, and the longer you stall, the more you pay for the privilege of standing still.

Why does SAP have the nerve to set this clock at all? Because it can read its own book of business. Cloud revenue reached €17.14 billion in 2024 and is now SAP's largest revenue stream, with total cloud backlog of €63 billion, up 40%.¹² The vast majority of license customers also sign recurring support contracts.² In other words, SAP already collects a predictable annuity from the installed base - 83% of its 2024 revenue was the more predictable kind.¹ The deadline simply converts that captive annuity into new cloud bookings on SAP's preferred timetable. The clock isn't a threat to the relationship; it's the harvesting mechanism for it.

If the lock-in is so strong, why hasn't it worked yet?

Here's the honest objection, and it's a good one. If SAP truly controls its customers, why has it persuaded so few to actually move? As of end-2024, only about 39% - roughly 14,000 - of SAP's ~35,000 ECC customers had even purchased S/4HANA transition licences, and a purchased licence is a proxy for intent, not a completed migration.⁴ Gartner projects around 17,000 holdouts will still be on ECC at the 2027 deadline, and more than 13,000 will remain on ECC in 2030.⁴ As one Gartner VP put it bluntly, SAP convinced less than half of clients in fifteen years.⁴ That is not the record of an all-powerful jailer.

But read the resistance carefully and it confirms the thesis rather than refuting it. Customers aren't fleeing to a rival ERP - they're refusing the timetable, which is exactly the variable SAP controls and keeps relaxing. The fact that SAP added extended maintenance to 2030 and longer paid transition options for large customers is the tell: when too many customers balked at the 2027 date, the answer wasn't to lose them - it was to sell them another extension. Slow adoption isn't the lock-in failing. It's the lock-in being repriced. A wall that customers ignore would be a failure. A staircase customers climb slowly, paying at each step, is the business working as designed. And the looming talent crunch around 2027 - with thousands of companies needing the same scarce migration specialists at once⁵ - only tightens the squeeze on the holdouts SAP hasn't yet collected from.

SAP likes to say its customers generate the overwhelming majority of global commerce⁸ - a self-reported figure, but a revealing ambition. The company's real product was never the software in the box; it's the position in the middle of everything, and the right to decide when that position needs renewing. The migrations take years because the systems are deep. The migrations happen because the clock runs out. SAP didn't have to make leaving impossible. It only had to make staying expire on a schedule it writes - and then sell you a little more time.