Executive Summary
Cloud migration is not one purchase and it does not have one price. It is a portfolio of workload decisions: what to retire, what to retain, what to move with limited change, what to replace with SaaS, and what to modernise. A credible business case prices those paths at workload level, then compares their multi-year cost, risk and business value with the cost of keeping the current estate.
For a Singapore enterprise, provider selection is part of that same decision. AWS, Microsoft Azure, Google Cloud and Oracle Cloud Infrastructure (OCI) have different service catalogues, commercial mechanics, ecosystem strengths and operational trade-offs. Region availability is important, but it is not by itself proof of data-residency, regulatory or resilience suitability. Buyers must validate the specific services, backup paths, support access, sub-processors and contractual commitments that apply to their workload.
This guide supplies a transparent framework rather than a universal cost benchmark. Public provider calculators are useful for pricing infrastructure under stated assumptions; they are not a complete migration budget. The missing line items are usually where programmes fail: discovery, landing-zone work, integration, data movement, dual running, security controls, training, decommissioning, FinOps and change management. Use the framework to produce a range, test it through a pilot and make commercial commitments only after real usage is measured.
Key Takeaways
- Start with the portfolio, not a provider quote. Inventory applications, dependencies, data, licences, criticality and owners before pricing or issuing an RFP.
- Use the 7Rs at workload level. Rehost, replatform and refactor have very different delivery effort and steady-state economics; retire and retain are valid outcomes.
- Model three years or more, including transition. A provider calculator may estimate infrastructure, while the programme needs people, parallel running, networking, security, support, tooling and decommissioning.
- Do not compare list-price totals alone. Compare the target architecture, utilisation, availability design, operating model, contractual discounts, data-transfer pattern and commitment risk.
- Run a weighted scorecard and a production-like proof of concept. A feature checklist cannot show latency, operating effort, migration tooling fit or cost behaviour under the enterprise's own workload.
- Build FinOps before migration waves. Tagging, cost allocation, budgets, anomaly detection and decision rights protect the business case after cutover.
- Treat Singapore compliance as a design input. Assess PDPA transfer obligations, contractual requirements, IMDA guidance, MTCS and relevant MAS requirements before selecting services and regions.
- Design an exit path without paying for unnecessary multi-cloud. Portability, data export, infrastructure-as-code, access to logs and practical recovery plans matter more than a generic claim of being “multi-cloud”.
Quick Facts
| Question | Practical answer for buyers |
|---|---|
| What is being bought? | A target operating model and portfolio migration programme, not simply virtual machines or a cloud account. |
| Best estimation unit | Workload or application group, with its dependencies, data, availability target, migration pattern and owner. |
| Core taxonomy | The 7Rs: retire, retain, rehost, relocate, repurchase, replatform and refactor/re-architect. |
| Financial horizon | At least three years, with a separate transition period and sensitivity analysis for growth, utilisation, exchange rate, discounts and exit. |
| Calculator limitation | Provider tools estimate priced services under supplied assumptions; they do not replace discovery, an application plan or an independently owned business case. |
| Singapore data point | Local regions can reduce latency and support data-location choices, but service-specific processing, support and transfer terms still need verification. |
| Commitment principle | Commit stable, measured base load; keep volatile or still-migrating demand flexible. |
| Primary cost discipline | FinOps: allocate spend, measure utilisation, optimise continuously and make engineering, finance and business owners accountable together. |
| Decision evidence | Inventory, 7R rationale, target design, TCO model, risk assessment, scored RFP, proof-of-concept results, contract and exit plan. |
What Is Cloud Migration Cost and Vendor Selection?
Cloud migration cost planning establishes the full economic case for moving selected workloads from their current environment to cloud or SaaS destinations. Vendor selection determines which platform, managed service and delivery partner can meet those requirements at an acceptable cost and risk. The choices are linked: an application strategy changes the target services, and target-service design changes cost, security, skills and portability.
A useful programme distinguishes four decisions that are too often collapsed into one:
- Portfolio decision: which applications and data move, stay, retire or are replaced.
- Architecture decision: the target service model, resilience, integration, identity, security, observability and operating model.
- Commercial decision: pricing, discounts, support, partner funding, commitments, contractual protections and allocation model.
- Delivery decision: who migrates each wave, who accepts risk, how cutover is tested and how the former environment is decommissioned.
The 7Rs: a cost classification, not a slogan
AWS documents seven migration strategies: retire, retain, rehost, relocate, repurchase, replatform and refactor or re-architect. The taxonomy is widely used because it forces a decision on each workload rather than assuming every system should be lifted to infrastructure-as-a-service. The exact label matters less than recording the reason, dependencies, target state, cost assumptions and accountable owner.
| Strategy | What it means | Cost and procurement implication | Typical risk |
|---|---|---|---|
| Retire | Decommission or archive a workload with no justified future use. | Fund records retention, data disposal and dependency removal; capture avoided run cost. | Hidden consumers, legal-retention gaps or a late business owner objection. |
| Retain | Keep it in the present environment for now. | Keep on-premises, colocation or existing-service cost in the target TCO; define the review trigger. | “Temporary” retention becoming an ungoverned permanent estate. |
| Rehost | Move largely as-is to cloud infrastructure. | Usually lower application-change effort, but target sizing, licensing and operations may preserve legacy cost. | Moving underutilisation and unsupported dependencies unchanged. |
| Relocate | Move an environment at hypervisor or managed-platform level with minimal application change. | Can accelerate a platform move; evaluate platform dependency, licences and later modernisation cost. | Locking in a temporary landing pattern without an exit roadmap. |
| Repurchase | Replace a capability with SaaS. | Compare subscription, integration, data migration, configuration and exit terms—not only licence price. | Functional gaps, data portability and shadow customisation. |
| Replatform | Make limited changes to use managed cloud services. | More engineering up front; can remove selected infrastructure and operations work. | Underestimating data migration, testing or managed-service constraints. |
| Refactor | Redesign the application for cloud-native capabilities. | Highest uncertainty and change-management need; assess it as a product-modernisation investment, not a lift-and-shift task. | Mixing a broad rewrite with a deadline-driven data-centre exit. |
Who should use this framework—and who should not?
Use it when the organisation has multiple applications, regulated data, material technology debt, a data-centre or hosting renewal, a business-continuity objective, or a need to establish a primary cloud platform. It is also useful for a SaaS replacement because subscription economics, integration and exit need disciplined comparison.
Do not turn it into a heavyweight programme for a single low-risk, isolated workload that already has a clear target and owner. That work still needs a small cost, security and recovery assessment, but it may not need a multi-provider RFP. Conversely, do not use a short pilot to justify an enterprise-wide provider standard without testing the services and controls that will carry the largest risk or cost.
Why It Matters: Cloud Economics Are Architecture and Operating Decisions
Cloud changes the cost curve, not the requirement to manage capacity, security, availability and people. Elastic services can eliminate or reduce specific capital costs, but an always-on, over-sized or highly available target can cost more than its previous environment. The cloud bill reflects resource choices, duration, regions, data movement, support and third-party services. It also reflects whether the organisation can observe and govern them.
Migration can make costs temporarily higher. Source and destination environments may run in parallel; data may be copied repeatedly; teams may need specialist delivery support; and new monitoring, security and networking services may be introduced before older contracts are ended. A fair business case shows this transition explicitly rather than presenting the future-state run rate as Year 1 cash spend.
The same is true of vendor selection. A provider with a lower quoted compute rate may be a more expensive choice if the target design needs costly cross-region traffic, specialist skills, a separate security stack or an unwieldy support model. A provider with stronger existing enterprise agreements may be more attractive for a Microsoft estate, while an AI- or data-intensive platform may have a better engineering fit elsewhere. These are hypotheses to test, not rankings to repeat.
Singapore Market Overview
Singapore is a regional technology and connectivity hub with local public-cloud regions and a dense ecosystem of carriers, data centres, system integrators and managed-service providers. That makes local deployment possible for many workloads, but buyers should verify service availability at the product and feature level. A region may not offer every managed service, capacity type, availability-zone design or compliance option needed by the target architecture.
IMDA’s cloud-services materials include Singapore’s Multi-Tier Cloud Security (MTCS) scheme and, in 2025, Advisory Guidelines for the resilience and security of cloud services and data centres. The advisory guidelines are industry best-practice guidance, not a substitute for a buyer’s own resilience design. They reinforce the need to assess misconfiguration, cyber, physical and recovery risks rather than assuming the provider’s platform removes them.
Data location is a control requirement, not a checkbox
The Personal Data Protection Act (PDPA) includes a Transfer Limitation Obligation for personal data transferred overseas. A Singapore region can be part of a sound design, but it does not by itself answer where backups, logs, support data, telemetry, disaster-recovery copies, sub-processors or globally scoped services are processed. Ask each provider and partner for service-specific answers and record the contractual and technical safeguards that make the answer true.
Financial institutions and their material outsourced arrangements need additional attention. MAS Technology Risk Management and outsourcing expectations, as well as applicable notices and internal policies, should inform due diligence, audit rights, business continuity, access, notification and exit requirements. The regulated entity remains accountable; a provider’s compliance mapping is supporting evidence, not a transfer of responsibility.
Singapore-specific buyer checks
- Confirm the exact Singapore-region availability, zone model, capacity options and roadmap for each required service.
- Map data categories to in-country, regional, multi-region and global service locations, including backup and support paths.
- Assess private connectivity, carrier choice, data-centre cross-connects, remote offices and regional disaster recovery as one network design.
- Use MTCS, ISO/IEC 27001, SOC reports and cloud-control mappings as evidence inputs; validate their scope, service applicability and reporting period.
- For financial services, bring risk, compliance, internal audit and legal teams into the selection before contract terms are fixed.
- For public-sector or sector-specific workloads, apply the relevant agency and sector policy rather than assuming commercial-cloud terms are sufficient.
Cloud Migration Cost Framework: Build a Workload-Level Three-Year TCO
Do not rely on a generic “cost per server” or “cost per application” number. Public sources do not provide a reliable, comparable market price for every enterprise programme. A simple web-estate migration and a regulated core system can have similar server counts but radically different dependencies, testing, data, licensing and downtime costs. The only defensible starting point is a portfolio inventory.
1. Establish the baseline and the unit of analysis
For each workload or tightly coupled application group, record the business service, owner, users, criticality, uptime target, dependencies, interfaces, data classification, current cost, licensing, average and peak utilisation, environment count, recovery objectives, retention rules and target migration window. Reconcile this with finance and vendor contracts; a CMDB alone rarely contains all commercial facts.
Then calculate two comparable futures: status quo (including refresh, support, hosting, energy, facilities and licence renewals) and target state (migration plus cloud run costs). Use the same growth, availability and service-level assumptions in both. If the current baseline ignores internal labour or a looming hardware refresh, the comparison will be biased.
2. Price the migration programme separately from steady state
| Cost domain | Include in the migration budget | Evidence to request |
|---|---|---|
| Discovery and planning | Inventory, dependency mapping, 7R decisions, target architecture, risk assessment, wave plan and business-case ownership. | Workload register, assumptions log, dependency evidence and signed 7R rationale. |
| Foundation and governance | Landing zones, identity, network, logging, security controls, account structure, policy, backup and cost-allocation setup. | Reference architecture, control map, infrastructure-as-code and operational acceptance criteria. |
| Application and data work | Migration tooling, transformation, integration changes, data cleansing, transfer, testing, cutover and rollback. | Per-wave plan, volume estimate, reconciliation and test evidence. |
| Parallel running | Source and target capacity, licences, connectivity, support and operational overlap until acceptance and decommissioning. | Explicit overlap duration, exit criteria and source shutdown owner. |
| People and change | Internal backfill, partner services, training, service management, operating-model change and stakeholder communication. | RACI, skills plan, rate card, named roles and deliverables. |
| Risk and contingency | Remediation, security testing, legal or compliance review, late dependencies, rework, exchange-rate exposure and controlled contingency. | Risk register linked to a quantified or governed contingency approach. |
| Decommissioning | Data retention or disposal, contract termination, hardware disposition, licence changes, records and confirmation that costs ceased. | Decommission checklist, financial close-out and evidence of asset disposition. |
3. Price the steady-state service honestly
| Run-cost category | Questions that change the answer |
|---|---|
| Compute and platform | What utilisation, schedule, instance family, autoscaling, managed service, operating system and licence model is assumed? |
| Storage, backup and recovery | How much hot, warm, archive and replicated data exists? What are retrieval, retention, cross-region and recovery-test costs? |
| Networking and data transfer | Where do users, on-premises systems, SaaS, partners and DR sites sit? What traffic crosses zones, regions, clouds or the internet? |
| Security, observability and operations | Which logging, SIEM, posture, key-management, vulnerability, monitoring, incident-response and automation services are required? |
| Support and partners | What support tier, response target, service-management coverage, managed-service fee and escalation route are needed? |
| Licensing and third parties | Which database, operating-system, backup, marketplace, SaaS, commercial open-source and network-security licences remain or change? |
| People and FinOps | Who owns platform engineering, security, SRE, FinOps, chargeback/showback, tagging quality, optimisation and architecture review? |
| Commitment and exit exposure | What is the cost if consumption falls, a region changes, a product is retired or data must be exported to another location? |
4. Use ranges and sensitivity analysis
For each provider, calculate optimistic, base and downside scenarios. Change the assumptions most likely to move the result: migration-wave slippage, source overlap, utilisation, data growth, data egress, availability design, foreign exchange, licence eligibility, partner rates and commitment utilisation. Show net present value, payback and cash flow by period only if the underlying assumptions are reviewable.
Three-year target TCO = one-time migration and transition cost + three years of cloud service, licences, support, people and governance cost + exit or residual cost. Compare that with the equivalent status-quo cost over the same period. Keep risks and benefits separate from cost reductions; resilience, delivery speed and product capability may be valid benefits, but they should not be silently counted as cash savings.
Provider calculators: use them, but control their assumptions
AWS Pricing Calculator, Azure Migrate business cases and assessments, and Google Cloud pricing tools can accelerate infrastructure estimates. Microsoft’s Azure Migrate documentation, for example, shows how its business case can include right-sizing and selected Azure Hybrid Benefit assumptions. That is useful, but every tool is naturally optimised around its own target platform and available inputs. Export the assumptions, add omitted programme costs and apply the same level of design detail across every shortlisted provider.
How Enterprise Buyers Should Evaluate Cloud Providers
Set non-negotiables before scoring
Separate pass/fail requirements from scored preferences. Examples of genuine gates include legal data restrictions, required Singapore or regional service location, regulated-workload controls, supported operating systems, recovery objectives, cryptographic key requirements, unacceptable supplier terms or a material inability to migrate within a critical deadline. Do not let a high feature score obscure a failed gate.
Use a weighted scorecard that reflects your estate
The weights below are an example for a mixed enterprise portfolio, not a universal answer. A bank may weight control assurance and operational resilience more highly; a product company with an AI roadmap may place more weight on data, AI and engineering productivity. Publish the weights before seeing vendor scores and preserve the evidence behind each score.
| Domain | Example weight | What to test |
|---|---|---|
| Security, governance and compliance | 20% | Identity, key management, logging, policy, assurance reports, residency controls, shared responsibility, audit and incident obligations. |
| Workload and platform fit | 20% | Required compute, databases, integration, operating systems, containers, migration tooling, service maturity and regional availability. |
| Economics and FinOps | 20% | Comparable target architecture, discount mechanics, billing data, allocation, budgets, optimisation tools, egress and commitment risk. |
| Data, analytics and AI | 15% | Data-platform fit, governance, model and AI service needs, data movement, performance, skills and sovereignty requirements. |
| Resilience and connectivity | 10% | Zone and region architecture, DR options, private connectivity, carrier ecosystem, operational visibility and tested recovery approach. |
| Support and ecosystem | 10% | Singapore delivery coverage, escalation route, partner quality, managed services, training, documentation and referenceability. |
| Contract, portability and exit | 5% | Data export, configuration and log access, termination assistance, price protections, audit rights, sub-processors and transition support. |
Make the proof of concept representative
A cloud proof of concept should test the workload characteristics that drive the decision: identity integration, private networking, a realistic data volume, backup and restore, observability, security controls, deployment pipeline, failure behaviour, performance and a measured cost report. Synthetic compute tests can be useful, but they do not validate an enterprise’s cross-system traffic, data gravity, change process or support model.
Define success criteria, responsibility, data handling, budget cap, exit and evidence before starting. Require the same use case and reporting standard from each contender. A POC that relies on unpriced credits or a specialist vendor team should state what changes when it becomes production.
Questions to put to every bidder
- Which required services and features are available in the intended Singapore and recovery regions today, and what is excluded?
- Show the cost model by workload, including assumptions for utilisation, storage, data transfer, HA/DR, support, licences and commitments.
- Which costs are intentionally excluded from your estimate, and who owns them?
- Which personal-data, telemetry, support, backup and sub-processor locations apply to each selected service?
- What controls are provider, customer and managed-service-provider responsibilities? Show the operating RACI.
- How will you migrate, validate, roll back and decommission each wave? Provide comparable delivery references.
- What is the partner’s commercial relationship with each cloud provider, including resale, funding and incentives?
- What happens to data, encryption keys, logs, infrastructure definitions, discounts and support tickets at termination?
Vendor Landscape: Where Each Major Platform Usually Fits
This is a fit assessment, not a league table. All four providers below offer broad enterprise services and have material limitations that vary by service, region and contract. Buyers should use current service-location pages, documentation, commercial schedules and a POC rather than assume a capability applies in every Singapore deployment.
Amazon Web Services (AWS)
Core strengths: broad service catalogue, a large global partner ecosystem, mature infrastructure and migration tooling, and multiple commitment options. AWS’s prescriptive guidance documents the 7Rs and its Pricing Calculator can model workloads and available account discounts.
Trade-offs: service breadth can create governance and skills overhead. A large catalogue also means that service selection, policy design and pricing need active architecture and FinOps discipline. Validate the exact regional availability, service terms and data-transfer paths.
Often a fit for: diverse portfolios, cloud-native platforms, organisations with existing AWS skills, or programmes that value service breadth and partner choice. It may be less attractive when an enterprise needs to maximise a different existing licensing estate or cannot govern a broad self-service platform.
Microsoft Azure
Core strengths: strong alignment with Microsoft identity, Windows Server, SQL Server, Microsoft 365 and hybrid management patterns. Azure Migrate supports discovery, assessment and business-case workflows, including selected licensing assumptions such as Azure Hybrid Benefit.
Trade-offs: licensing and enterprise-agreement economics can be complex; savings depend on actual eligibility and usage. Buyers should validate whether target services, governance tools and operational ownership work consistently across subscriptions, management groups and recovery designs.
Often a fit for: Microsoft-centric estates, hybrid operations and teams that can make use of existing Microsoft commercial and identity investments. It is not automatically the lowest-cost choice for every application; it must be modelled against the intended target architecture.
Google Cloud
Core strengths: strong market relevance for data platforms, analytics, AI services, Kubernetes and developer-oriented cloud operations. Google documents Singapore as the asia-southeast1 location group; buyers must still check the exact service, zone and data-governance behaviour.
Trade-offs: organisations without existing Google Cloud skills or partners may face a capability ramp. Some enterprise workloads may require careful validation of product maturity, partner coverage, support processes and integration with established tooling.
Often a fit for: data- and AI-intensive workloads, Kubernetes-centric engineering organisations, or teams that value Google-managed data services. It should be compared on workload-specific economics and operating fit, not only on compute prices.
Oracle Cloud Infrastructure (OCI)
Core strengths: a relevant contender for Oracle database and enterprise-application estates, and for buyers whose commercial or data-transfer patterns warrant an OCI comparison. OCI’s published materials highlight a monthly outbound-data allowance; check the current regional price list and product terms rather than extrapolating a marketing comparison to an entire estate.
Trade-offs: provider and partner breadth, service maturity and availability must be assessed against the enterprise’s required services rather than inferred from an Oracle workload. A narrow commercial advantage can be outweighed by skills, integration or operating costs.
Often a fit for: Oracle-centred portfolios, certain enterprise database modernisation paths, or a well-defined price/performance and connectivity case. It should enter a short list only when the workload and exit requirements support it.
Enterprise Comparison and Decision Matrix
| Provider | Common strengths | Buyers should probe | Best initial evaluation use case |
|---|---|---|---|
| AWS | Service breadth, migration guidance, ecosystem and mature cloud-native options. | Governance at scale, regional service fit, operating skills, data-transfer design and commitment coverage. | A representative mixed application group with landing-zone, network, security and managed-service needs. |
| Microsoft Azure | Microsoft and hybrid alignment, identity integration, migration assessment and enterprise agreements. | Actual licensing eligibility, subscription governance, target-service fit, support model and cross-region design. | A Windows/SQL or hybrid application with identity, backup, monitoring and licence assumptions fully modelled. |
| Google Cloud | Data, AI, analytics, Kubernetes and developer platforms. | Singapore service availability, operational skills, enterprise integration, partner coverage and data-governance settings. | A data or AI pipeline that includes real data volume, access controls, observability and model operations. |
| OCI | Oracle-workload relevance and a commercial comparison point for selected infrastructure and egress patterns. | Required service depth, partners, operations, data portability and lifecycle alignment beyond the Oracle estate. | An Oracle-centred database or application workload with complete licensing, connectivity and exit analysis. |
How to use the matrix: score provider evidence against your pre-agreed weights, then include the costed POC and contract terms. Do not award points for a roadmap item unless delivery date, location, support and commercial terms are contractual enough to carry the business risk.
Pricing Overview, Commitments and FinOps
Understand the main pricing levers
| Pricing model | When it helps | Buyer caution |
|---|---|---|
| Pay as you go | Discovery, pilots, migration waves, seasonal demand and volatile workloads. | Flexibility can conceal waste without budgets, schedules, rightsizing and ownership. |
| Committed usage or spend | Measured base load with predictable demand. AWS Savings Plans, Azure savings plans and Google Cloud CUDs use one- or three-year terms for eligible resources. | Discounts do not eliminate the obligation to pay. Model utilisation, scope, portability, region and term risk before purchase. |
| Reservations | Stable, specific usage where a more targeted commitment has clear value. | More specificity can mean less flexibility. Azure notes that reservations and savings plans have different scope and trade-offs. |
| Enterprise agreement or negotiated pricing | Large, strategic or multi-service consumption with commercially meaningful forecasts. | Compare effective price, minimum-spend risk, ramps, currency, service exclusions, credits, renewals and exit—not headline discount percentage. |
| Managed service | When internal staffing, 24/7 operations, platform engineering or compliance evidence cannot be efficiently built in-house. | Separate cloud consumption, provider support and partner fee. Define automation, access, responsibility, evidence and transition-out rights. |
AWS Savings Plans exchange a one- or three-year usage commitment for lower eligible compute prices. Microsoft describes Azure savings plans as hourly-spend commitments and Azure Reservations as more resource- and region-specific. Google Cloud resource-based CUDs commit selected compute resources for one or three years. The common lesson is not the maximum advertised discount: it is that an unused commitment is still a cost. Make commitments after migration data has stabilised, with a documented utilisation threshold and owner.
FinOps operating model
FinOps is not a monthly finance report. Establish it during the landing-zone phase so cloud accounts, subscriptions or projects have owners; cost allocation is usable; and teams can act on the data. The FinOps Foundation frames cloud financial management as a cross-functional practice. Its concepts are useful even if the enterprise uses another framework.
- Inform: standardise tags or labels, account hierarchy, billing exports, budgets, forecasts, anomaly alerts and allocation rules.
- Optimise: rightsizing, schedules, storage lifecycle, commitment coverage, idle-resource removal, architecture reviews and data-transfer design.
- Operate: give product teams timely cost visibility, review unit economics where relevant, and connect material cost changes to engineering and business decisions.
Compliance, Security and Resilience Considerations
Cloud compliance is a shared-responsibility exercise. Certifications and independent reports can provide assurance about a provider’s controls, but the enterprise remains responsible for service configuration, identities, data classification, workloads, integrations, monitoring, incident response and the controls it delegates to a managed-service provider.
| Area | What to assess before contracting |
|---|---|
| PDPA and cross-border data | Data inventory, purpose, transfer mechanism, comparable protection, service locations, backup, support, sub-processors, deletion, breach and audit obligations. |
| Singapore assurance | Whether MTCS, ISO/IEC 27001, SOC reports, Cloud Security Alliance materials or other assurance applies to the exact service and period in scope. |
| Financial services | MAS TRM and outsourcing requirements, materiality, audit and access rights, notification, business continuity, concentration and exit requirements. |
| Identity and privileged access | Federation, least privilege, administrator break-glass, credential lifecycle, service accounts, logging and partner access. |
| Encryption and keys | Encryption scope, key ownership and lifecycle, HSM or external-key needs, recovery, access, rotation, export and legal requirements. |
| Resilience and recovery | Failure domains, RTO/RPO, backup immutability, restore testing, regional recovery, dependency mapping, runbooks and communication obligations. |
| Logging and evidence | Log sources, retention, immutability, SIEM integration, data location, monitoring ownership, security alerts and evidence export. |
| Exit and concentration | Data and configuration export, format, egress cost, transition support, key handling, replacement timeline and whether the design depends on proprietary services. |
For high-impact services, test restoration and operational recovery instead of accepting an availability SLA as the whole resilience design. A cloud region is not an application architecture, and a multi-region design is not necessarily recoverable until dependencies, data, identity and procedures are exercised.
Implementation Considerations: Deliver by Waves and Accept Evidence
| Phase | Indicative purpose | Exit evidence |
|---|---|---|
| 1. Mobilise | Set sponsorship, governance, objectives, scope, business-case ownership and decision rights. | Charter, RACI, funding model, risk register and measurement plan. |
| 2. Discover and rationalise | Build the inventory, map dependencies and classify the 7Rs with application owners. | Validated workload register, dependency map, owners and prioritised migration backlog. |
| 3. Design the foundation | Implement account structure, identity, network, security, logging, backup, operations and FinOps guardrails. | Tested landing zone, control evidence, operating runbooks, billing allocation and support route. |
| 4. Pilot | Prove a representative pattern and improve the playbook before high-volume waves. | Measured cost, performance, security, recovery, cutover and rollback results; lessons incorporated. |
| 5. Migrate waves | Move grouped workloads by dependency, criticality and repeatable pattern. | Business acceptance, data reconciliation, observability, recovery evidence, source shutdown trigger and cost handover. |
| 6. Optimise and decommission | Rightsize, improve reliability, purchase only justified commitments and remove former cost. | Source closure, asset and contract updates, realised-cost report and remaining-risk roadmap. |
Internal stakeholders to involve
Executive sponsorship sets the value and risk appetite. Application owners accept functional outcomes. Platform, security, network and data teams design controls and operational handover. Finance owns the baseline and cost-accounting method. Procurement and legal control the commercial position. Risk, compliance, privacy and internal audit need timely evidence—not a contract sent for review after the technical decision is complete.
Migration-partner selection
Evaluate partners separately from platforms. Ask for delivery experience in comparable applications and regulated contexts, named delivery roles, capability transfer, customer references, approach to failed cutovers, cloud-provider incentives, tool licensing, security responsibility and post-migration FinOps support. The enterprise should own its cloud tenant, administrative control plane, billing data, infrastructure code, documentation and exit plan even when a partner operates it.
Common Procurement and Implementation Mistakes
- Starting with a provider discount. A credit or headline discount can be useful, but it should not substitute for portfolio discovery and the target architecture.
- Using one blended migration number. Retiring a low-use system, rehosting a packaged application and refactoring a customer platform are different investments.
- Comparing unlike architectures. One provider may be priced as a single-zone VM design and another as managed multi-zone services. Normalise the requirements first.
- Ignoring dual running and decommissioning. The business case should identify when former capacity, licences, support and contracts actually stop.
- Buying commitments before usage is stable. Migration waves, modernisation and demand changes can leave discounted capacity unused.
- Calling a region a data-residency answer. Verify selected services, global controls, backup, support, telemetry and sub-processors.
- Designing resilience only around a provider SLA. Test application-level recovery across dependencies, identities, data and operational runbooks.
- Letting a system integrator own the business case. The partner can contribute estimates, but the enterprise must own assumptions, risk acceptance and final scoring.
- Equating multi-cloud with an exit plan. Two platforms without common operating capability can add cost and complexity. Define the actual scenario that needs portability.
- Launching FinOps after the bill arrives. Cost allocation, accountability and baseline reporting are landing-zone requirements.
- Leaving exit terms to renewal. Data export, log access, encryption keys, infrastructure definitions, support and assistance are easiest to negotiate before onboarding.
Future Trends: 2026-2029
AI will change the cost model—not remove it
AI workloads can introduce high-value capabilities and new consumption patterns for accelerators, model inference, data platforms, observability and governance. Buyers will need workload-level unit economics, capacity planning and data-governance controls rather than relying on broad AI credits or aggregate cloud-spend forecasts.
Resilience and concentration risk will receive more board attention
Enterprises will ask more rigorous questions about cloud dependencies, common failure modes, provider concentration, regional recovery and exit readiness. The practical response is not automatically multi-cloud; it is a measured architecture and tested recovery plan aligned to each service’s impact.
Cost governance will shift into engineering workflows
Infrastructure-as-code, policy-as-code, cost data and architecture review will increasingly be connected. The useful goal is prevention: identify an untagged, oversized, unapproved or cross-region design before it becomes production spend.
Commercial flexibility will be valued alongside discounts
As architectures change, buyers will evaluate not only the discount but also scope, utilisation, currency, renewal, portability, data-transfer and termination risk. A slightly higher flexible rate can be a better commercial outcome than an inflexible commitment with poor utilisation.
Sustainability and local infrastructure constraints will influence placement
Singapore’s data-centre policy and energy-efficiency focus mean location, workload efficiency and infrastructure utilisation may become more visible procurement topics. Treat provider sustainability reporting as an input to the decision, then connect it to the organisation’s own measurement method and workload design.
Frequently Asked Questions
How much does an enterprise cloud migration cost?
There is no credible universal figure. Price the workload portfolio with its 7R strategy, target architecture, data, licences, testing, people, parallel running and decommissioning. Present a range with clear assumptions, not an unsupported average.
What are the 7Rs of cloud migration?
Retire, retain, rehost, relocate, repurchase, replatform and refactor/re-architect. They are alternative paths for a workload, not mandatory stages. The correct choice depends on business value, dependency, risk, target state and available time.
Should we choose AWS, Azure or Google Cloud?
Choose the provider that best meets your validated workload, commercial, security, operating and exit requirements. Azure is often relevant to Microsoft and hybrid estates; AWS to broad portfolios and ecosystem needs; and Google Cloud to data, AI and Kubernetes needs. Test actual services and terms. OCI can be relevant for Oracle-centred workloads and defined commercial cases.
Do provider calculators include total migration cost?
No. They are valuable infrastructure-pricing inputs, but the programme budget must also include discovery, foundations, application work, data movement, partner and internal labour, dual running, testing, security, change management, FinOps and decommissioning.
Does the PDPA require all data to be hosted in Singapore?
Not universally. The PDPA’s Transfer Limitation Obligation applies to overseas transfers of personal data. Other rules and contracts may be stricter. Verify data flows for the selected service, including backup, support, global control planes and sub-processors.
When should we buy Savings Plans, reservations or CUDs?
After the workload is in steady state and usage has been measured. Match the commitment to the stable base load, maintain flexible capacity for uncertainty and monitor commitment utilisation continuously.
Is multi-cloud a good exit strategy?
It can support a specific resilience or capability requirement, but it is not automatically a cheaper or simpler exit strategy. A primary-cloud design with portable data, infrastructure code, documented interfaces and tested recovery may be more proportionate.
How do we control egress costs?
Map data flows before selection: users, on-premises systems, SaaS, partners, regions, clouds, backup and recovery. Design to minimise avoidable cross-boundary transfers, then price the required flows with current provider rate cards and test them in the POC.
What should be measured after each migration wave?
Business acceptance, performance, security-control coverage, backup and restore, availability, cutover and rollback outcomes, user experience, cloud cost, former-environment cost reduction, tag quality and any unresolved risks.
How should we compare cloud-migration partners?
Score comparable delivery experience, named capability, implementation method, security and change controls, commercial incentives, knowledge transfer, post-migration support, FinOps support, evidence quality and exit support. Do not select only on the provider badge count.
What is a practical first step?
Commission a time-boxed discovery that produces a validated workload inventory, a 7R decision for the first migration waves, an initial landing-zone design, a transparent TCO model and a shortlist of proof-of-concept use cases. It should be owned by the enterprise, even when a partner performs the work.
Can a cloud migration save money?
It can, but savings are not automatic. Savings depend on what is retired, how resources are sized and scheduled, which licences change, how data moves, how support is organised and whether the organisation controls waste. Treat resilience, speed and product capability as separate benefits unless they produce measured cash effects.
Final Recommendations
Fund discovery before committing to a provider or a migration target. The deliverable should be a workload-level 7R map, dependencies, target patterns, risks and an assumptions-led financial model—not a generic cloud assessment deck.
Shortlist providers with gates, a weighted scorecard and a representative proof of concept. Compare a like-for-like architecture and measured operation. Let actual service availability, support, data handling, integration, cost and recovery evidence decide the outcome.
For Singapore, treat compliance, data transfer and resilience as design constraints. Map PDPA, IMDA guidance, MTCS and any applicable MAS or sector requirements to the exact services and responsibilities being bought. Keep legal and regulatory interpretation with the accountable organisation.
Operate the business case after migration, not just before approval. Establish FinOps, track source shutdown, test recovery, measure realised outcomes and review commitments as usage evolves. The goal is not the lowest opening estimate; it is a cloud operating model whose cost, risk and value remain understandable over time.
Selected Primary Sources and Further Reading
This guide was reviewed against the public sources below on 14 August 2026. Cloud products, availability, pricing, regulatory guidance and contracts change frequently. Confirm the current service-specific position before relying on it in a procurement or compliance decision.
- AWS Prescriptive Guidance: migration strategies (7Rs) and detailed portfolio discovery.
- AWS Pricing Calculator and AWS Savings Plans.
- Azure Migrate business case overview and Azure Migrate cost-estimation assumptions.
- Azure savings plans versus reservations.
- Google Cloud locations, Google Cloud location restrictions and Google Cloud committed use discounts.
- Oracle Cloud Infrastructure cloud-economics material and the current OCI price list.
- FinOps Foundation Framework.
- PDPC Advisory Guidelines on the PDPA for Selected Topics (revised May 2024).
- IMDA cloud computing and services standards and IMDA Advisory Guidelines for Cloud Services and Data Centres.
- MAS Technology Risk Management Guidelines and applicable MAS outsourcing requirements.
Browse Cloud and Technology Providers in Singapore
TechDirectory lists directory records for cloud providers, system integrators, managed-service providers, cybersecurity companies and data-centre operators. Profiles may show recorded assessment, migration, operations and governance capabilities, plus approved reviews where available. Verify delivery capability, commercial relationship, certifications, service scope and references before contracting.
Browse Cloud Providers →