Cloud Strategy and Platform Selection

Cloud strategy defines how an organisation consumes computing resources from external providers rather than owning and operating physical infrastructure. For mission-driven organisations operating across multiple countries with staff in headquarters, regional hubs, and field offices, cloud services provide geographic reach, elastic capacity during emergencies, and reduced dependency on local infrastructure that proves difficult to maintain in resource-constrained contexts. The strategic decisions made at this level constrain every subsequent technical choice, from network architecture to application deployment patterns.

Cloud computing: On-demand delivery of computing resources over networks, with usage-based pricing and provider-managed infrastructure. The defining characteristics are self-service provisioning, broad network access, resource pooling, rapid elasticity, and measured service.
Deployment model: The ownership and access pattern for cloud infrastructure: public (shared, provider-owned), private (dedicated, organisation-controlled), hybrid (combination), or community (shared among organisations with common requirements).
Multi-cloud: Deliberate use of multiple cloud providers for different workloads, distinct from hybrid cloud which combines cloud with on-premises infrastructure.
Data sovereignty: Legal and regulatory requirements governing where data resides and which jurisdictions have authority over it. Distinct from data residency (physical location) and data localisation (legal requirements to store data within specific borders).
Landing zone: Pre-configured cloud environment with identity, networking, security, and governance foundations established before workloads deploy.

Deployment Models

Cloud deployment models represent distinct approaches to infrastructure ownership, access control, and operational responsibility. The choice of model affects cost structure, security posture, compliance capability, and operational complexity. Each model suits different workload characteristics and organisational constraints.

Public Cloud

Public cloud infrastructure is owned and operated by third-party providers who sell capacity to multiple customers from shared resource pools. Customers access standardised services through self-service portals and APIs, paying based on consumption. The provider handles all physical infrastructure, including data centres, power, cooling, and hardware lifecycle management.

The economic model relies on statistical multiplexing: providers provision capacity based on aggregate demand patterns rather than peak individual demand. This enables pricing below the true cost of equivalent dedicated infrastructure, provided the customer accepts standardised service offerings and shared tenancy. For a humanitarian organisation running office productivity workloads, the per-user cost through a public cloud provider falls between 40% and 60% of equivalent on-premises infrastructure when accounting for staff time, facilities, power, and hardware refresh cycles.

Public cloud concentrates technical expertise at the provider, eliminating the need for organisations to maintain deep infrastructure skills. A three-person IT team supporting 200 staff cannot maintain the security monitoring, patching cadence, and availability engineering that major cloud providers deliver as baseline capabilities. The tradeoff is reduced control: the organisation depends on provider decisions about service features, pricing changes, and geographic availability.

+----------------------------------------------------------------------+
|                            PUBLIC CLOUD MODEL                        |
+----------------------------------------------------------------------+
|                                                                      |
|  +--------------------+  +--------------------+  +-----------------+ |
|  |  Organisation A    |  |  Organisation B    |  | Organisation C  | |
|  |  (Your workloads)  |  |  (Other customer)  |  | (Other customer)| |
|  +--------------------+  +--------------------+  +-----------------+ |
|           |                       |                     |            |
|           +-----------------------+---------------------+            |
|                                   |                                  |
|                                   v                                  |
|    +-----------------------------------------------------------+     |
|    |              SHARED INFRASTRUCTURE POOL                   |     |
|    |  +--------+  +--------+  +--------+  +--------+           |     |
|    |  |Compute |  |Storage |  |Network |  |  Data  |           |     |
|    |  | Pool   |  | Pool   |  | Pool   |  | Centres|           |     |
|    |  +--------+  +--------+  +--------+  +--------+           |     |
|    |                                                           |     |
|    |  Provider manages: hardware, facilities, security,        |     |
|    |  patching, availability, capacity planning                |     |
|    +-----------------------------------------------------------+     |
|                                                                      |
+----------------------------------------------------------------------+
|  Customer responsibility: applications, data, access control,        |
|  configuration, compliance                                           |
+----------------------------------------------------------------------+

