Home
Resources
SAP Cloud Migration in 2026: The Complete Strategy Guide for Enterprise Leaders

Cloud

SAP Cloud Migration in 2026: The Complete Strategy Guide for Enterprise Leaders

Cloud Architecture Expert Co-founder & CTO of Gart

March 6, 2026

The clock is ticking. With SAP ECC mainstream support ending in 2027, SAP cloud migration has moved from a strategic discussion to an operational emergency. Nearly 17,000 organizations — representing 61% of the global SAP install base — are still in the planning or early execution phases of their transition. For many, 2026 is the last full year to act before consulting costs surge and certified talent becomes scarce.

This guide walks you through everything enterprise leaders need to know: which migration path to choose, how to unlock AI-native capabilities, what the real ROI looks like, and how Gart Solutions helps organizations execute with precision and measurable outcomes.

Why 2026 Is the Critical Window for SAP Cloud Migration

The urgency of SAP cloud migration stems from two converging forces: a hard deadline and a transformative opportunity.

On the deadline side, SAP will end mainstream support for ECC in 2027. Organizations that have not completed their transition by then will face extended maintenance contracts at a premium, a shrinking pool of certified implementation partners, and rising consulting rates driven by demand concentration. Industry analysts project a significant “bottleneck” effect as thousands of organizations compete for the same resources in the final stretch.

On the opportunity side, SAP S/4HANA in the cloud is no longer just a technical upgrade — it is an AI-native business platform. The 2026 version of S/4HANA delivers autonomous workflows, predictive decision-making, real-time embedded analytics, and AI copilot capabilities that simply do not exist in legacy ECC environments. Organizations that migrate now position themselves to compete on the basis of intelligence and speed, while those that wait risk falling behind competitors who are already using AI to close their books faster, manage supply chains autonomously, and serve customers more responsively.

The Business Case in Numbers

Early adopters and independent industry research have produced a compelling set of benchmarks that make the economic case for SAP cloud migration difficult to ignore:

30–50% reduction in IT infrastructure costs
Up to 70% acceleration in financial close cycles
70% reduction in manual finance tasks through AI-driven workflows
547% average five-year total ROI
Up to 200x improvement in operational efficiency for certain workflows
100% system availability even during peak traffic periods such as Black Friday retail surges

These are not theoretical projections. They are outcomes documented by organizations that have completed their SAP cloud migration and are now operating on a modern, cloud-native platform.

Choosing the Right SAP Cloud Migration Path

The single most consequential decision in any SAP cloud migration program is choosing the right methodology. In 2026, three primary approaches dominate the landscape, each with distinct implications for speed, cost, risk, and long-term innovation potential.

Greenfield: Build Clean, Start Fresh

A Greenfield migration treats the S/4HANA deployment as a net-new implementation. The organization designs its ERP landscape from scratch, adopting SAP Best Practices and eliminating decades of accumulated technical debt in the process.

This approach is ideal for organizations whose existing ECC processes are heavily customized, outdated, or simply no longer aligned with how the business operates today. Greenfield migrations enable a “Clean Core” strategy from day one — meaning the new system is built without legacy modifications that would impede future AI-driven upgrades.

The trade-off is investment. Greenfield implementations typically require 18 months to three years and significant organizational change management. However, for organizations that are committed to becoming genuinely AI-native, starting clean is often the right long-term decision.

Best for: Organizations with outdated processes, multiple legacy ERP instances, or a strategic mandate to transform operations comprehensively.

Brownfield: Convert What You Have

Brownfield migration — formally known as system conversion — lifts an existing ECC environment and converts it to S/4HANA. Most configurations, custom code, and historical data are preserved during the process.

This approach is favored by organizations facing imminent support deadlines or those with high-quality existing processes they do not want to disrupt. Brownfield migrations can typically be completed in six to 18 months, making them the fastest path to S/4HANA compliance.

The trade-off is long-term debt. By carrying forward legacy customizations, organizations often limit their ability to fully leverage cloud-native innovations such as real-time analytics and AI-embedded workflows. A Brownfield migration may meet the 2027 deadline while still leaving the organization architecturally behind.

Best for: Organizations with tight timelines, well-functioning existing processes, and a near-term focus on compliance over transformation.

Bluefield: The Strategic Hybrid

The Bluefield approach — also known as Selective Data Transition — has emerged as the most popular choice for large enterprises in 2026, and for good reason. It offers the discipline of Greenfield (intentional redesign of critical processes) with the continuity of Brownfield (preservation of historical data and stable workflows).

Under Bluefield, organizations migrate selectively: reinventing areas of the business where innovation is most valuable while retaining data and configurations where continuity matters. This approach is particularly powerful for companies with multiple ERP instances that need to be consolidated into a single S/4HANA core.

Data cleansing and harmonization happen during the migration itself, ensuring that the target system is populated with clean, actionable information from the moment it goes live.

Best for: Large enterprises, multi-instance landscapes, organizations seeking both transformation and continuity without betting everything on one approach.

Understanding RISE with SAP: A New Commercial Model

RISE with SAP — now officially called SAP Cloud ERP — is SAP’s primary vehicle for moving customers to the cloud. Rather than selling a software license separately from infrastructure and managed services, RISE bundles all three into a single subscription contract with SAP as the single point of accountability.

This model eliminates the fragmentation of traditional SAP deployments, where customers had to manage separate vendor relationships for software, hyperscaler infrastructure, and implementation services. Under RISE, SAP coordinates service level agreements across the entire stack and manages upgrades according to a published roadmap.

The commercial shift is equally significant. RISE converts SAP from a capital expenditure into an operating expense, which aligns ERP costs with business consumption and removes the need for on-premise hardware investment cycles.

That said, RISE introduces its own complexities. CIOs must carefully evaluate license metrics, long-term cost trajectories, and the risk of vendor dependency before committing to multi-year contracts. Proactive Software Asset Management (SAM) and well-defined renewal roadmaps are essential to maintaining negotiating leverage as contracts mature.

AI-Native Capabilities: What SAP Cloud Migration Unlocks

Moving to S/4HANA in the cloud is not simply about keeping the lights on after 2027. It is the gateway to a fundamentally different way of running a business — one powered by embedded AI that reasons, acts, and learns on behalf of users.

Joule: SAP’s AI Copilot

