Your IT team manages SAP on Azure, Oracle Fusion on OCI, Salesforce hosted on AWS, and Workday running somewhere nobody quite knows. Not because you designed it that way — it happened gradually, one acquisition at a time, one SaaS decision at a time, driven by different business units. For most mid-market organizations, multi-cloud ERP isn’t a strategy. It’s the accumulated result of ten years of incremental decisions.
According to the Flexera State of the Cloud Report 2026, 89% of organizations now use multiple cloud providers simultaneously, with 73% operating in hybrid mode. Cloud waste reached 29% in 2026 — the first increase in five years. Without formal governance, multi-cloud environments cost more and deliver less clarity over time.
This article offers a practical framework: the 4 possible multi-cloud ERP architectures, a hyperscaler comparison, and the governance pillars that prevent your cloud estate from becoming unmanageable.
Multi-Cloud ERP: A Reality Inherited, Not Designed
How mid-market organizations ended up multi-cloud without planning it
Three mechanisms explain nearly all unplanned multi-cloud situations in mid-market organizations.
Acquisitions are the first driver. Each acquired subsidiary arrives with its own ERP, its own cloud, its own contracts. Application integration takes years; in the meantime, both environments coexist. After two or three acquisitions, the CIO is managing three ERPs across two or three different clouds.
Cloud creep is the second driver. A finance department adopts NetSuite because they couldn’t wait for the next update cycle of the central ERP. Marketing deploys HubSpot autonomously. Supply chain picks a SaaS WMS running on AWS. Each decision is rational in isolation — collectively, they produce fragmentation that nobody owns.
Business units that purchase SaaS tools without consulting IT are the third driver. SaaS procurement outside of IT governance processes exploded after 2020. Each “best-of-breed” tool installs on whichever cloud its vendor prefers.
The combination of these three mechanisms explains why, according to Flexera, multi-cloud adoption often progresses unintentionally — through mergers, siloed application teams, or inherited architectures rather than deliberate strategy.
The ERP-to-hyperscaler certification map in 2026
Each hyperscaler has built preferred partnerships with certain ERP vendors. These partnerships are not neutral: they influence available SLAs, native integrations, and potential cost savings.
AWS is the historic host for SAP (partnership since 2011), Oracle (E-Business Suite, JDE), Infor, and Sage X3. Its systems integrator ecosystem is the densest.
Azure has become SAP’s preferred cloud since the deepened partnership in 2019, confirmed and expanded at SAP Sapphire 2026 with the SAP Joule + Microsoft Copilot integration and expanded SAP Datasphere capabilities on Microsoft Fabric (source: Microsoft TechCommunity). Microsoft Dynamics 365 runs natively on Azure. Workday is certified on both Azure and AWS.
GCP is the preferred option for Oracle analytical workloads, SAP BW/4HANA, and IFS. Its strength lies in BigQuery and Vertex AI for analytics use cases built around ERP data.
OCI (Oracle Cloud Infrastructure) is the exclusive platform for Oracle Fusion Cloud ERP. All Fusion customers share the same codebase hosted on OCI, now available across 40+ global regions. OCI offers certified direct interconnects with Azure, AWS, and GCP for hybrid architectures (source: Oracle).
Sovereign clouds form a fifth category worth monitoring in 2026. Organizations subject to data residency requirements — whether due to GDPR, sector-specific regulation, or concerns about US jurisdiction under the Cloud Act — are evaluating sovereign hosting options alongside hyperscalers. For European CIOs navigating this landscape, our article on trusted cloud and SecNumCloud for ERP covers the regulatory context and practical trade-offs in detail.
The 4 Multi-Cloud ERP Architectures
Architecture 1 — Hub-and-spoke (one primary cloud, others at the edge)
The hub-and-spoke model designates a primary cloud that hosts the core transactional ERP, with peripheral modules on other clouds connected via dedicated links (VPN, ExpressRoute, or Direct Connect depending on the hyperscaler).
Typical example: SAP S/4HANA on Azure as the hub, Workday HR also on Azure to keep HR data within the same cloud perimeter, Salesforce on AWS at the edge with an SAP Integration Suite connector.
Advantages: centralized governance on a primary provider, simplified contracts, availability SLA defined on a single perimeter, egress costs limited to hub-to-periphery flows.
Disadvantages: strong dependency on the primary cloud — if Azure or AWS experiences an outage in your region, the entire ERP landscape is affected. Potential latency if peripheral modules are geographically distant.
Best fit: mid-market organizations with one dominant ERP (SAP or Oracle) and a handful of complementary modules. This is the recommended architecture for organizations starting fresh or looking to rationalize a fragmented estate.
Architecture 2 — Distributed best-of-breed (each function on its optimal cloud)
Each functional domain uses the solution and cloud that best serves it: Oracle Fusion Finance on OCI, Workday HR on Azure, Salesforce CRM on AWS, Infor CloudSuite WMS on GCP. No central cloud — each system is optimal within its perimeter.
Advantages: each module can be replaced independently without a global migration. Improved resilience if availability SLAs are contractually distinct across providers.
Disadvantages: integration costs explode (an iPaaS platform must orchestrate N clouds), egress charges apply on all cross-cloud flows, and monitoring complexity increases — an incident touching two clouds simultaneously is extremely difficult to diagnose. Integration budgets regularly exceed initial estimates in this model, as detailed in our analysis of ERP-SaaS integration hidden costs.
Best fit: tech scale-ups with mature IT teams, or large enterprises where each business unit has an independent IT budget. Not recommended below 500 employees: governance costs are disproportionate to scale.
Architecture 3 — Coordinated hybrid (on-premise core + cloud periphery)
The ERP core stays on-premise (often SAP ECC or Oracle E-Business Suite still under contract) while new capabilities — BI, analytics, HR, CRM — are deployed in the cloud.
Advantages: the most sensitive data (financial, payroll) never leaves controlled infrastructure. Existing on-premise investments continue to amortize. Cloud costs are limited to newly opened application perimeters.
Disadvantages: dual maintenance (on-premise infrastructure + cloud), latency between the core and cloud modules, and a modernization path that grows more complex over time. On-premise ERP updates run on a different cycle from cloud, progressively widening a functional gap.
Best fit: regulated sectors (banking, defense, healthcare) with data localization constraints, or organizations in transition whose on-premise ERP contract still runs 3 to 5 years.
Architecture 4 — Sovereign cloud + hyperscaler (compliance + performance)
This architecture combines sovereign hosting for sensitive data (Cloud Act compliance, GDPR, sector-specific obligations) with a hyperscaler for performance or AI workloads.
Context: the US Cloud Act (2018) grants US authorities access to data held by any US-based company, regardless of where servers are physically located. AWS, Azure, GCP, and OCI are US entities — their European datacenters are not exempt from this jurisdiction. For organizations subject to strict data sovereignty requirements, hosting the most sensitive ERP data on a certified sovereign cloud is becoming a compliance requirement rather than an option.
Example split: financial and payroll data on a sovereign-certified cloud, anonymized analytics module on Azure or GCP to leverage Vertex AI or Azure OpenAI.
Cost: the sovereign premium is real — CIO-reported figures typically range between 15 and 30% above pure hyperscaler pricing, due to certification costs and a more limited managed services ecosystem.
Best fit: critical infrastructure operators, healthcare systems, public sector, or industrial organizations operating in regulated supply chains (defense, aerospace).
Hyperscaler Comparison for ERP
| Hyperscaler | Preferred ERPs | ERP Strengths | Watch Points |
|---|---|---|---|
| AWS | SAP, Oracle EBS/JDE, Infor, Sage X3 | Densest SI ecosystem, HANA maturity, global footprint | Fewer native synergies if stack is Microsoft/SAP; separate IAM to federate |
| Azure | SAP S/4HANA, Dynamics 365, Workday | Deepened SAP partnership in 2026, Copilot/Joule GA, SAP Datasphere on Fabric | Licensing cost can escalate if org is not in Microsoft ecosystem |
| GCP | Oracle, SAP BW, IFS | Analytics (BigQuery, Vertex AI), Workspace integration | Fewer ERP partners than AWS/Azure; less mature for pure transactional workloads |
| OCI | Oracle Fusion Cloud (native, exclusive), SAP | Reduced latency for Oracle Fusion, certified interconnects to Azure/AWS/GCP | Smaller partner footprint; less suited if primary ERP is not Oracle |
Oracle Fusion customers benefit from reduced latency by staying on OCI — Oracle has optimized Fusion’s performance on its own infrastructure. SAP customers will find the deepest partnership on Azure in 2026, with documented customer cases including Maersk (500 SAP servers and 1 petabyte of data migrated to Azure in six months with near-continuous availability) and KONE (54,000 contracts processed with a 33% reduction in processing time via SAP + Azure AI, per Microsoft TechCommunity).
Multi-Cloud ERP Governance: The 4 Pillars
Pillar 1 — iPaaS as the integration backbone
A multi-cloud landscape without a centralized integration platform inevitably produces point-to-point flows: 10 systems generate potentially 45 bilateral connections. Each new SaaS adds N more.
The main options in 2026 are MuleSoft (acquired by Salesforce, dominant in enterprise), Dell Boomi (acquired by Francisco Partners, strong in mid-market), Azure Integration Services (native to Azure, recommended when Azure is the hub), and SAP Integration Suite (recommended when SAP is the core, with pre-built adapters for 400+ systems).
Practical rule: standardize on a single iPaaS before reaching your fifth integration. After that threshold, integration debt makes platform changes costly. Our article on ERP-SaaS integration hidden costs covers the full cost breakdown in detail.
Pillar 2 — Federated IAM across clouds
Each hyperscaler has its own identity and access management system: AWS IAM, Azure Entra ID, OCI IAM, GCP Identity. Without federation, IT teams manage as many administration consoles and user directories as they have clouds.
The solution is identity federation via SAML 2.0 or OIDC, with a central identity provider (IdP): Okta, Microsoft Entra ID (if Azure is the hub), or Ping Identity. All clouds connect to this single IdP. Each user has one identity, one deprovisioning procedure when they leave.
Without federated IAM, users accumulate multiple identities, ghost accounts build up after departures, and compliance audits become high-risk manual exercises.
Pillar 3 — ERP cloud FinOps
According to Flexera, 29% of cloud spend is wasted in 2026 — rising for the first time in five years. Organizations managing multiple clouds without formal FinOps governance see bills increasing without proportional business value gains. The 63% of organizations with dedicated FinOps teams (Flexera 2026) control this dynamic more effectively.
In a multi-cloud context, FinOps is more complex than in a single-cloud setup: each hyperscaler has its own pricing model, its own reservation mechanisms (AWS Reserved Instances, Azure Reservations, OCI Universal Credits), and its own cost visibility tools.
Essential practices: systematic tagging from the first deployment (ERP module, entity, environment), cost allocation by business unit, overage alerts by cloud and by project. Our article on ERP FinOps covers optimization levers applicable to SAP, Oracle, and Dynamics stacks in detail.
Pillar 4 — Multi-cloud data governance
The underestimated risk of multi-cloud ERP is losing control of where data actually lives. When financial data flows from an SAP ERP on Azure to an analytics module on GCP to feed a Tableau dashboard on AWS, how many national borders has it crossed? Under which jurisdiction does it sit in transit?
Multi-cloud data governance rests on three concrete actions: data classification (sensitive, internal, public) with associated location policies; inter-cloud flow control via the iPaaS platform (each flow documented, encrypted, and auditable); and periodic review of data residency policies against regulatory developments (GDPR, NIS 2, DORA for financial services, and sector-specific requirements).
Recommendations by Organization Profile
Profile 1: Industrial mid-market under SAP (500–3,000 employees)
Choose Azure as your primary hub. The SAP-Microsoft partnership in 2026 offers the best level of native integration: SAP Joule and Microsoft Copilot are in general availability since late 2025, and SAP Datasphere integrates directly into Microsoft Fabric for advanced analytics. Keep Workday or SuccessFactors on Azure to limit egress costs. Use SAP Integration Suite for internal ERP flows and Azure Integration Services for external partner flows. Target architecture: hub-and-spoke with Azure as hub.
Profile 2: Services organization on Oracle Fusion Cloud and Salesforce
Oracle Fusion runs on OCI — you don’t choose the cloud for your financial core. Salesforce hosts its main services primarily on AWS and GCP. The connection between the two runs through MuleSoft (which you likely already have in your Salesforce license) or Oracle Integration Cloud. Monitor egress costs between OCI and AWS/GCP closely for real-time data synchronizations — they can represent a significant share of your inter-cloud bill. Target architecture: best-of-breed with Oracle Integration Cloud as the central bridge.
Profile 3: Multi-country organization in rapid growth
The primary risk in this profile is the absence of architectural standards from the earliest acquisitions. Each new entity brings its own local ERP and preferred cloud. Decentralized governance costs exponentially more as the group scales.
The recommendation is to define a standard “blueprint” before acquiring the fifth entity: an approved primary cloud, a mandatory group iPaaS for all inter-system flows, and a common FinOps tagging policy. Imposing these standards on each new entity during integration is more cost-effective than harmonizing after the fact. Target architecture: hub-and-spoke mandated from the start, even if the initial hub is modest.
Three articles to go deeper on related topics: our analysis of ERP-SaaS integration hidden costs and iPaaS, our guide on trusted cloud and data sovereignty for ERP, and our analysis of ERP microservices, monolith, or composable architecture for application architecture decisions beyond cloud hosting alone.