Figure 1: Public cloud shared infrastructure model

Private Cloud

Private cloud dedicates infrastructure to a single organisation, whether located on-premises or hosted by a third party. The organisation gains exclusive access to compute, storage, and network resources without sharing capacity with other customers. This isolation provides greater control over security configuration, network architecture, and data handling practices.

The cost structure differs fundamentally from public cloud. Private cloud requires capital investment in infrastructure and ongoing operational expenditure regardless of utilisation. An organisation paying for 100 virtual machine capacity pays the same whether running 10 or 90 workloads. This model suits organisations with predictable, sustained workloads that would generate high public cloud costs, or those facing regulatory requirements that prohibit shared tenancy.

Private cloud demands substantial technical capability. The organisation assumes responsibility for hardware procurement, data centre facilities (or colocation contracts), hypervisor management, security patching, capacity planning, and availability engineering. For organisations with fewer than 500 staff, the operational overhead of private cloud infrastructure exceeds the benefits in most scenarios. The exceptions involve specific regulatory requirements, data sensitivity classifications that preclude shared tenancy, or existing infrastructure investments with remaining useful life.

Hosted private cloud services from providers offer a middle path: dedicated infrastructure operated by the provider. This reduces operational burden while maintaining isolation. Costs exceed public cloud by 30% to 50% for equivalent capacity, reflecting the loss of statistical multiplexing benefits.

Hybrid Cloud

Hybrid cloud combines public cloud services with on-premises or private cloud infrastructure, treating them as a unified environment. Workloads distribute across environments based on technical requirements, cost characteristics, regulatory constraints, or data sensitivity. The hybrid model enables organisations to maintain existing infrastructure investments while gaining public cloud capabilities for appropriate workloads.

The technical implementation requires network connectivity between environments, identity federation so users authenticate once and access resources in both locations, and management tools that operate across boundaries. Complexity increases substantially compared to single-environment deployments. Data synchronisation, latency between environments, and inconsistent security models across platforms create operational challenges that demand mature IT capabilities.

Hybrid cloud suits organisations in transition from on-premises to public cloud, those with specific workloads that cannot migrate due to regulatory or technical constraints, or those requiring data processing at field locations with intermittent connectivity. A humanitarian organisation maintaining case management systems with protection data might run the application in public cloud while keeping the database in a controlled private environment to satisfy data protection requirements. This configuration requires careful architecture to avoid creating dependencies that undermine the benefits of either environment.

+-------------------------------------------------------------------+
|                       HYBRID CLOUD MODEL                          |
+-------------------------------------------------------------------+
|                                                                   |
|  +---------------------------+    +---------------------------+   |
|  |      PUBLIC CLOUD         |    |    PRIVATE/ON-PREMISES    |   |
|  |                           |    |                           |   |
|  |  +------+  +------+       |    |  +------+  +------+       |   |
|  |  | Web  |  | API  |       |    |  | Data |  |Legacy|       |   |
|  |  | App  |  | Svcs |       |    |  | Base |  | Apps |       |   |
|  |  +------+  +------+       |    |  +------+  +------+       |   |
|  |                           |    |                           |   |
|  |  Burst capacity           |    |  Sensitive data           |   |
|  |  Global distribution      |    |  Regulatory compliance    |   |
|  |  Modern workloads         |    |  Legacy integration       |   |
|  +-------------+-------------+    +-------------+-------------+   |
|                |                                |                 |
|                +----------------+---------------+                 |
|                                 |                                 |
|                    +------------v-----------+                     |
|                    |                        |                     |
|                    |  HYBRID CONNECTIVITY   |                     |
|                    |  - VPN / ExpressRoute  |                     |
|                    |  - Identity federation |                     |
|                    |  - Unified management  |                     |
|                    |                        |                     |
|                    +------------------------+                     |
|                                                                   |
+-------------------------------------------------------------------+

Figure 2: Hybrid cloud architecture connecting public and private environments

Community Cloud