Joule is the AI interface that spans SAP’s entire cloud portfolio. In 2026, it has reached a level of maturity that allows it to perform deep research across both internal SAP data and external web resources, delivering comprehensive insights in natural language. Joule is now available across multiple languages and devices, including a sophisticated mobile experience for field sales teams.

Autonomous AI Agents Across Business Functions

Beyond Joule as a conversational interface, SAP has deployed specialized AI agents that automate complex, multi-step business workflows without human intervention:

Human Capital Management: In SAP SuccessFactors, Joule agents now automate succession planning, identify leadership potential from workforce data, and detect payroll anomalies before the final payroll run — reducing both risk and manual effort for HR teams.

Procurement and Spend Management: Agents in SAP Ariba and Concur handle natural language procurement requests and automated expense categorization, delivering an average 12% productivity gain in procurement intake and an 11.5% improvement in travel booking speed.

Asset and Maintenance Management: A dedicated Maintenance Planner Agent helps industrial organizations prioritize maintenance tasks proactively, reducing unplanned downtime and extending equipment lifecycles.

Customer Experience: AI-powered CX workflows are producing up to 25% improvements in customer satisfaction scores by automating back-end processes like ticket categorization and intelligent customer routing.

All of these agents operate within enterprise-grade security, ethics, and compliance frameworks, ensuring that AI-driven decisions remain auditable and aligned with organizational governance standards.

Infrastructure Foundations: Hyperscalers and High Availability

A successful SAP cloud migration requires more than choosing the right SAP path — it requires the right infrastructure foundation. Hyperscalers including AWS, Microsoft Azure, and Google Cloud provide the certified high-memory instances that SAP HANA’s in-memory computing demands for real-time data processing.

Microsoft Azure and RISE with SAP

Azure has become a leading destination for SAP cloud migration, particularly through its deep partnership with SAP under the RISE with SAP on Azure program. Organizations migrating to Azure gain seamless integration with Microsoft 365 Copilot, the ability to run joint AI use cases through SAP AI Core hosted on Azure infrastructure, and access to automated migration tooling through Azure Migrate and Modernize.

Zero-Downtime Standards and Disaster Recovery

For mission-critical SAP environments, the cost of unplanned downtime can reach thousands of dollars per minute. The 2026 standard for production SAP cloud deployments is a zero-downtime architecture, supported by enterprise-grade Backup and Disaster Recovery (BDR) solutions.

Leading BDR providers such as Zerto and Veeam now offer Recovery Point Objectives (RPOs) measured in seconds and Recovery Time Objectives (RTOs) measured in minutes. For ransomware protection, air-gapped immutable storage architectures ensure that backup data cannot be altered or deleted even in the event of a successful cyberattack.

Site Reliability Engineering (SRE) practices further strengthen cloud SAP stability, applying proactive monitoring and automated incident response to maintain performance during traffic peaks and system stress events.

Data Integrity: The Clean Core Foundation

One of the most common failure points in SAP cloud migration is poor data quality in the source system. SAP S/4HANA’s advanced data models and real-time processing capabilities require clean, structured, harmonized information to function as designed.

Industry research from 2025 and 2026 consistently identifies data quality as the number one success factor in migration programs: 76% of successful migrators named “cleansed and harmonized operational data” as their top requirement for project success.

The Clean Core strategy addresses this at two levels. First, data must be profiled, deduplicated, harmonized across regions, and archived before migration begins — ensuring that only high-quality, actionable information moves into the new system. Second, any custom developments that would traditionally be embedded in the ERP core are moved to the SAP Business Technology Platform (BTP), keeping the core clean and upgrade-ready for SAP’s bi-annual release cycle.

Organizations that invest in data governance before go-live consistently experience faster migrations, lower cloud storage costs, and more reliable AI outputs — because AI is only as good as the data it operates on.

A 6-Phase SAP Cloud Migration Roadmap

Successful SAP cloud migration does not happen through improvisation. It follows a structured, multi-phase approach that aligns technical execution with business priorities from day one.

Phase 1 — Readiness Assessment and Discovery: Conduct a thorough inventory of the existing ECC landscape, including all systems, integrations, custom ABAP code, and data dependencies. Define the business value expectations and ROI targets that will drive executive sponsorship.

Phase 2 — Migration Strategy Definition: Based on the assessment findings, select the migration path (Greenfield, Brownfield, or Bluefield), the target cloud model (RISE with SAP, Private Cloud, or Hybrid), and design the cloud architecture including security frameworks and high-availability configurations.

Phase 3 — Business Case and Budget Planning: Build a detailed ROI analysis and Total Cost of Ownership (TCO) model covering five to ten years. Account for software licensing, implementation partner fees, training, change management, and the cost of running parallel systems during transition.

Phase 4 — Data Cleansing and System Preparation: Execute data profiling, deduplication, harmonization, and archiving. Run technical pre-checks for S/4HANA compatibility, remediate custom code, and begin moving extensions to SAP BTP.

Phase 5 — Migration Execution and Testing: Perform data extraction, transformation, and loading in a controlled sequence. Execute rigorous test cycles covering unit testing, integration testing, and user acceptance testing (UAT). Apply zero-downtime techniques wherever feasible.

Phase 6 — Post-Migration Optimization and Support: Stabilize the production environment, tune performance, train users on SAP Fiori interfaces, and activate managed services for ongoing support. Begin deploying advanced AI functionalities and real-time analytics as the core platform matures.

Gart Solutions: Expert-Led SAP Cloud Migration

Navigating this level of complexity requires more than a software vendor and a project plan. It requires a technical partner with hands-on experience across cloud infrastructure, database migration, DevOps automation, and site reliability engineering — capabilities that Gart Solutions has built and validated across real enterprise engagements.

Gart Solutions operates as a specialized DevOps and cloud services provider, with a deep focus on SMBs and scaling enterprises that need enterprise-grade outcomes without enterprise-grade overhead. The Gart approach prioritizes “Quick Wins” — measurable impact delivered early in the engagement rather than theoretical frameworks that take months to produce results.

What Gart Delivers for SAP Cloud Migration

Cloud Migration Consulting: Comprehensive analysis of the existing infrastructure landscape, technology stack selection, and a step-by-step migration plan designed for your specific business context — not a templated playbook.

Infrastructure-Led Transformation: Modernization of legacy platforms into scalable, cloud-native environments using Infrastructure as Code (IaC) tools including Terraform and Kubernetes. This is the foundation that makes cloud SAP environments genuinely resilient and manageable.

