Rimini Street做的不是开发软件，也不是销售新系统。这家公司瞄准的是Oracle和SAP客户每年都要支付的高额维护费：企业买完软件许可后，仍要持续向原厂支付维护费用，而Rimini Street提供的方案，是以更低价格承接这部分支持服务。
高价维护费撑起第三方支持市场
按照文中举例，企业如果花 100 万美元购买Oracle软件许可，从第二年起通常还要支付许可费 22% 的年度维护费，也就是 22 万美元。该费用每年还可能上涨 4% 到 8%。按这一口径计算，100 万美元的许可，5 年累计维护费会超过 130 万美元，已经高于最初的软件采购成本。
不续维护并非不可以，但代价也很直接：企业将失去安全补丁、法规更新和技术支持。对承载财务、采购、供应链等核心流程的系统来说，这类支持关系到持续运行和审计合规，很多企业很难真正停掉。
SAP的情况也类似。文中提到，全球约有 35,000 家公司在使用SAP ECC系统。SAP在 2015 年推出S/4HANA，但到现在，仍有超过一半客户没有迁移。原因并不复杂：迁移成本高、周期长。中型企业升级一次往往要花数百万美元，大型跨国公司甚至可能达到 10 亿美元，项目周期通常在 18 到 36 个月。
相比之下，已经运行多年的旧系统虽然不新，但往往足够稳定。对于很多企业而言，只要财务、采购和供应链仍能正常运转，停下业务去重做系统，并不是优先选项。
Rimini Street的切入点正是在这里：客户继续使用原有软件，但把维护服务从原厂转给第三方，以更低成本维持旧系统运行。
从PeopleSoft到Rimini Street，Seth Ravin押注旧系统支持
Rimini Street的创始人 Seth Ravin 很早就接触过这类需求。上世纪90年代，他曾在PeopleSoft任高管，负责客户销售，并在公司内部推动过一项延长支持计划，服务那些系统已经稳定、不愿被迫升级的客户。
2002 年，Ravin与他人共同创办TomorrowNow，继续做同一类业务，为Oracle旧系统客户提供维护支持，收费约为原厂一半。2005 年，SAP收购TomorrowNow，Ravin在收购完成后仅停留了 3 个月便离开。
此后，Oracle起诉SAP和TomorrowNow侵犯版权。最终，SAP赔偿 3.59 亿美元，TomorrowNow关停。
同年，Ravin在拉斯维加斯再次创办Rimini Street，商业模式与此前相近。Oracle随后再次发起诉讼。2010 年，Oracle正式起诉Rimini Street，理由仍是版权侵权。
与Oracle缠斗15年，关键裁决落在“合法竞争”
Rimini Street与Oracle的争议持续了 15 年。2015 年首次审判中，Oracle提出 24 项指控，最终只赢下一项，且法院认定为“无意侵权”。按文中表述，法院认为Rimini并非故意侵权，问题更多出在流程层面。
2018 年，美国第九巡回上诉法院推翻了更多不利判决，Seth Ravin的大部分个人责任被免除。文中援引法院表述称，Rimini Street提供第三方支持，是在与Oracle的直接维护服务进行合法竞争。
2019 年，案件上诉至美国最高法院。9 名大法官一致裁定，Oracle必须向Rimini Street返还 1280 万美元。
不过，纠纷并未完全结束。2023 年，内华达州一名联邦法官在PeopleSoft相关业务线上认定Rimini存在重复侵权，并发布新的禁令。
到 2025 年 7 月，双方最终达成和解。根据文中信息，Oracle返还 3790 万美元律师费，Rimini Street则主动退出PeopleSoft产品线，这部分业务年收入约为 2000 万美元。其核心的Oracle数据库和SAP相关业务则未受影响。
价格更低、覆盖更广，是Rimini Street的核心卖点
Rimini Street能在市场中站稳，首先靠的是价格。文中称，Oracle维护费通常按许可费的 22% 收取，且每年上涨 4% 到 8%；Rimini Street的收费大致只有原厂一半，价格整体更稳定。
其次是服务范围。原厂维护通常不会覆盖客户多年积累的定制代码，而Rimini Street则把这部分一并纳入支持范围。对于最高优先级故障，文中称Oracle没有给出明确响应承诺，而Rimini Street承诺 10 分钟内响应，实际平均响应时间不到 2 分钟。
客户案例也构成了其销售依据。文中提到，美国饮料品牌Welch's的CTO因Oracle EBS维护费占IT预算比例过高，转而采用Rimini Street。按照Rimini官方案例，第一年节省的成本大致相当于公司当年净收益的四分之一。
阿曼最大的私营财团Khimji Ramdas同样被点名为客户。其SAP系统有 700 多个定制模块，若更换系统几乎意味着全部重做。该公司技术负责人在文中表示，切换到Rimini Street后，总维护成本下降了 80%。
日本最大的汽车后市场零售商AUTOBACS与Rimini Street合作已满 10 年。文章称，其系统在此期间没有出现崩溃，节省下来的资金被投入AI和物联网。
业务不止维护，Rimini Street开始卖托管、安全和AI
Rimini Street并不只满足于维护费差价。文中指出，维护只是入口，客户一旦切换到第三方支持，后续往往会继续采购更多服务。
这类延伸服务包括Rimini Manage托管服务，用于日常运维、监控、安全和系统对接；Rimini Connect，用于旧系统兼容新环境；以及Rimini Protect，面向旧系统安全防护。文中称，Rimini Protect背后有 75 名安全专家提供 7x24 支持。
在此基础上，Rimini Street还把AI叠加到现有系统之上。它的思路不是替换底层ERP，而是在原系统外层增加AI能力，用于处理工单、对账、审批等流程。
文中提到，Rimini Street与ServiceNow合作推出了 20 个模板，目前已在 26 家客户处落地。
巴西制药公司Apsen就是其中一个案例。该公司不希望迁移SAP系统，Rimini则帮助其在旧系统上部署ServiceNow的AI工作流，几周内上线。按文中描述，原先一项物料转移流程每月需要人工处理 100 多笔申请，调动超过 5 万件成品，流程依赖邮件和表格；引入AI后，70% 的人工流程实现自动化，开发周期也从几个月缩短到几周。
新模式正在形成黏性，但并不比原厂更稳
文章认为，Rimini Street实际上也在建立自己的“锁”。第一层是帮助客户从原厂维护费中省钱，第二层是把节省出来的预算引导到托管、安全和AI服务上，第三层则是随着新服务不断叠加，客户的替换成本持续上升。
从经营数据看，这套模式已经产生效果。文中给出的数据包括：客户留存率约为 90%，未到期合同总额达到 6.53 亿美元，创历史新高，国际业务增长 14%。
但这把“新锁”也有明显边界。首先是安全补丁能力。文中称，Rimini Street采用的是“虚拟补丁”方案，本质是在系统外部加一层防护，而不是直接修改底层代码。对金融、医疗等强监管行业来说，这种做法可能无法满足审计要求。
其次，客户一旦转向第三方维护，回到原厂的成本也会很高。文中提到，回到Oracle时，客户需要补交 150% 的追溯维护费，SAP也有类似做法。此前节省下来的维护支出，可能在回切时一次性吐回去。
订单下滑与云转型压力并存，原厂也在重建锁定机制
Rimini Street自身也面临增长压力。根据文中信息，公司最新财报显示，订单额同比下降 8.8%，负债高于资产，净资产为负。公司还将销售团队拆分为两组，一组负责拉新客户，一组负责服务老客户并推动续费。
与此同时，Oracle和SAP并未停留在传统维护模式上。文章提到，两家公司正在加快把客户迁移到云上。在SaaS模式下，软件许可控制权重新回到厂商手中，客户不再拥有把软件采购与维护服务拆分选择的空间。过去企业可以向A买软件、找B做维护；上云后，通常只能继续向A购买整套服务。
这意味着，原厂正在通过架构层面的变化强化锁定，而Rimini Street则依靠服务和增值产品提高客户黏性。文章将其概括为“两把锁在赛跑”。
第三方维护模式已从Oracle、SAP延伸到VMware
除了Oracle和SAP，Rimini Street也在复制这一模式。文中提到，博通收购VMware后，取消永久授权并推动价格上升，不少VMware老客户面临更高成本。Rimini Street在 2024 年推出VMware支持服务，不到一年半就签下了 100 多份合同。
按文章说法，Rimini Street已经先后与Oracle、SAP、VMware三类原厂生态正面交手。其立足点仍是同一套逻辑：把软件许可和后续维护视作可以拆分的两项商品，由第三方承接支持服务。
中国市场的对应问题仍未出现本土版Rimini Street
文章最后把视角拉回中国市场，提到用友、金蝶客户在信创和云化环境下面临的绑定逻辑，与Oracle和SAP并无本质差异。不过，文中同时指出，中国市场至今尚未出现一个本土版Rimini Street。
这篇文章来自微信公众号「王智远」（ID：Z201440），作者为王智远。文章没有给出明确答案，只留下一个问题：在厂商持续制造新锁的过程中，是否还会出现新的拆锁者。