Community cloud provides shared infrastructure for organisations with common requirements, governance models, or compliance obligations. Unlike public cloud where any customer can purchase capacity, community clouds restrict access to member organisations. The shared costs distribute among fewer participants than public cloud but more than private cloud, creating intermediate economics.

The humanitarian and development sector has explored community cloud models through initiatives that would provide shared infrastructure meeting sector-specific requirements for data protection, geographic distribution, and cost structure. These initiatives face challenges in achieving the scale necessary for economic viability and in coordinating governance across independent organisations. Existing community cloud examples include government clouds restricted to public sector entities and research clouds serving academic institutions.

Community cloud becomes viable when a defined group of organisations shares requirements that public cloud providers do not address and when the group possesses sufficient aggregate demand to operate dedicated infrastructure economically. For most mission-driven organisations, public cloud services with appropriate configuration satisfy requirements more cost-effectively than purpose-built community alternatives.

Single-Cloud and Multi-Cloud Strategy

The decision between concentrating workloads with a single provider or distributing across multiple providers affects every aspect of cloud operations. This choice involves tradeoffs between operational simplicity, cost optimisation, risk management, and capability access. Neither approach dominates in all scenarios; the appropriate strategy depends on organisational scale, technical capability, and specific requirements.

Single-Cloud Concentration

Operating all cloud workloads with a single provider simplifies operations substantially. Staff develop deep expertise in one platform rather than shallow knowledge across several. Integration between services works without cross-cloud complexity. Billing consolidates into unified reporting. Support relationships concentrate with one provider, enabling better engagement through higher aggregate spend.

Single-cloud concentration creates dependency on provider decisions. Service deprecation, pricing changes, or regional availability gaps affect the entire environment. The 2019 outage of a major cloud provider’s primary authentication service disrupted organisations worldwide for several hours. Organisations concentrated on that provider had no fallback; those with multi-cloud architectures maintained partial operations.

For organisations with limited IT capacity, single-cloud deployment reduces cognitive load and enables deeper platform knowledge. A four-person IT team cannot maintain expertise across multiple cloud platforms while also supporting users, managing security, and running projects. Concentration enables competence. The risk of provider-specific outages or business changes must be weighed against the operational overhead of multi-cloud complexity.

Multi-Cloud Distribution

Multi-cloud strategy deliberately uses multiple providers for different purposes. This differs from accidental multi-cloud, where shadow IT or departmental decisions create uncoordinated provider sprawl. Deliberate multi-cloud assigns workloads to providers based on capability requirements, geographic needs, cost characteristics, or risk distribution.

The primary drivers for multi-cloud include avoiding concentration risk, accessing provider-specific capabilities unavailable elsewhere, meeting data sovereignty requirements across jurisdictions, and optimising costs by placing workloads with the most economical provider. A development organisation operating programmes in 30 countries might use one provider for European operations (satisfying GDPR requirements with EU-based data centres) while using a different provider for operations in regions where the first provider lacks presence.

Multi-cloud increases operational complexity. Identity must federate across providers. Network connectivity requires multiple configurations. Security policies need translation between provider-specific implementations. Staff require training on multiple platforms. Management tooling must abstract provider differences or operate independently for each environment. These costs reduce and sometimes eliminate the theoretical benefits of multi-cloud for organisations without substantial IT capacity.

The economic case for multi-cloud cost optimisation weakens under scrutiny for most organisation sizes. The overhead of managing multiple providers, training staff, and maintaining parallel capabilities exceeds savings from workload-specific provider selection below approximately 500,000 USD annual cloud spend. Above this threshold, dedicated cloud engineering staff can extract savings that justify complexity.