Database Migration Expertise: Gart has a proven track record in complex database migrations — including Oracle to PostgreSQL transitions — delivering up to 40% cost reductions and 25% improvements in query performance.

Managed SRE and 24/7 Support: Continuous optimization, proactive monitoring, and automated incident response ensuring 100% system availability even during peak traffic periods.

Documented Client Outcomes

Gart Solutions’ impact is demonstrated through engagements across Europe and the United States:

Retail Cloud Transformation: For a major Eastern European retailer, Gart led a migration from on-premise infrastructure to AWS, re-platforming a legacy monolith into microservices using Kubernetes. The result was significantly reduced hosting costs and dramatically improved scalability for peak retail events.
Cloud Cost Optimization: By leveraging Azure Spot VMs and intelligent resource right-sizing, Gart helped an AI vision company reduce its cloud spend by 81% without compromising performance.
Disaster Recovery at Scale: For Datamaran, a global ESG platform, Gart designed and implemented a disaster recovery architecture that reduced potential downtime from days to minutes — delivering 99.99% uptime for a mission-critical, globally distributed system.
Security and DevOps Transformation: For a construction technology firm, Gart remediated all critical and high-severity security vulnerabilities while simultaneously reducing manual infrastructure management effort and cutting cloud operating costs.

For organizations that lack internal SAP infrastructure expertise, Gart also provides Fractional CTO services — embedding senior technical leadership into the migration program without the cost of a full-time executive hire.

Looking Ahead: SAP Cloud Migration Beyond 2027

As the 2027 deadline passes and the migration wave consolidates, the SAP ecosystem will shift into a phase of hyperautomation and AI-first operations.

By 2030, ERP systems are expected to evolve from transactional databases into genuinely autonomous engines — capable of managing supply chains, financial close processes, and procurement workflows with minimal human intervention. Industry-specific cloud architectures will become mainstream, with pre-configured processes tailored to healthcare, utilities, manufacturing, and financial services. Unified data planes will provide consistent governance across SAP and non-SAP systems, and regulatory compliance will be built directly into ERP workflows — automatically aligning business operations with GDPR, HIPAA, ESG reporting, and future regulations as they emerge.

Organizations that complete their SAP cloud migration in 2026 will enter this future-ready phase with a significant head start. Those that wait will spend their early 2027 resources catching up rather than innovating.

The Time to Act on SAP Cloud Migration Is Now

SAP cloud migration is the most significant transformation most organizations will undertake this decade. It is not a technical project with a start and end date — it is a strategic repositioning that determines whether your organization competes on intelligence and agility, or continues to operate with infrastructure that is aging out of relevance.

The combination of a hard 2027 deadline, a tightening talent market, and the extraordinary AI-native capabilities available in SAP S/4HANA today makes 2026 the definitive window for action. The organizations that move now will secure the resources, the expertise, and the implementation quality needed for a successful outcome. Those that delay will face higher costs, fewer options, and the growing risk of a rushed, under-resourced migration.

Gart Solutions is ready to help you navigate every phase of this journey — from readiness assessment and architecture design to execution, go-live support, and post-migration optimization. With battle-tested methodology, a track record of measurable outcomes, and a team built for the complexity of modern cloud transformation, Gart delivers the technical excellence your SAP migration demands.

Ready to start your SAP cloud migration journey? Contact the Gart Solutions team at gartsolutions.com for a readiness assessment tailored to your organization.

Let’s work together!

See how we can help to overcome your challenges

FAQ

What exactly is SAP cloud migration, and how is it different from a regular software upgrade?

SAP cloud migration is the process of moving your ERP environment from an on-premise SAP ECC system to a cloud-hosted SAP S/4HANA platform. Unlike a conventional software upgrade — which typically updates features within the same architectural model — SAP cloud migration involves a fundamental shift in how your ERP is deployed, managed, and consumed. In practical terms, this means moving from servers you own and maintain to infrastructure managed by SAP or a hyperscaler (AWS, Azure, GCP), replacing capital expenditure hardware cycles with a subscription-based operating expense model, and gaining access to AI-native capabilities that do not exist in ECC. It also involves re-examining business processes, data models, and custom code — many of which have accumulated over 10–20 years and may need to be redesigned or retired.

What is the difference between SAP ECC and SAP S/4HANA?

SAP ECC (ERP Central Component) is SAP's previous-generation ERP platform, built on traditional relational databases and an architecture designed primarily for transactional processing. It has been the backbone of enterprise operations for decades but was not built with cloud, real-time analytics, or AI in mind. SAP S/4HANA is the next-generation ERP, built entirely on SAP's in-memory HANA database. Key differences include: Data processing speed: S/4HANA processes data in-memory, enabling real-time reporting and analytics without separate data warehouses Simplified data model: S/4HANA reduces the number of database tables significantly (from millions in ECC to thousands), improving performance and reducing storage requirements User interface: S/4HANA uses SAP Fiori, a modern, role-based UI that replaces the older SAP GUI AI integration: S/4HANA embeds AI and machine learning directly into core workflows — not as bolt-on tools Deployment: S/4HANA is available as cloud (public and private) or on-premise, while ECC was primarily on-premise

What is "Clean Core" and why does it matter for our migration?

Clean Core is SAP's recommended architectural philosophy for S/4HANA: keep the ERP core free from custom modifications, and build any extensions or custom functionality on the SAP Business Technology Platform (BTP) instead. This matters for several important reasons: Future-proofing: SAP releases bi-annual updates to S/4HANA cloud. Organizations with a clean core can adopt these updates with minimal testing and remediation. Those with a heavily modified core face expensive compatibility testing with every release. AI readiness: SAP's AI features — including Joule agents — are designed to work with standard S/4HANA data models. Heavy customizations that alter these models can prevent AI features from functioning correctly or require expensive workarounds. Reduced TCO: Custom ABAP code requires maintenance, documentation, and regression testing. Every customization in the core is a long-term cost. Moving extensions to BTP isolates this complexity outside the upgrade cycle. Upgrade velocity: Organizations with clean cores can adopt new SAP innovations faster, giving them a sustained competitive advantage over peers still managing legacy modifications. Achieving a clean core often requires difficult conversations about retiring customizations that teams have relied on for years. Change management and stakeholder alignment are as important as the technical work.

