Architecture & System DesignDOC-ARCHITECTURE-MULTI-CL

Multi-Cloud Strategy for ERP

Understanding when multi-cloud makes sense for ERP deployments, the architectural patterns that enable portability, and the operational complexity that multi-cloud introduces.

11 min read
2,400 words
Updated 2026-02-25

Multi-Cloud: Strategy or Complexity?#

Multi-cloud—using multiple cloud providers—has become a popular strategy. Vendors promote benefits like avoiding vendor lock-in, leveraging best-of-breed services, and negotiating leverage. But multi-cloud also introduces significant complexity.

The honest assessment: Multi-cloud makes sense for some ERP deployments but adds unnecessary complexity for many others. The decision should be strategic, not tactical.

---

Multi-Cloud Motivations#

Avoiding Vendor Lock-In#

The concern: Dependency on a single vendor creates risk.

The reality: Most ERP systems are already highly vendor-dependent through proprietary functionality. Multi-cloud infrastructure doesn't solve application lock-in.

Best-of-Breed Services#

The opportunity: Use the best services from each provider.

Examples: - AWS for compute - Azure for Active Directory - GCP for analytics

Challenge: Integration complexity increases significantly.

Negotiating Leverage#

The strategy: Use multi-cloud as negotiating tool.

Reality: Vendors know multi-cloud is difficult. Leverage is limited unless you genuinely can move workloads.

Regulatory Requirements#

Some regulations require: - Data redundancy across providers - Geographic distribution - Sovereignty compliance

---

Multi-Cloud Architecture Patterns#

Primary-Secondary#

One primary cloud with secondary for specific workloads.

Example: - Primary: Azure (for Microsoft ecosystem) - Secondary: AWS (for specific services)

Distributed#

Workloads distributed across providers based on requirements.

Example: - ERP on Azure - Analytics on GCP - DR on AWS

Portable#

Architecture designed for portability between providers.

Requires: - Containerisation - Cloud-agnostic services - Abstraction layers

---

The Complexity Tax#

Operational Complexity#

Multiple skill sets required: - AWS expertise - Azure expertise - GCP expertise - Multi-cloud management

Increased operational burden: - Multiple monitoring systems - Multiple security models - Multiple support relationships

Integration Complexity#

Cross-cloud connectivity: - Network connectivity - Data transfer costs - Latency implications

Service integration: - Identity management - Data synchronisation - API compatibility

Cost Complexity#

Multiple billing models: - Different pricing structures - Complex cost allocation - Difficulty comparing total costs

---

When Multi-Cloud Makes Sense#

Genuine Regulatory Requirements#

If regulations require multi-provider redundancy or geographic distribution.

Existing Multi-Cloud Estate#

If your organisation already has significant multi-cloud investment.

Best-of-Breed Requirements#

If specific cloud services are genuinely superior for critical workloads.

Negotiating Leverage#

For large organisations where multi-cloud creates genuine negotiating leverage.

---

When to Avoid Multi-Cloud#

Single ERP Application#

Most ERP systems are designed for single-cloud deployment. Multi-cloud adds complexity without benefit.

Limited Cloud Expertise#

Multi-cloud multiplies skill requirements. Without strong cloud expertise, single-cloud is safer.

Cost Sensitivity#

Multi-cloud typically increases costs through complexity and reduced volume discounts.

Small Scale#

For smaller deployments, multi-cloud overhead isn't justified.

---

ANZ Multi-Cloud Considerations#

Data Residency#

Multi-cloud doesn't solve data residency: - Each provider must have ANZ regions - Verify compliance for each provider - Consider data transfer costs

Support Coverage#

Multiple support relationships: - Each provider requires separate support - Coordination for cross-provider issues - ANZ coverage for each provider

Partner Ecosystem#

Partner expertise is typically single-cloud: - Find partners with multi-cloud experience - Or use multiple specialist partners

---

Monday Morning Action Plan#

  1. Assess Your Motivation: Why are you considering multi-cloud? Is it genuine requirement or vendor marketing?
  1. Evaluate Application Fit: Does your ERP support multi-cloud deployment?
  1. Calculate Complexity Cost: Multi-cloud adds operational overhead. Is the benefit worth the cost?
  1. Consider ANZ Implications: Data residency and support coverage in ANZ for each provider.
  1. Start with Strategy: Multi-cloud should be strategic, not accidental.

---

Conclusion: Multi-Cloud Is a Choice, Not a Default#

Multi-cloud is a legitimate strategy for some organisations, but it's not a default best practice. For most ERP deployments, single-cloud provides better outcomes with less complexity. Choose multi-cloud deliberately, not by accident.