+------------------------------------------------------------------+
|                    CLOUD STRATEGY SELECTION                      |
+------------------------------------------------------------------+
|                                                                  |
|                     +---------------------+                      |
|                     |  Annual cloud spend |                      |
|                     |  projection?        |                      |
|                     +----------+----------+                      |
|                                |                                 |
|              +-----------------+-----------------+               |
|              |                                   |               |
|              v                                   v               |
|    +---------+----------+             +----------+---------+     |
|    | Under 500K USD     |             | Over 500K USD      |     |
|    +--------------------+             +--------------------+     |
|              |                                   |               |
|              v                                   v               |
|    +---------+----------+             +----------+---------+     |
|    | Data sovereignty   |             | Dedicated cloud    |     |
|    | requirements?      |             | engineering staff? |     |
|    +--------------------+             +--------------------+     |
|         |         |                        |          |          |
|         v         v                        v          v          |
|       +---+     +---+                   +----+     +----+        |
|       |Yes|     |No |                   |Yes |     | No |        |
|       +---+     +---+                   +----+     +----+        |
|         |         |                        |          |          |
|         v         v                        v          v          |
|  +------+---+ +---+------+          +------+---+ +----+-----+    |
|  | Targeted | | Single   |          | Consider | | Single   |    |
|  | multi-   | | cloud    |          | multi-   | | cloud    |    |
|  | cloud    | | strategy |          | cloud    | | strategy |    |
|  +----------+ +----------+          +----------+ +----------+    |
|                                                                  |
+------------------------------------------------------------------+

Figure 3: Decision framework for single versus multi-cloud strategy

Practical Multi-Cloud Patterns

Organisations adopting multi-cloud follow several patterns that balance capability access against complexity. The most common pattern uses one provider as the primary platform for most workloads while maintaining secondary provider relationships for specific purposes.

The sovereignty pattern places workloads in regional providers to satisfy data localisation requirements. An organisation operating in the European Union, Sub-Saharan Africa, and Southeast Asia might use a European provider for EU data, a regional provider or local data centres for specific African country requirements, and a global provider with Singapore presence for Asian operations. This pattern distributes data geographically while maintaining consistent application architectures where possible.

The capability pattern selects providers based on specific service strengths. Machine learning workloads might run on one provider with superior AI services while general computing runs elsewhere. This pattern suits organisations with specialised technical requirements but demands expertise in multiple platforms.

The risk mitigation pattern maintains parallel capability in a secondary provider sufficient to restore critical operations if the primary provider fails. This requires ongoing investment in secondary platform competence and periodic testing. The cost of maintaining genuine failover capability across providers exceeds the single-cloud approach by 40% to 60% for most workloads. Few organisations outside regulated industries justify this investment.

Platform Evaluation Framework

Selecting a cloud provider requires systematic evaluation against organisational requirements rather than comparison of technical feature lists. Providers differ in geographic presence, pricing structure, nonprofit programme availability, service breadth, and jurisdictional implications. The evaluation framework translates organisational strategy into weighted criteria for provider comparison.

Requirements Definition

Effective evaluation begins with requirements that reflect actual organisational needs rather than theoretical capabilities. The requirement categories that matter for mission-driven organisations include geographic presence where staff and programmes operate, data sovereignty obligations from regulators or donors, cost structure alignment with funding models, service availability for planned workloads, and administrative burden for the IT team.

Geographic presence requirements derive from where the organisation operates. Field offices in East Africa need connectivity to cloud services with acceptable latency. If the nearest data centre is 6,000 kilometres away, application performance degrades noticeably. Providers with regional presence reduce latency and sometimes satisfy data residency requirements. A provider with data centres in Nairobi, Johannesburg, and Cape Town serves Sub-Saharan Africa operations differently than one with nearest presence in Frankfurt.

Data sovereignty requirements emerge from donor conditions, host country regulations, and organisational policy. USAID-funded programmes may restrict data to specified countries. European operations processing personal data must satisfy GDPR requirements including restrictions on transfers outside the EU without adequate safeguards. Some host countries require specific data types to remain within national borders. The evaluation must map these requirements to provider capabilities for data residency.

Evaluation Criteria

The criteria for evaluation weight according to organisational priorities. An organisation prioritising cost optimisation weights pricing structure heavily. An organisation operating in high-risk contexts weights security capabilities and jurisdictional considerations. The weighting should reflect actual decision factors rather than theoretical importance.