What is SAP BTP and how does it fit into cloud migration?

SAP Business Technology Platform (BTP) is SAP's unified cloud platform for application development, integration, data management, and AI services. In the context of SAP cloud migration, BTP serves two critical roles: Extension platform: Instead of modifying S/4HANA's core, custom business logic is built as "side-by-side extensions" on BTP. These extensions integrate with S/4HANA via standard APIs, preserving the clean core while still supporting unique business requirements. Integration hub: BTP's Integration Suite manages connections between S/4HANA and third-party systems — whether legacy applications, partner systems, or non-SAP cloud services. This is particularly important for organizations with complex IT landscapes where S/4HANA is one component among many. BTP is not optional in a well-designed SAP cloud migration. It is the architectural layer that makes clean core achievable in practice.

How do organizations typically fund SAP cloud migration?

The shift from CapEx to OpEx creates both a funding challenge and an opportunity. Common approaches include: OpEx-funded transformation: The RISE with SAP subscription model means ongoing infrastructure and license costs appear as operating expenses. Many organizations use the avoided hardware refresh and maintenance costs to partially fund the migration program. Savings reinvestment: Early automation wins — such as reducing manual finance tasks by 70% — can generate measurable savings within the first year post-go-live. Progressive organizations build these savings into the business case and use them to fund later phases of the program. Phased approach: Rather than migrating everything at once, some organizations prioritize the highest-ROI modules first (typically Finance and Procurement) to generate early returns that fund subsequent phases. CFO alignment: The most successful migrations secure CFO sponsorship by framing migration as a self-funding transformation rather than a cost center project. A well-constructed TCO and ROI model covering five to ten years is essential for this conversation.

How does SAP cloud migration affect our integrations with third-party systems?

Integrations are consistently among the most complex and time-consuming aspects of SAP cloud migration. In a typical ECC environment, there are dozens to hundreds of integration points — with financial systems, HR platforms, customer data tools, logistics providers, and custom-built applications. S/4HANA uses a different, more modern API architecture than ECC. Many legacy integrations built on BAPIs, IDocs, or RFC calls must be re-evaluated and often redesigned using OData APIs or SAP Integration Suite on BTP. A thorough integration inventory during Phase 1 of the migration roadmap is essential. Each integration must be assessed for: Whether the source/target system is still in use and will remain so Whether the integration method is compatible with S/4HANA's API layer Whether the data exchanged aligns with S/4HANA's simplified data model The criticality of the integration to business operations Integration redesign is frequently the item that most significantly extends project timelines in organizations that underinvest in the discovery phase.

What is SAP HANA, and why does the database matter for migration?

SAP HANA is the in-memory database that underpins S/4HANA. Unlike traditional relational databases that store data on disk and retrieve it for processing, HANA stores all operational data in RAM. This architectural difference is what enables S/4HANA's real-time analytics and processing speed. The practical implications for migration are significant: Hardware requirements: HANA requires certified high-memory server instances. On hyperscalers, this means specific VM types (e.g., M-series on Azure, x1e on AWS) that carry a cost premium over standard compute. Data model changes: ECC stored data in aggregated summary tables alongside detail tables. HANA's speed eliminates the need for pre-aggregation, so S/4HANA uses a simplified data model with far fewer tables — which is why migrating data requires transformation, not just copying. Performance tuning: HANA performance is sensitive to memory sizing, table partitioning, and query design. Post-migration performance tuning is a specialized skill that should be factored into partner selection.

How do we handle data security and compliance during migration?

Data security and compliance are non-negotiable dimensions of SAP cloud migration, particularly for organizations subject to GDPR, HIPAA, SOX, or sector-specific regulations. Key considerations include: Data residency: Under RISE with SAP, SAP operates the infrastructure in partnership with hyperscalers. Organizations must verify that their chosen deployment region complies with data residency requirements for their industry and jurisdiction. For EU organizations, this typically means confirming that data remains within EU data centers. Encryption in transit and at rest: All SAP cloud environments support encryption, but organizations should verify that encryption standards meet their internal security policies and regulatory requirements. Access controls: Role-based access control (RBAC) must be redesigned for S/4HANA's Fiori interface and authorization model, which differs from ECC. This is often the trigger for a broader Identity Access Management (IAM) review. Audit trails: S/4HANA provides comprehensive audit logging capabilities. Organizations should ensure that audit configuration meets regulatory requirements before go-live. Data masking during testing: Test environments often use copies of production data. Masking sensitive personal and financial data in non-production environments is both a regulatory requirement and a security best practice.

What should we prioritize immediately after SAP cloud migration go-live?

The 30–90 days following go-live are among the highest-risk and highest-opportunity periods of the entire program. Key priorities include: Hypercare support: Maintain elevated support staffing levels to address issues quickly as users encounter the new system in production conditions for the first time. Performance monitoring: Actively monitor system performance under real production load. HANA database tuning, query optimization, and infrastructure right-sizing are common post-go-live activities. User adoption: SAP Fiori is a significant interface change for teams accustomed to SAP GUI. Structured training, floor-walking support, and access to help resources directly impact how quickly the organization realizes productivity gains. Quick win activation: Post-go-live is the right time to activate pre-planned automation improvements — such as automated payment processing, real-time financial reporting, or AI-assisted procurement — that demonstrate immediate business value to stakeholders. Hyperscaler cost governance: Cloud costs can spike unexpectedly in the weeks following go-live as the system operates under real production load for the first time. FinOps monitoring should be active from day one.

Cloud

20 Cloud Costs Optimization Traps: How to Reduce Cloud Waste?

Roman Burdiuzha

October 6, 2025

