Moving SAP to the cloud modernises infrastructure, but often exposes critical processes
Moving SAP ERP to the Cloud is Only Half the Job
Written by Independent Journalist Pat Brans
Featuring expert input from Martin Hulbert, CTO, Ignite Technology.
Moving SAP to the cloud modernises infrastructure, but without enterprise orchestration, it often leaves critical business processes exposed.
The most successful SAP cloud programmes share one principle: keep it simple. That means avoiding unnecessary redesign during migration and focusing first on keeping existing business processes running reliably while the underlying platform changes.
For many organisations, the decision to move SAP ERP from on-prem infrastructure to the cloud, whether through S/4HANA, RISE with SAP, or a hybrid of both, is framed as a destination. In practice, it’s a transition point rather than an endpoint.
“For many organisations, the decision to move SAP ERP from on-prem to the cloud is framed as a destination – in practice, it’s a transition point.”
The migration itself usually succeeds. SAP runs. Performance is acceptable. Infrastructure concerns diminish. But what often emerges once the dust settles is a different problem: the operating model that supported SAP for years no longer fits the reality of a distributed, cloud-based environment.
SAP Cloud ERP is not broken. But it’s also not designed to act as an enterprise-wide control plane. As SAP landscapes expand to include hyperscalers, SAP BTP services, SaaS platforms, legacy systems, and regional deployments, organisations begin to see the gaps, particularly in automation, orchestration, and visibility.
This is usually when the conversation changes. It shifts from “how do we run SAP in the cloud?” to “how do we run the business reliably now that SAP is in the cloud?” That shift is where Ignite Technology typically becomes involved.
Why Enterprise Orchestration Becomes Critical in the Cloud
Most SAP cloud programmes start with sensible objectives: reduce infrastructure overheads, modernise platforms, and prepare for long-term innovation. What’s often underestimated is the operational friction that appears once systems go live.
In traditional on-prem SAP environments, organisations accumulate years of automation logic. Custom schedulers, cron jobs, shell scripts, and manual interventions are layered on top of one another to keep critical processes running. Many of these mechanisms depended on direct system access, predictable infrastructure behaviour, and tightly coupled execution paths.
When SAP moves to the cloud, that model no longer holds. Database access is restricted. Infrastructure is abstracted behind APIs. Execution timing becomes less deterministic. Processes that once ran reliably suddenly become fragile, and teams often reintroduce manual steps simply to keep things moving.
“Processes that once ran reliably suddenly become fragile, and teams often reintroduce manual steps simply to keep things moving”
SAP’s native scheduling capabilities were never designed to coordinate complex, cross-system business processes with predictive awareness and enterprise-wide governance. They operate inside SAP, not across the wider landscape. As a result, organisations end up with fragmented automation that works locally but fails globally.
One architectural reality becomes clear very quickly in SAP cloud programmes: SAP is rarely alone. In a typical post-migration environment, SAP Cloud ERP sits at the centre, supported by SAP BTP services and hosted on hyperscaler infrastructure. Around it remain legacy on-prem systems, regional SAP instances, data platforms, SaaS applications such as CRM or supply-chain tools, and external partner integrations. Each of these systems continues to execute part of the overall business process, often owned by different teams with different priorities and tooling.
“One architectural reality becomes clear very quickly in SAP cloud programmes: SAP is rarely alone.”
Native SAP workflows do not see beyond SAP’s boundaries. As a result, dependencies that stretch across systems, financial close, data pipelines, supply chain execution, reporting, and payments, are managed through a mixture of time-based scheduling, manual coordination, and brittle integration logic.
From an architectural standpoint, what’s missing is a layer that understands process flow end to end. Not just which job runs next, but which business outcome depends on which upstream conditions, across multiple platforms.
“From an architectural standpoint, what’s missing is a layer that understands process flow end to end.”
This is where Broadcom Automic Automation fits into the architecture. Automic operates above SAP rather than inside it, and critically, it can orchestrate and synchronise processes that span legacy on-prem SAP and SAP Cloud ERP, allowing organisations to keep end-to-end operations running smoothly as workloads transition between the two. Architecturally, it functions as an enterprise orchestration layer that connects SAP Cloud ERP, SAP BTP services, hyperscaler resources, on-prem systems, SaaS platforms, and infrastructure services into a single execution model.
“Instead of relying on fixed schedules, Automic uses event-driven logic.”
Instead of relying on fixed schedules, Automic uses event-driven logic. Workflows are triggered by real conditions, file arrivals, API responses, job completion states, or business events, rather than arbitrary time slots. This allows processes to move as soon as prerequisites are met, eliminating unnecessary waiting and reducing end-to-end cycle times.
More importantly, Automic understands dependencies. It knows which upstream activities must complete before downstream processes can safely begin. It tracks execution history, understands typical runtimes, and can predict when SLAs are at risk. When delays occur, it does not simply raise an alert; it can adjust dependent workflows and surface the business impact before failures cascade.
“In cloud environments, where direct system access is restricted and API-based integration is the norm, this architectural role becomes essential.”
In cloud environments, where direct system access is restricted and API-based integration is the norm, this architectural role becomes essential. Automic is designed to operate in this API-driven model, allowing organisations to modernise automation without rewriting everything at once. Legacy scripts and schedulers can be absorbed into governed workflows and progressively refactored into reusable, policy-driven automation.
From a CTO perspective, one of the most valuable architectural outcomes of enterprise orchestration is visibility. When orchestration is centralised, execution history, audit trails, SLA tracking, and dependency maps all live in one place. SAP teams, operations teams, and business stakeholders gain a shared view of what is happening across the landscape, not just inside SAP, but end to end.
“From a CTO perspective, one of the most valuable architectural outcomes of enterprise orchestration is visibility.”
This is particularly important in regulated industries, where confidence matters as much as speed. Every action is tracked automatically. Organisations can demonstrate not only that processes ran, but that they ran correctly, in the right order, and within defined controls.
The conversation shifts from “did the job run?” to “did the business process complete as expected, and what happens if it doesn’t?”
System Lifecycle Operations: The SAP Copy Challenge
One area where SAP migrations consistently expose inefficiency is system copies and refreshes. For SAP Basis teams, system copies remain one of the most time-consuming and error-prone operational tasks. They are manual, disruptive, and heavily dependent on specialist knowledge. This problem has become more urgent with the announced retirement of SAP Landscape Manager in 2027.
“One area where SAP migrations consistently expose inefficiency is system copies and refreshed.”
Automic SAP Copy addresses this architectural gap by treating system copies as orchestrated workflows rather than isolated technical tasks. Integrated with VMware Cloud Foundation, Automic coordinates infrastructure cloning, SAP pre- and post-processing, and compliance logging as a single automated process.
What once took days or weeks becomes predictable and repeatable. Manual post-processing steps are automated. Risk is reduced. And SAP projects no longer stall while teams wait for scarce Basis resources. Crucially, SAP Copy operates within the same orchestration platform that manages the wider SAP and enterprise landscape, rather than introducing yet another point tool.
System Lifecycle Operations: The SAP Copy Challenge
Technology alone does not solve SAP cloud complexity. Architecture has to be implemented, governed, and evolved. At Ignite Technology, our role is to help customers design and operationalise this orchestration layer as part of their SAP cloud programmes, not as an afterthought. That means identifying which processes truly matter, mapping cross-system dependencies, redesigning automation for event-driven execution, and defining operating models that work in hybrid environments.
Bringing Automic into the programme early allows organisations to modernise automation as part of the migration itself, rather than treating it as an expensive clean-up exercise later. From a CTO perspective, that is the difference between a cloud migration that merely moves systems and one that genuinely improves how the business operates.
“Bringing Automic into the programme early allows organisations to modernise automation as part of the migration itself.”
One of the architectural mistakes I see most often is treating SAP cloud migration as a one-time event rather than the start of continuous change. Once SAP is in the cloud, the environment does not stabilise, it accelerates. New SaaS applications are added, data platforms evolve, regions modernise at different speeds, and business processes are constantly reworked.
“One of the architectural mistakes I see most often is treating SAP cloud migration as a one-time event rather than the start of continuous change.”
From a CTO standpoint, the question is not whether the architecture works on day one, but whether it can absorb change without introducing risk every time something moves. This is where orchestration becomes strategic rather than operational. When dependencies are explicit, when workflows are modelled rather than implied, and when execution logic lives above individual systems, organisations gain the ability to change safely.
Automic supports this by making dependencies visible and testable. Architectural changes can be scenario-planned rather than guessed. Teams can see which processes will be impacted before changes go live, rather than discovering issues after the fact. That capability becomes critical as organisations adopt SAP BTP services, integrate AI-driven processes, or re-platform surrounding systems independently of SAP.
Your Next Steps
In other words, enterprise orchestration is not just about keeping today’s SAP processes running. It’s about creating an architecture that remains resilient as the business continues to evolve.
There is a tendency in enterprise IT to overcomplicate the message. I don’t believe that helps anyone. The value of Automic is straightforward. It automates what must happen, ensures it happens on time, and removes humans from repetitive, error-prone tasks. Architecturally, it provides the control layer that SAP Cloud ERP does not attempt to be.
If you’re moving SAP ERP to the cloud and assuming everything else will take care of itself, it probably will not. If you want SAP Cloud ERP to deliver on its promise of agility and resilience, you need orchestration above SAP.
That’s why customers call Ignite Technology, and why Broadcom Automic remains central to modern SAP operations.
Let’s start the conversation today, contact our team to explore your options and build an automation and orchestration strategy that sets you up for long-term success.