Geographic and sovereignty criteria examine where providers operate data centres, what mechanisms exist for restricting data to specific regions, and what jurisdictional exposure results from provider headquarters location. A provider headquartered in the United States exposes customer data to potential US government requests under the CLOUD Act regardless of where data physically resides. Providers headquartered in Europe face different legal exposure. This consideration matters most for organisations handling sensitive data in contexts where government access creates risk.

Economic criteria examine base pricing, volume discounts, committed use discounts, nonprofit programme eligibility, and total cost of operations including staff training and management tooling. Nonprofit programmes from major providers offer between 20% and 90% discount on list prices depending on organisation type, geography, and service category. Eligibility requirements vary; some programmes require 501(c)(3) status or equivalent, while others accept a broader range of mission-driven organisations.

Technical criteria examine service breadth for planned workloads, API consistency for automation, availability track record, and integration capabilities. Organisations planning specific workloads evaluate provider capabilities in those areas. General-purpose computing, storage, and database services exist across providers; specialised services for machine learning, IoT, or serverless computing vary substantially.

Operational criteria examine support model availability in operating time zones, documentation quality, training resources, and community ecosystem. A provider with extensive training programmes and active community forums reduces the learning curve for IT staff. Support availability during the organisation’s operating hours matters for incident response.

Due Diligence Process

Platform selection involves provider engagement, reference gathering, and proof-of-concept validation. The process scales to organisational size and commitment level. An organisation planning to migrate 50 users to cloud email requires less diligence than one rebuilding core programme systems on cloud infrastructure.

Provider engagement establishes pricing eligibility, clarifies geographic capabilities, and surfaces constraints not apparent from public documentation. Direct conversation with provider representatives reveals nonprofit programme terms, identifies potential blockers, and establishes relationships that assist during implementation. The engagement also tests provider responsiveness, indicating likely support quality.

Reference conversations with peer organisations using the provider reveal operational reality versus marketing claims. Organisations similar in size, sector, and geographic distribution provide the most relevant references. Questions should focus on actual experience: implementation challenges encountered, ongoing operational issues, support quality during incidents, and cost trajectory over time.

Proof-of-concept deployments validate technical assumptions before commitment. A limited deployment of planned workloads reveals integration challenges, performance characteristics, and operational workflow. The proof of concept should exercise the critical path for planned usage, not merely demonstrate that services function. For organisations planning field deployment, proof-of-concept testing from actual field locations with representative connectivity validates assumptions about latency and bandwidth requirements.

Data Sovereignty and Jurisdictional Considerations

Cloud computing separates the physical location of data from the organisation’s operating location, creating jurisdictional complexity. Data stored in a provider’s data centre falls under the legal jurisdiction where that data centre operates, the jurisdiction where the provider is headquartered, and potentially the jurisdiction where the organisation is incorporated. Understanding these overlapping claims enables informed decisions about data placement.

Jurisdictional Exposure

Provider headquarters location determines which government can compel access to customer data through legal process. The United States CLOUD Act enables US government agencies to request data from US-headquartered companies regardless of where data physically resides. A US-headquartered provider storing data in a German data centre must comply with valid US legal process requesting that data, potentially without customer notification depending on the legal instrument used.

European providers face different legal frameworks. The General Data Protection Regulation restricts transfers of personal data outside the European Economic Area without adequate safeguards. European governments can compel access through their own legal processes, but the extraterritorial reach differs from US law.

For organisations handling sensitive data in contexts where government access creates risk, provider jurisdiction matters substantially. Protection data about survivors of violence, programme data about beneficiaries in politically sensitive contexts, or operational data that could endanger staff under hostile governments requires careful jurisdictional analysis. The evaluation should consider not only the organisation’s own government relationships but also the governments that might seek access through the provider.

Data Residency Implementation

Cloud providers offer mechanisms to restrict data to specific geographic regions. These controls vary in granularity and enforcement certainty. Some providers guarantee that data remains within specified boundaries; others provide configuration options that place data regionally but permit transfers for operational reasons like support access or disaster recovery.

Implementing data residency requires understanding what data flows to cloud services and configuring services to respect geographic constraints. Managed services that process data may transfer content to other regions for processing even when storage remains local. Backup and replication features may copy data to secondary regions unless explicitly restricted. Support interactions may provide provider staff in other regions with access to customer data unless restricted.