Organizations often expect to cut costs when migrating IT infrastructure from on-premises setups to the cloud. However, the reality can be starkly different. Various cost traps can emerge during cloud transformation, leading to unexpectedly high expenses if not carefully managed. In this article, we will explore the most common cloud cost traps and provide strategies to avoid cloud expenditures during cloud transformation. Estimating Cloud Transformation Expenses Forecasting expenses during a cloud transformation can be challenging. In traditional IT setups, cost estimation is relatively straightforward, encompassing fixed costs such as data center rent, hardware, and licenses. Conversely, in a cloud environment, you pay based on usage, which can fluctuate greatly, complicating cost predictions. This variability often leads to unforeseen cost spikes during cloud transformation. At Gart Solutions, we help numerous organizations navigate their cloud transformation journeys and frequently encounter five key mistakes that can drive up costs. Common Cloud Costs Optimization Traps Happening There: 1. The "Lift and Shift" Approach A common mistake is migrating existing setups to the cloud without modifications, known as a "lift and shift." This method usually leads to high costs because it fails to leverage the cloud's unique advantages. Instead, organizations should modernize their solutions through "refactoring." Refactoring involves changing or completely replacing applications or systems to exploit the cloud's benefits such as scalability, elasticity, self-service, and measurability. By optimizing resources for the cloud, organizations can achieve greater flexibility, efficiency, and cost savings. 2. Choosing the Wrong IT Architecture Setup Selecting the right architecture for a cloud environment is critical. IT architecture must be carefully planned to maximize cloud benefits. Determining how services interact and which ones to use requires an architecture tailored to the organization’s needs. Poor architectural choices can result in an environment that does not meet security and scalability requirements, leading to costly adjustments. Hence, it's vital to seek expert advice, critically review recommendations, and explore alternatives that do not compromise functionality or performance. Contact Gart & get the IT Infrastructure Consulting. Quick and long-term wins are guaranteed. 3. Overreliance on Enterprise Versions Organizations often default to enterprise versions of cloud services without assessing their actual needs. This can result in unnecessarily high costs. Before opting for enterprise versions, it's crucial to evaluate if standard versions can meet the requirements. Contact Gart & assess cloud services carefully. 4. Uncontrolled Capacity Planning Accurately predicting capacity needs is a common challenge, where previous expertise is needed. Capacity requirements can vary — constant for some, linear for others, exponential for a third, and seasonal for a fourth. These variations can lead to over- or under-provisioning of resources, resulting in additional costs. Effective capacity planning involves basic estimates and continuous monitoring to detect changes in needs and adjust resources accordingly. Utilizing the built-in capabilities of cloud services for business alignment requires the right expertise. Contact Gart to assess your resources and requirements and make optimal capacity planning. 5. Lack of Appropriate Skills Cloud transformation increases IT delivery complexity and requires new skills. Without the right expertise, projects can become inefficient, leading to wrong decisions and increased costs. Contact Gart - we are the trusted partner in cloud consulting, migration, and cost optimization. 6. Underestimating Data Transfer Costs One often overlooked cost trap is data transfer. While moving data to the cloud might seem straightforward, the costs associated with data egress (data leaving the cloud) can be substantial. Organizations should be aware of these charges and plan data transfer strategies accordingly, such as optimizing data placement and minimizing data transfer needs. 7. Neglecting Long-term Cost Implications Focusing solely on immediate cost savings can lead to higher long-term expenses. Organizations should consider the long-term implications of their cloud choices, including potential costs associated with scaling, maintenance, and upgrades. A comprehensive cost-benefit analysis that includes future scenarios can help in making more informed decisions. 8. Ignoring Security and Compliance Costs Security and compliance are critical in cloud environments, and neglecting these aspects can lead to significant expenses. Ensuring that cloud deployments comply with regulatory standards and implementing robust security measures can prevent costly breaches and fines. Investing in security tools and expertise upfront is crucial for avoiding unexpected costs later. Contact for consulting in security, architecture, and cloud technologies. Prevent unnecessary expenses and ensure a smooth transition. 9. Failing to Monitor and Optimize Usage Continuous monitoring and optimization of cloud usage are essential for controlling costs. Without proper monitoring, organizations can easily overspend on unnecessary resources. Utilizing cloud management tools and implementing policies for regular audits and optimizations can help keep costs in check. 10. Overlooking Vendor Lock-in Risks Vendor lock-in occurs when an organization becomes overly dependent on a single cloud provider, making it difficult and costly to switch providers. To mitigate this risk, organizations should adopt a multi-cloud strategy or ensure that their architecture allows for flexibility and portability across different cloud platforms. 11. Underutilizing Reserved Instances and Savings Plans Cloud providers offer reserved instances and savings plans that can significantly reduce costs for predictable workloads. However, many organizations fail to take advantage of these options. By analyzing usage patterns and committing to long-term plans, organizations can achieve substantial savings compared to on-demand pricing. 12. Over-Provisioning Resources Over-provisioning, or allocating more resources than needed, is a common cost trap. This often results from a lack of understanding of actual usage requirements. Implementing auto-scaling and right-sizing strategies can help in dynamically adjusting resources based on real-time demand, thus avoiding unnecessary expenses. 13. Lack of Governance and Policies Effective governance and policies are crucial for managing cloud costs. Without proper governance, organizations can face uncontrolled spending and resource mismanagement. Establishing clear policies for resource usage, cost allocation, and accountability ensures that cloud resources are used efficiently, and costs are kept under control. 14. Neglecting to Decommission Unused Resources Failing to decommission unused or idle resources can lead to wasted spending. Regularly reviewing and cleaning up unused instances, storage, and other resources can help in reducing unnecessary costs. Automation tools can assist in identifying and decommissioning these resources. 15. Ignoring Cloud Cost Management Tools Most cloud providers offer cost management and optimization tools, but organizations often overlook these valuable resources. Utilizing these tools can provide insights into spending patterns, help identify cost-saving opportunities, and enable more effective budgeting and forecasting. 16. Misjudging Data Storage Costs Data storage costs can add up quickly, especially if organizations do not manage their data efficiently. Implementing data lifecycle policies, such as archiving old data and deleting redundant data, can help control storage costs. Additionally, selecting the appropriate storage class based on access frequency and performance needs is essential. 17. Overlooking Software Licensing Costs Cloud transformation can sometimes lead to increased software licensing costs, particularly if organizations do not review their licensing agreements carefully. It's important to understand the licensing implications of moving to the cloud and to negotiate contracts that align with cloud usage patterns. 18. Inadequate Backup and Disaster Recovery Planning Backup and disaster recovery are critical components of cloud strategy, but inadequate planning in these areas can lead to unexpected costs. Organizations should ensure that their backup and recovery plans are cost-effective and align with their overall cloud strategy. This includes selecting the right tools and services for efficient data protection and recovery. 19. Failing to Leverage Cloud Provider Discounts Cloud providers often offer discounts for committed usage, volume purchases, and other incentives. Failing to leverage these discounts can result in higher costs. Organizations should actively seek out and take advantage of available discounts to optimize their cloud spending. Contact Gart and calculate cloud discounts for your case. 20. Not Considering Hidden Costs Hidden costs, such as those related to network latency, data retrieval, and specialized support, can significantly impact the overall cloud budget. Organizations should thoroughly assess all potential costs, including those that may not be immediately apparent, to avoid budget surprises. Final words Cloud transformation requires specialized expertise & careful planning. Contact us to address all organizational needs for a successful cloud transformation. Gart Solutions can help your organization avoid common cost traps and achieve business objectives efficiently. Review our latest Case Studies of our cloud migration & cost optimization projects.

