Purpose. This document condenses the API, microservices and integration-architecture learnings from the interview responses on cloud ERP migration and its impact on financial reporting. Nine learnings are grouped under four themes. Each is grounded in operator experience across Hotelbeds, Awaze, Lloyds and advisory engagements.
1. Microservices as the Escape Valve from Monolithic ERP
Learning 1 — Build microservices around the ERP for competitive processes
Source: Hotelbeds (2016–2020)
At Hotelbeds, SAP best practices were adopted for the bulk of the back office, but microservices were built around the ERP for the parts that were genuinely competitively differentiating: dynamic pricing, marketplace settlement, and complex multi-currency revenue recognition. The underlying compute was migrated from Telefónica and BT data centres into AWS, adopting a microservices marketplace architecture in parallel.
Key principle: Standardise where you are average; protect configuration freedom where you genuinely compete. The hybrid model (standard ERP core + microservices extensions for differentiated processes) worked. Doing this should be the norm, not the workaround.
Learning 2 — Vendors must deliver composable, microservices-based ERPs
Source: Advisory experience, cross-client
The architectural rhetoric of ERP vendors is ahead of the product reality. Vendors claim composability but deliver monoliths dressed in cloud. The companies that over-customise recreate the legacy maintenance nightmare in the cloud; those that under-customise watch their differentiated processes get flattened into vanilla.
Implication for research: The tension between standardisation and differentiation is the central architectural trade-off in cloud ERP, and APIs/microservices are the mechanism through which that tension is resolved operationally.
2. The BTP Extension Tax and RISE Constraints
Learning 3 — RISE’s clean-core philosophy creates a material API refactor cost
Source: SAP RISE analysis; Spanish retail client engagement (2025)
Under SAP’s RISE model, the “clean core” philosophy and managed-cloud restrictions on operating-system-level access and custom batch jobs limit the kind of microservices extensions built at Hotelbeds. Clients must redesign legacy customisations as SAP Business Technology Platform (BTP) extensions.
Quantified impact: In a recent retail-sector engagement, the BTP refactor cost was modelled at €1.2–1.8M as a base case for a mid-sized estate, with code-Z volume (custom ABAP) as the dominant cost driver. This is an integration tax that rarely appears in the original RISE business case.
Learning 4 — RISE is not a genuine cloud service; APIs do not behave as expected
Source: Tendam/RISE analysis; CIO peer evidence from RTVE, Carrefour, Repsol, Iberdrola, Naturgy, Holcim, Maxam, Amadeus, Cuatrecasas
RISE does not autoscale, services cannot be cancelled at will, and the licensing FUE abstraction can mask real consumption inflation. The standard contract effectively makes the commitment for life. Maxam rewrote core processes in .NET rather than commit further to the SAP stack. The pattern across the corpus: RISE works where the client has negotiated like a hostage negotiator, and fails where the client has trusted the standard SAP commercial frame.
API implication: The promise of cloud-native APIs (autoscaling, elastic consumption, programmatic provisioning) does not hold in the RISE model. Integration architects should treat RISE as a managed on-premise deployment, not a cloud-native platform.
3. Cross-Platform Integration and the Data Autonomy Imperative
Learning 5 — Vendor-embedded AI is siloed; cross-platform layers are a strategic-autonomy decision
Source: Advisory experience, cross-client; Copilot Disruption briefing (Feb 2026)
Vendor-embedded AI is siloed inside its own stack: Workday’s intelligence does not see SAP’s data, NetSuite’s does not see Salesforce’s. The strongest commercial value emerges when companies build a cross-platform data and analytics layer on top of their cloud ERPs rather than relying on what each vendor ships in-stack.
Strategic framing: This cross-platform layer is not merely an architectural preference—it is a strategic-autonomy decision. It is the primary defence against cognitive lock-in, where the vendor’s semantic index, agent configurations and accumulated context become the institutional memory of the finance function, and that memory cannot be exported.
Learning 6 — Ring-fence the organisational data graph in infrastructure you control
Source: Cognitive lock-in framework; Copilot Disruption briefing (Feb 2026)
Recommendation to clients regardless of vendor stack: ring-fence the organisational data graph in a cross-platform layer they control, and treat agent configurations and AI-accumulated context as exportable assets—even when the vendor offers no native export path. The discipline required is similar to the one finance teams already apply to working papers and audit trails: if it is the institutional memory of the function, it does not belong to the vendor.
4. Agent Protocols, Foundation-Model APIs and the Structural Threat to ERP
Learning 7 — SAP risks becoming a data repository accessed by external AI agents
Source: Interview responses, Section E; SAP Sapphire 2025 analysis
Unless SAP engages credibly with cross-platform agent protocols—Google’s Agent-to-Agent (A2A) standard, Anthropic’s Model Context Protocol (MCP)—there is a real risk that SAP ends up as a data repository accessed by agentic AI vendors that sit outside its “best of suite” stack. The vendor’s AI flywheel pitch delivers process automation in the short term but offers no clear answer on autonomous agents.
Contrast: Salesforce has at least committed to outcome-based pricing for its sales agents, charging per qualified new customer. SAP’s strategic picture post-Sapphire 2025 is uncertain: rebranding, executive churn, and a Databricks partnership that is for now a connector and a demo rather than a native real-time lakehouse.
Learning 8 — The three-player framework: pre-AI incumbent, AI-native teenager, post-LLM disruptor
Source: Rory O’Driscoll, Scale Venture Partners (20VC, March 2026)
Every enterprise software category now has three players competing in parallel: the pre-AI incumbent (SAP, classical Oracle), the AI-native teenager (vendors that built AI in from 2018 onward), and the post-LLM disruptor (custom workflows built on top of foundation-model APIs). A nuance from operator experience: competitive surveillance via APIs existed in the earlier era too. Expedia systematically scanned Hotelbeds' pricing through the API (detectable via a million-to-one look-to-book ratio); today Webbeds does precisely the same to Hotelbeds, tracking prices one-to-one and undercutting by one euro. The surveillance framework did not break between eras; what collapsed is the barrier to building a competing platform. For finance functions, the practical question this raises: which parts of the stack are systems of record with defensible data moats, and which are workflow tools that a well-prompted agent could replace?
Learning 9 — Systems of record survive; point solutions face replacement by custom apps on APIs
Source: Amjad Masad, Replit CEO (20VC, April 2026)
Systems of record like ERP will survive. Point-solution and vertical SaaS tools face replacement by custom apps built atop foundation-model APIs. The asymmetry between systems of record and workflow tools is going to determine which line items survive the next three CFO budget cycles.
Implication: Niche planning apps, expense workflows, AP automation point solutions, and some treasury workflow tools are not systems of record. They sit in the kill zone. ERPs, as systems of record, are structurally safer—but their surrounding ecosystem of point solutions is not.
Synthesis for Discussion with Will
Three threads connect these nine learnings and are worth exploring in the academic context:
APIs as the architectural resolution of the standardisation–differentiation tension. Cloud ERP forces a binary: accept standard process or customise. Microservices and APIs provide the third option—standard core with differentiated extensions—but the vendor commercial model (RISE clean core, BTP extension tax) actively works against this option.
Cross-platform APIs as the defence against cognitive lock-in. The four-generations lock-in framework (technical → contractual → workflow → cognitive) reaches its sharpest form in the API layer. When vendor-embedded AI agents accumulate context inside a proprietary stack, the only escape route is a cross-platform integration layer that the enterprise owns and controls.
Foundation-model APIs as the structural threat to the ERP ecosystem. The O’Driscoll three-player framework and the Masad system-of-record thesis converge on the same prediction: ERPs survive as data repositories, but the workflow and intelligence layers above them are contestable by post-LLM entrants building on foundation-model APIs. The question for research is whether this makes ERP vendors more or less powerful—owners of an indispensable data moat, or commoditised infrastructure underneath someone else’s agent layer.