Verification of data residency controls should not rely solely on provider documentation. Technical validation through network monitoring, service configuration review, and provider attestation establishes actual data location. Ongoing monitoring detects configuration drift that might redirect data outside intended boundaries.

Donor and Regulatory Requirements

Funding sources impose requirements that constrain cloud selection. USAID cooperative agreements typically include provisions about data handling, including restrictions on data transfer outside the United States or specified countries. European Union funding may require GDPR compliance and restrict processing outside the EU. United Nations agency partnerships reference UN data protection principles and sometimes impose specific technical requirements.

These requirements must be mapped during cloud evaluation. The mapping identifies which workloads fall under which requirements and what provider capabilities satisfy those requirements. For organisations with multiple funding sources, the intersection of requirements may substantially constrain options. A programme funded jointly by USAID and EU sources faces requirements from both, potentially limiting cloud options to providers with US and EU presence and adequate controls for both frameworks.

Requirements change over time. Funding source policies evolve, new regulations emerge, and existing requirements receive new interpretation. Cloud architectures should accommodate some flexibility for requirement changes without requiring fundamental redesign. This argues for avoiding deep dependency on provider-specific services that would complicate migration if requirements change.

Nonprofit Programme Evaluation

Major cloud providers operate programmes offering discounted or donated services to eligible nonprofit organisations. These programmes substantially reduce cloud costs but impose constraints that affect platform selection. Evaluation of nonprofit programmes should consider eligibility criteria, discount depth, service coverage, renewal terms, and programme stability.

Programme Structures

Nonprofit programmes follow several models. Donation programmes provide free credits or services up to specified limits. Discount programmes reduce prices by fixed percentages. Hybrid programmes combine initial credits with ongoing discounts. The economic value depends on planned usage patterns and programme terms.

Credit-based programmes suit organisations with limited cloud usage or those beginning cloud adoption. An organisation receiving 2,000 USD monthly in credits with modest workloads may operate at zero cost. The same organisation scaling to significant cloud usage eventually exceeds credit allocations and pays list prices for overage. Credit programmes incentivise initial adoption but may not provide long-term cost advantage.

Discount programmes suit organisations with sustained cloud usage. A 50% discount on compute services provides ongoing savings that grow with usage. The effective value depends on which services receive discounts; programmes discounting only specific services provide less value than those covering broad service categories.

Eligibility and Renewal

Eligibility criteria vary across programmes and change over time. Some programmes accept any registered nonprofit organisation. Others restrict eligibility to organisations with specific charitable purposes, excluding educational institutions, healthcare organisations, or religious organisations. Geographic restrictions limit some programmes to specific countries. Verification processes range from self-attestation to detailed documentation review.

Renewal terms determine long-term viability. Programmes offering perpetual renewal provide predictable cost structures. Programmes with limited terms or discretionary renewal create uncertainty. An organisation building cloud dependency based on nonprofit programme pricing faces significant cost increases if programme eligibility lapses or terms worsen. This risk argues for avoiding programmes with uncertain renewal even if initial terms appear more generous.

Programme stability matters for long-term planning. Providers sometimes discontinue programmes, reduce benefits, or tighten eligibility. Established programmes from major providers have demonstrated multi-year stability, though terms adjust periodically. Newer programmes or those from smaller providers carry higher discontinuation risk.

Comparing Programme Value

Comparing programme value requires projecting actual usage rather than comparing headline benefits. A programme offering 3,500 USD in monthly credits provides more value than one offering 2,000 USD monthly credits for an organisation that would use 3,000 USD in services. For an organisation using 1,000 USD in services, both programmes provide equivalent value. The comparison must reflect expected usage.

The comparison should include services outside programme coverage. An organisation requiring database services not covered by the nonprofit programme pays list prices for those services. A different provider with less generous headline credits but broader service coverage may prove more economical overall.