Kubernetes

8 Gotchas Developers Encounter During Kubernetes Migration

Roman Burdiuzha

April 1, 2025

Kubernetes is becoming the standard for development, while the entry barrier remains quite high. We've compiled a list of recommendations for application developers who are migrating their apps to the orchestrator. Knowing the listed points will help you avoid potential problems and not create limitations where Kubernetes has advantages. Kubernetes Migration. Who is this text for? It's for developers who don't have DevOps expertise in their team – no full-time specialists. They want to move to Kubernetes because the future belongs to microservices, and Kubernetes is the best solution for container orchestration and accelerating development through code delivery automation to environments. At the same time, they may have locally run something in Docker but haven't developed anything for Kubernetes yet. Such a team can outsource Kubernetes support – hire a contractor company, an individual specialist, or, for example, use the relevant services of an IT infrastructure provider. For instance, Gart Solutions offers DevOps as a Service – a service where the company's experienced DevOps specialists will take on any infrastructure project under full or partial supervision: they'll move your applications to Kubernetes, implement DevOps practices, and accelerate your time-to-market. Regardless, there are nuances that developers should be aware of at the architecture planning and development stage – before the project falls into the hands of DevOps specialists (and they force you to modify the code to work in the cluster). We highlight these nuances in the text. The text will be useful for those who are writing code from scratch and planning to run it in Kubernetes, as well as for those who already have a ready application that needs to be migrated to Kubernetes. In the latter case, you can go through the list and understand where you should check if your code meets the orchestrator's requirements. The Basics At the start, make sure you're familiar with the "golden" standard The Twelve-Factor App. This is a public guide describing the architectural principles of modern web applications. Most likely, you're already applying some of the points. Check how well your application adheres to these development standards. The Twelve-Factor App Codebase: One codebase, tracked in a version control system, serves all deployments. Dependencies: Explicitly declare and isolate dependencies. Configuration: Store configuration in the environment - don't embed in code. Backing Services: Treat backing services as attached resources. Build, Release, Run: Strictly separate the build, release, and run stages. Processes: Run the application as one or more stateless processes. Port Binding: Expose services through port binding. Concurrency: Scale the application by adding processes. Disposability: Maximize reliability with fast startup and graceful shutdown. Dev/Prod Parity: Keep development, staging, and production environments as similar as possible. Logs: Treat logs as event streams. Admin Processes: Run administrative tasks as one-off processes. Now let's move on to the highlighted recommendations and nuances. Prefer Stateless Applications Why? Implementing fault tolerance for stateful applications will require significantly more effort and expertise. Normal behavior for Kubernetes is to shut down and restart nodes. This happens during auto-healing when a node stops responding and is recreated, or during auto-scaling down (e.g., some nodes are no longer loaded, and the orchestrator excludes them to save resources). Since nodes and pods in Kubernetes can be dynamically removed and recreated, the application should be ready for this. It should not write any data that needs to be preserved to the container it is running in. What to do? You need to organize the application so that data is written to databases, files to S3 storage, and, say, cache to Redis or Memcache. By having the application store data "on the side," we significantly facilitate cluster scaling under load when additional nodes need to be added, and replication. In a stateful application where data is stored in an attached Volume (roughly speaking, in a folder next to the application), everything becomes more complicated. When scaling a stateful application, you'll have to order "volumes," ensure they're properly attached and created in the right zone. And what do you do with this "volume" when a replica needs to be removed? Yes, some business applications should be run as stateful. However, in this case, they need to be made more manageable in Kubernetes. You need an Operator, specific agents inside performing the necessary actions... A prime example here is the postgres-operator. All of this is far more labor-intensive than simply throwing the code into a container, specifying five replicas, and watching it all work without additional dancing. Ensure Availability of Endpoints for Application Health Checks Why? We've already noted that Kubernetes itself ensures the application is maintained in the desired state. This includes checking the application's operation, restarting faulty pods, disabling load, restarting on less loaded nodes, terminating pods exceeding the set resource consumption limits. For the cluster to correctly monitor the application's state, you should ensure the availability of endpoints for health checks, the so-called liveness and readiness probes. These are important Kubernetes mechanisms that essentially poke the container with a stick – check the application's viability (whether it's working properly). What to do? The liveness probes mechanism helps determine when it's time to restart the container so the application doesn't get stuck and continues to work. Readiness probes are not so radical: they allow Kubernetes to understand when the container is ready to accept traffic. In case of an unsuccessful check, the pod will simply be excluded from load balancing – no new requests will reach it, but no forced termination will occur. You can use this capability to allow the application to "digest" the incoming stream of requests without pod failure. Once a few readiness checks pass successfully, the replica pod will return to load balancing and start receiving requests again. From the nginx-ingress side, this looks like excluding the replica's address from the upstream. Such checks are a useful Kubernetes feature, but if liveness probes are configured incorrectly, they can harm the application's operation. For example, if you try to deploy an application update that fails the liveness/readiness checks, it will roll back in the pipeline or lead to performance degradation (in case of correct pod configuration). There are also known cases of cascading pod restarts, when Kubernetes "collapses" one pod after another due to liveness probe failures. You can disable checks as a feature, and you should do so if you don't fully understand their specifics and implications. Otherwise, it's important to specify the necessary endpoints and inform DevOps about them. If you have an HTTP endpoint that can be an exhaustive indicator, you can configure both liveness and readiness probes to work with it. By using the same endpoint, make sure your pod will be restarted if this endpoint cannot return a correct response. Aim for More Predictable and Uniform Application Resource Consumption Why? Almost always, containers inside Kubernetes pods are resource-limited within certain (sometimes quite small) values. Scaling in the cluster happens horizontally by increasing the number of replicas, not the size of a single replica. In Kubernetes, we deal with memory limits and CPU limits. Mistakes in CPU limits can lead to throttling, exhausting the available CPU time allotted to the container. And if we promise more memory than is available, as the load increases and hits the ceiling, Kubernetes will start evicting the lowest priority pods from the node. Of course, limits are configurable. You can always find a value at which Kubernetes won't "kill" pods due to memory constraints, but nevertheless, more predictable resource consumption by the application is a best practice. The more uniform the application's consumption, the tighter you can schedule the load. What to do Evaluate your application: estimate approximately how many requests it processes, how much memory it occupies. How many pods need to be run for the load to be evenly distributed among them? A situation where one pod consistently consumes more than the others is unfavorable for the user. Such a pod will be constantly restarted by Kubernetes, jeopardizing the application's fault-tolerant operation. Expanding resource limits for potential peak loads is also not an option. In that case, resources will remain idle whenever there is no load, wasting money. In parallel with setting limits, it's important to monitor pod metrics. This could be kube-Prometheus-Stack, VictoriaMetrics, or at least Metrics Server (more suitable for very basic scaling; in its console, you can view stats from kubelet—how much pods are consuming). Monitoring will help identify problem areas in production and reconsider the resource distribution logic. There is a rather specific nuance regarding CPU time that Kubernetes application developers should keep in mind to avoid deployment issues and having to rewrite code to meet SRE requirements. Let's say a container is allocated 500 milli-CPUs—roughly 0.5 CPU time of a single core over 100 ms of real time. Simplified, if the application utilizes CPU time in several continuous threads (let's say four) and "eats up" all 500 milli-CPUs in 25 ms, it will be frozen by the system for the remaining 75 ms until the next quota period. Staging databases run in Kubernetes with small limits exemplify this behavior: under load, queries that would normally take 5 ms plummet to 100 ms. If the response graphs show load continuously increasing and then latency spiking, you've likely encountered this nuance. Address resource management—give more resources to replicas or increase the number of replicas to reduce load on each one. Get a sample of IT Audit Sign up now Get on email Loading... Thank you! You have successfully joined our subscriber list. Leverage Kubernetes ConfigMaps, Secrets, and Environment Variables Kubernetes has several objects that can greatly simplify life for developers. Study them to save yourself time in the future. ConfigMaps are Kubernetes objects used to store non-confidential data as key-value pairs. Pods can use them as environment variables or as configuration files in volumes. For example, you're developing an application that can run locally (for direct development) and, say, in the cloud. You create an environment variable for your app—e.g., DATABASE_HOST—which the app will use to connect to the database. You set this variable locally to localhost. But when running the app in the cloud, you need to specify a different value—say, the hostname of an external database. Environment variables allow using the same Docker image for both local use and cloud deployment. No need to rebuild the image for each individual parameter. Since the parameter is dynamic and can change, you can specify it via an environment variable. The same applies to application config files. These files store certain settings for the app to function correctly. Usually, when building a Docker image, you specify a default config or a config file to load into Docker. Different environments (dev, prod, test, etc.) require different settings that sometimes need to be changed, for testing, for example. Instead of building separate Docker images for each environment and config, you can mount config files into Docker when starting the pod. The app will then pick up the specified configuration files, and you'll use one Docker image for the pods. Typically, iftheconfig files are large,youuse a Volume to mount them into Docker as files. If the config files contain short values, environment variables are more convenient. It all depends on yourapplication's requirements. Another useful Kubernetes abstraction is Secrets. Secrets are similar to ConfigMaps but are meant for storing confidential data—passwords, tokens, keys, etc. Using Secrets means you don't need to include secret data in your application code. They can be created independently of the pods that use them, reducing the risk of data exposure. Secrets can be used as files in volumes mounted in one or multiple pod containers. They can also serve as environment variables for containers. Disclaimer: In this point, we're only describing out-of-the-box Kubernetes functionality. We're not covering more specialized solutions for working with secrets, such as Vault. Knowing about these Kubernetes features, a developer won't need to rebuild the entire container if something changes in the prepared configuration, for example, a password change. Ensure Graceful Container Shutdown with SIGTERM Why? There are situations where Kubernetes "kills" an application before it has a chance to release resources. This is not an ideal scenario. It's better if the application can respond to incoming requests without accepting new ones, complete a transaction, or save data to a database before shutting down. What to Do A successful practice here is for the application to handle the SIGTERM signal. When a container is being terminated, the PID 1 process first receives the SIGTERM signal, and then the application is given some time for graceful termination (the default is 30 seconds). Subsequently, if the container has not terminated itself, it receives SIGKILL—the forced termination signal. The application should not continue accepting connections after receiving SIGTERM. Many frameworks (e.g., Django) can handle this out of the box. Your application may already handle SIGTERM appropriately. Ensure that this is the case. Here are a few more important points: The Application Should Not Depend on Which Pod a Request Goes To When moving an application to Kubernetes, we expectedly encounter auto-scaling—you may have migrated for this very reason. Depending on the load, the orchestrator adds or removes application replicas. The application mustn't depend on which pod a client request goes to, for example, static pods. Either the state needs to be synchronized to provide an identical response from any pod, or your backend should be able to work across multiple replicas without corrupting data. Your Application Should Be Behind a Reverse Proxy and Serve Links Over HTTPS Kubernetes has the Ingress entity, which essentially provides a reverse proxy for the application, typically an nginx with cluster automation. For the application, it's enough to work over HTTP and understand that the external link will be over HTTPS. Remember that in Kubernetes, the application is behind a reverse proxy, not directly exposed to the internet, and links should be served over HTTPS. When the application returns an HTTP link, Ingress rewrites it to HTTPS, which can lead to looping and a redirect error. Usually, you can avoid such a conflict by simply toggling a parameter in the library you're using, checking that the application is behind a reverse proxy. But if you're writing an application from scratch, it's important to remember how Ingress works as a reverse proxy. Leave SSL Certificate Management to Kubernetes Developers don't need to think about how to "hook up" certificate addition in Kubernetes. Reinventing the wheel here is unnecessary and even harmful. For this, a separate service is typically used in the orchestrator — cert-manager, which can be additionally installed. The Ingress Controller in Kubernetes allows using SSL certificates for TLS traffic termination. You can use both Let's Encrypt and pre-issued certificates. If needed, you can create a special secret for storing issued SSL certificates.

