Workload fit
Review application dependencies, performance needs, data gravity, licensing, latency, and migration complexity before deciding what should move.
Cloud computing services
Cloud decisions grounded in your workloads and operating needs
Plan, migrate, and manage cloud environments with attention to application fit, security controls, reliability, and cost visibility. The right approach depends on your existing systems, constraints, and operating model.
- Workload fit
- Defined scope
- Visible trade-offs
- 01 Applications & dataBusiness systems · APIs · workloads
- 02 Platform & runtimeManaged services · containers · databases
- 03 Compute & storageVirtual machines · storage · network
Cross-cutting controls
Identity & access
Network boundaries
Monitoring
Cost visibility
Illustrative model. Actual components depend on the chosen provider and workload requirements.
Start with the decision
Define the target before choosing the technology.
Cloud adoption is an architecture and operating decision as much as a hosting decision. Begin with the constraints that shape a workable design.
Operating model
Clarify who owns identity, network changes, deployments, monitoring, incident response, backups, and ongoing platform administration.
Risk and cost
Consider resilience targets, recovery requirements, data location, access control, usage patterns, support costs, and the risk of provider-specific dependencies.
Service areas
Cloud services across planning, delivery, and operations.
Scope can be limited to a defined assessment or extended to implementation and operational support. Activities and deliverables are agreed against the environment and engagement requirements.
Cloud strategy and assessment
Establish the current state, identify constraints, compare target-state options, and prioritize feasible next steps.
- Workload and dependency inventory
- Readiness and risk review
- Target-state options and migration waves
Cloud migration and modernization
Plan workload movement while accounting for cutover risk, application dependencies, data transfer, and rollback needs.
- Migration sequencing and readiness
- Rehost, replatform, refactor, or retain decisions
- Validation and cutover planning
Cloud infrastructure design
Design foundational components to fit workload needs, access boundaries, resilience objectives, and operational ownership.
- Compute, storage, and network design
- Account, subscription, or project structure
- Environment separation and connectivity
Cloud platforms and delivery
Assess managed platforms and deployment patterns against application architecture and team operating capabilities.
- Managed runtime and database options
- Container platform considerations
- Deployment automation where appropriate
Security and governance
Translate security and governance requirements into practical controls, ownership, and review points.
- Identity and least-privilege access
- Logging, encryption, and key-management considerations
- Policy and control mapping to stated obligations
Cost and operations optimization
Improve visibility into resource use and establish operational practices that reflect actual demand and service criticality.
- Usage, tagging, and budget visibility
- Rightsizing and idle-resource review
- Monitoring, backup, and recovery planning
Service models
Choose how much of the stack you want to manage.
The service model changes the division of responsibility between the cloud provider and your organization. Exact responsibilities depend on the product and configuration.
IaaS
Infrastructure as a Service
Use virtual compute, storage, and networking resources while retaining substantial responsibility for operating systems, applications, configuration, and data.
Consider when: you need infrastructure flexibility or must retain control over more of the software stack.
PaaS
Platform as a Service
Use a managed application or data platform to reduce the amount of underlying infrastructure your team operates.
Consider when: the application fits the service constraints and the team prefers to focus on code and configuration.
SaaS
Software as a Service
Consume a provider-operated application, with configuration, access, data handling, integration, and subscription choices remaining important.
Consider when: a suitable application can meet the business need without building and running the full stack.
Deployment patterns
Match the deployment model to the constraints.
A design should follow workload, governance, team, and commercial requirements—not the assumption that one deployment pattern is always best.
Public cloud
Provider-operated infrastructure with access to a broad range of managed services and elastic capacity.
Check: usage-based cost, configuration, data location, and
dependency on provider services.
Private cloud
Cloud-style resource management in an environment dedicated to one organization.
Check: capacity planning, platform upkeep, skills, and total cost
of ownership.
Hybrid cloud
Connected on-premises and cloud environments where workloads remain across more than one location.
Check: network dependencies, identity consistency, observability,
and data movement.
Multi-cloud
Use of services from more than one public cloud provider for specific architectural or business reasons.
Check: operating complexity, skills, tool overlap, portability, and
contract overhead.
Delivery approach
A staged path from current state to operation.
The sequence below is a planning framework, not a promise of a fixed timeline. The required depth at each stage depends on scope, dependencies, and risk.
-
01
Discover
Review workloads, interfaces, data flows, operational constraints, and desired outcomes.
Typical output: current-state findings and open questions -
02
Decide
Compare target patterns, migration options, priorities, risks, and indicative cost drivers.
Typical output: options and a scoped recommendation -
03
Prepare
Establish required foundations, identity and network controls, environments, ownership, and migration prerequisites.
Typical output: readiness actions and cutover plan -
04
Migrate and validate
Move agreed workloads in controlled stages, validate functionality and data, and define rollback criteria before cutover.
Typical output: validation evidence for the agreed scope -
05
Operate and improve
Review monitoring, access, backups, recovery, usage, and cost allocation; assign ongoing responsibilities.
Typical output: operational actions and ownership
Operational guardrails
Account for security, resilience, and cost together.
These areas should be designed and reviewed in context. Cloud adoption does not automatically deliver security, availability, regulatory compliance, or lower expenditure.
Identity and data protection
Define who can access each environment, how privileged access is controlled, how secrets and keys are managed, and what data requires protection or residency review.
Reliability and recovery
Set service availability and recovery objectives, identify dependencies, test backup restoration, and validate failover assumptions rather than relying on backup configuration alone.
Observability and ownership
Decide which metrics, logs, traces, alerts, and audit records are needed, who reviews them, and how incidents are escalated and resolved.
Cost visibility and control
Include compute, storage, data transfer, licenses, support, backup, redundancy, and idle resources in cost reviews. Estimates depend on usage assumptions and the chosen design.
Common questions
Questions to resolve before a cloud project.
A sound plan makes assumptions and dependencies visible early, before implementation choices become difficult to reverse.
Can every application be moved to the cloud?
No. Some workloads may be better retained, replaced, re-architected, or delayed. The decision depends on technical dependencies, licensing, latency, data requirements, security obligations, supportability, and economics.
How should we choose a cloud provider?
Compare service fit, existing skills, integration requirements, data-location constraints, resilience options, pricing, contractual terms, and dependence on provider-specific services. A provider should be selected against stated requirements rather than assumed preference.
Will moving to cloud reduce costs?
Not automatically. Costs depend on workload utilization, architecture, licensing, data transfer, support, resilience design, and the effort needed to operate the environment. A useful estimate states its assumptions and should be revisited against observed usage.
Does the cloud provider handle all security responsibilities?
No. Responsibilities are shared and vary by service model. The provider secures parts of the underlying service, while customers typically retain responsibilities for areas such as identities, access, data, configuration, and application security.
What information is useful for an initial discussion?
A high-level workload list, current hosting arrangement, key application dependencies, data sensitivity, availability and recovery needs, known constraints, and the business reason for considering cloud are useful starting points. Sensitive credentials or production data are not needed for an initial scope discussion.
Next step
Start with a defined cloud requirement.
Share the business objective, current environment, and constraints you need to work within. The next step is to clarify scope, information needs, and whether an assessment, migration plan, or operational review is the appropriate starting point.