Consider the following example: an organisation projects annual cloud usage of 60,000 USD across compute, storage, database, and machine learning services. Provider A offers nonprofit credits of 36,000 USD annually, covering compute and storage only. Provider B offers 25% discount across all services. Provider A’s effective cost is 60,000 USD minus 36,000 USD credits on eligible services (roughly 70% of usage) plus full price on remaining services, yielding approximately 36,000 USD annually. Provider B’s effective cost is 60,000 USD minus 25% discount, yielding 45,000 USD annually. Despite lower headline credits, Provider A proves more economical for this usage pattern.

Cloud Readiness Assessment

Cloud adoption succeeds when organisational capability matches cloud requirements. Readiness assessment identifies gaps between current capability and cloud operational requirements, enabling targeted preparation rather than discovering gaps during migration. The assessment examines technical infrastructure, operational processes, staff skills, and governance structures.

Technical Readiness

Technical readiness examines existing infrastructure and its cloud compatibility. Network connectivity between current locations and cloud providers determines what latency users will experience and what bandwidth supports data transfer. Organisations with field offices on satellite connectivity face different cloud experience than those with reliable broadband. Baseline network assessment should measure latency and bandwidth from each significant location to candidate provider regions.

Application inventory identifies workloads for cloud migration. Applications vary in cloud readiness based on architecture, licensing, and dependencies. Modern web applications with stateless architecture migrate readily. Legacy applications with dependencies on specific operating systems, hardware configurations, or local file system access require modification or alternative approaches. The inventory should classify applications by migration approach: rehost (move without change), replatform (modify for cloud services), refactor (redesign for cloud-native architecture), or retain (keep on-premises).

Identity infrastructure readiness affects cloud integration. Cloud services authenticate through identity providers; organisations lacking modern identity infrastructure face significant preparation work. Active Directory integration, federation capability, and multi-factor authentication readiness enable smooth cloud identity integration. Organisations without centralised identity management should address this foundation before cloud migration.

Operational Readiness

Operational processes require adaptation for cloud environments. Change management processes designed for on-premises infrastructure need modification for cloud’s faster change pace. Incident management processes need integration with cloud provider status and support channels. Backup and recovery processes shift from managing local infrastructure to configuring cloud-native services.

The operational assessment identifies process gaps and adaptation requirements. Organisations with mature ITSM processes adapt more readily than those with informal operations. The assessment should be honest about actual operational practice rather than documented policy. Cloud operations expose process gaps that on-premises operations might tolerate.

Monitoring and visibility capabilities need evaluation. Cloud operations require different monitoring approaches than on-premises infrastructure. The assessment should identify current monitoring tools, their cloud compatibility, and gaps that cloud-native monitoring services would address.

Skills and Governance

Staff skills assessment identifies training requirements. Cloud platforms require different skills than on-premises infrastructure. The learning curve varies by platform and by staff background. Staff with strong networking and virtualisation skills adapt more readily than those limited to specific on-premises products. The assessment should inventory current skills and map gaps to training programmes.

Governance readiness examines decision rights, policies, and oversight mechanisms. Cloud spending can grow rapidly without controls that constrain on-premises infrastructure through procurement processes. Organisations need governance mechanisms suited to cloud’s flexibility: tagging standards for cost allocation, budget alerts, and approval workflows for resource provisioning. Security policies require updates for cloud-specific risks and controls.