Cloud

Catalysts for Cloud Migration: Why Your Business Should Make the Move

Roman Burdiuzha

December 28, 2023

Moving to the cloud demands significant investment, effort, and time due to its costliness and labor-intensive nature. In other words, it demands extra finances. At the same time, for many technical specialists, the language of business sounds like a foreign one, complicating communication between the development team and the financial department of your company. That's why any successful transformation always starts with clearly defined business results that are understandable to all participants in the process. So, what advantages does cloud migration bring to the business? [lwptoc] Cost Savings When it comes to the benefits of migrating to the cloud, the first thing that comes to mind is the financial aspect. This is the most straightforward business outcome for many business owners, although not the only one. In simple terms, the financial motives for cloud migration boil down to: Increasing revenue. Reducing expenses. How does this play out in practice? Cloud computing can reduce costs related to hardware and software, data center setup, and its operation. Expenses for servers, continuous power for operation and cooling, as well as IT specialists to manage the infrastructure, can quickly add up. Closing a data center is often referred to as "getting out of the datacenter business." Additionally, you avoid expenses for software updates and purchasing new equipment. The cloud can create opportunities for offering new products to customers or delivering existing products in a new way. For example, a regular fitness center introduces online workouts accessible through a subscription-based mobile app. Users can join live sessions or access a library of recorded workouts, creating a new stream of revenue beyond the traditional gym visit. Cloud migration can also increase revenue from existing customers. For instance, an e-commerce company enhances its customer experience by implementing a cloud-based recommendation mechanism. By analyzing customer behavior and preferences, the platform provides personalized product recommendations, leading to increased sales and profit growth. Elevate Your Business with Our Cloud Consulting Expertise. Unlock Efficiency, Security, and Innovation – Consult with Us Today!! Flexibility Quickly adapting to market changes can help a business retain existing customers or gain market share from competitors. Cloud technologies can significantly speed up product development. For example, Azure DevOps offers engineers a set of tools to accelerate: Azure Repos for managing code versions, Azure Test Plans for automated testing of ready solutions, Azure Pipelines for deploying software for applications in different environments. Reducing time-to-market can motivate a manager to allocate budget for IT transformation. Changes in the operational needs of a company often create a demand for new IT services or the scaling of existing services. Purchasing and installing new hardware and virtual resources can take weeks. After migrating to the cloud, the IT team can set up the necessary resources in a matter of hours. Globalization The modern world is global, meaning a large portion of businesses has the potential to enter international markets. Cloud technologies noticeably simplify this process. Cloud solutions shift the costs of globalization to the cloud provider. Companies can quickly deploy resources in the same region as their customers without the need to purchase and maintain local data centers. For instance, today, an online store selling products worldwide and interacting with customers in different time zones and languages is not uncommon. In practice, the store can use Azure Bot Service and various features in Azure Cognitive Services, including Translator, Language Understanding (LUIS), QnA Maker, and Text Analytics. This ensures that their customers can get information when they need it, and it will be provided in their language. Furthermore, cloud computing allow managing the product assortment displayed on the store's pages, adapting it to geographic tastes, preferences, and the current availability of products. Operating in global markets imposes additional constraints on businesses due to regulatory aspects, especially in industries like fintech or healthcare. Cloud technologies offer compliance solutions that help clients adhere to regulatory requirements in regulated sectors and global markets. In other words, cloud providers ensure secure storage and processing of confidential data. For example, let's consider an American healthcare service provider that has secured a contract in Europe. European legislation requires their data to remain in each specific country in Europe. Therefore, the American company deploys its software using fully scripted DevOps processes. Productivity In our world, it is taken as a given that applications work quickly and without glitches. If such expectations are suddenly not met, it can significantly damage the company's reputation. Cloud technologies simplify backup and disaster recovery since data can be mirrored on multiple backup sites within the cloud provider's network. One of the most crucial functions of IT is ensuring that corporate data is never lost, and applications remain accessible despite server failures, power outages, or natural disasters. You can protect your data and ensure the possibility of recovery by creating a backup in the cloud. Carbon Footprint Today, it is crucial to build a responsible business that cares for the environment. Cloud computing can help your organization reduce carbon emissions, use resources more efficiently, and minimize environmental impact. Statistics show that migrating to the cloud reduces carbon dioxide emissions into the ecosystem by 98%. If you doubt the importance of this point, consider government initiatives: The UK government aims to achieve net-zero greenhouse gas emissions by 2050. The US government plans to achieve net-zero emissions by 2050. The European Climate Law aims to reduce greenhouse gas emissions by 55% by 2030. The European Union's goal is to achieve net-zero emissions by 2050. Of course, these are not the only business drivers that should motivate you to migrate to the cloud. However, I hope you have already made the decision that is right for you.

Why 2026 Is the Critical Window for SAP Cloud Migration

The Business Case in Numbers

Choosing the Right SAP Cloud Migration Path

Greenfield: Build Clean, Start Fresh

Brownfield: Convert What You Have

Bluefield: The Strategic Hybrid

Understanding RISE with SAP: A New Commercial Model

AI-Native Capabilities: What SAP Cloud Migration Unlocks

Joule: SAP’s AI Copilot

Autonomous AI Agents Across Business Functions

Infrastructure Foundations: Hyperscalers and High Availability

Microsoft Azure and RISE with SAP

Zero-Downtime Standards and Disaster Recovery

Data Integrity: The Clean Core Foundation

A 6-Phase SAP Cloud Migration Roadmap

Gart Solutions: Expert-Led SAP Cloud Migration

What Gart Delivers for SAP Cloud Migration

Documented Client Outcomes

Looking Ahead: SAP Cloud Migration Beyond 2027

The Time to Act on SAP Cloud Migration Is Now

FAQ

What exactly is SAP cloud migration, and how is it different from a regular software upgrade?

What is the difference between SAP ECC and SAP S/4HANA?

What is "Clean Core" and why does it matter for our migration?

What is SAP BTP and how does it fit into cloud migration?

How do organizations typically fund SAP cloud migration?

How does SAP cloud migration affect our integrations with third-party systems?

What is SAP HANA, and why does the database matter for migration?

How do we handle data security and compliance during migration?

What should we prioritize immediately after SAP cloud migration go-live?

You might also like

20 Cloud Costs Optimization Traps: How to Reduce Cloud Waste?

8 Gotchas Developers Encounter During Kubernetes Migration

Catalysts for Cloud Migration: Why Your Business Should Make the Move

Subscribe to our blog