+------------------------------------------------------------------+
|                   CLOUD READINESS DIMENSIONS                     |
+------------------------------------------------------------------+
|                                                                  |
|  TECHNICAL                        OPERATIONAL                    |
|  +------------------------+       +------------------------+     |
|  | Network connectivity   |       | Change management      |     |
|  | - Latency to regions   |       | - Pace adaptation      |     |
|  | - Bandwidth capacity   |       | - Approval workflow    |     |
|  |                        |       |                        |     |
|  | Identity foundation    |       | Incident management    |     |
|  | - Centralised IdP      |       | - Cloud integration    |     |
|  | - Federation ready     |       | - Provider support     |     |
|  |                        |       |                        |     |
|  | Application portfolio  |       | Monitoring capability  |     |
|  | - Migration approach   |       | - Cloud-compatible     |     |
|  | - Dependencies mapped  |       | - Coverage gaps        |     |
|  +------------------------+       +------------------------+     |
|                                                                  |
|  SKILLS                           GOVERNANCE                     |
|  +------------------------+       +------------------------+     |
|  | Platform knowledge     |       | Decision rights        |     |
|  | - Training completed   |       | - Provisioning         |     |
|  | - Certification        |       | - Architecture         |     |
|  |                        |       |                        |     |
|  | Security skills        |       | Financial controls     |     |
|  | - Cloud security       |       | - Budget management    |     |
|  | - IAM configuration    |       | - Cost allocation      |     |
|  |                        |       |                        |     |
|  | Automation capability  |       | Policy alignment       |     |
|  | - Infrastructure code  |       | - Security policies    |     |
|  | - CI/CD familiarity    |       | - Data policies        |     |
|  +------------------------+       +------------------------+     |
|                                                                  |
+------------------------------------------------------------------+

Figure 4: Cloud readiness assessment dimensions

Implementation Considerations

Cloud strategy implementation varies by organisational context. Approaches that suit a 50-person organisation with a single IT staff member differ from those appropriate for a 500-person organisation with a dedicated IT team. Implementation guidance must acknowledge these differences rather than prescribing universal approaches.

For Organisations with Limited IT Capacity

Organisations with minimal IT staff or shared IT responsibility benefit from simplicity over optimisation. Single-cloud concentration reduces learning burden and eliminates multi-platform management overhead. Selection should favour providers with strong nonprofit programmes, extensive documentation, and accessible training. Provider stability matters more than technical sophistication; established providers with mature nonprofit programmes carry lower risk than newer entrants with attractive initial terms.

Implementation should begin with well-understood workloads. Email, file storage, and basic collaboration tools migrate to cloud with manageable risk and immediate benefit. These workloads free staff from infrastructure maintenance for services where cloud delivery now represents standard practice. Attempting simultaneous migration of complex workloads alongside basic services overwhelms limited capacity.

External assistance provides temporary expertise for implementation. Cloud migration partners, consultants, or peer organisations with relevant experience can guide implementation decisions. The organisation should develop sufficient internal knowledge to operate cloud services independently; external expertise supplements internal capability during transition rather than replacing it permanently.

For Organisations with Established IT Functions

Organisations with dedicated IT teams can pursue more sophisticated cloud strategies. Multi-cloud becomes viable when dedicated staff can develop expertise across platforms. Hybrid architectures connecting cloud and on-premises infrastructure become practical when network engineering capability exists.

These organisations benefit from formal architecture governance. Cloud adoption without architecture standards creates inconsistency that compounds over time. Landing zone design, service selection criteria, and tagging standards established early prevent technical debt accumulation. Investment in infrastructure-as-code capabilities enables consistent, reproducible cloud deployments.

Organisations at this scale should evaluate build versus buy for cloud capabilities. Managed services reduce operational burden but increase provider dependency. Self-managed services on cloud infrastructure preserve flexibility but require staff capability. The appropriate balance depends on staff skills, strategic priorities, and specific workload requirements.

For Organisations with Field Operations

Field operations introduce constraints that affect cloud strategy. Intermittent connectivity, high latency, bandwidth limitations, and unreliable power shape what cloud services prove practical. Synchronisation patterns, offline capability, and data caching require architectural consideration absent from headquarters-only deployments.

Geographic distribution affects provider selection. Providers with regional presence in operating areas deliver better performance than those requiring connections across continents. Latency from a field office in rural Myanmar to a data centre in Singapore (approximately 50 milliseconds) differs substantially from latency to Frankfurt (approximately 250 milliseconds). Application responsiveness varies accordingly.

Data sovereignty requirements multiply with geographic distribution. Operations spanning multiple countries face requirements from each jurisdiction. Cloud architectures must accommodate data placement rules that vary by country and data type. This complexity argues for cloud platforms with broad regional presence and granular data residency controls.