|
Key Takeaways
|
- Don’t swap your orchestration engine while performing a high-stakes SAP "heart transplant.
- AutoSys remains fully compatible with S/4HANA and RISE through minimal architectural adjustments.
- Keep your enterprise connected by leveraging proven integrations instead of creating new silos.
|
Don’t swap the engine while you’re changing the tires
If you are like most of the customers I speak with these days, the migration to SAP S/4HANA is currently the "sun" around which your IT department orbits. It is a massive gravitational force, consuming the lion’s share of budget and focus, leaving little time for other efforts.
Whether you are moving on-premises or transitioning to RISE with SAP, you are fundamentally altering your ERP landscape. In the midst of this transformation, you may hear noise from niche, SAP-centric competitors suggesting that this is also the time to "modernize" (read: replace) your enterprise scheduler.
Let me be the voice of architectural reason: Do not add unnecessary risk to what is already a time-critical, high-stakes endeavor.
Migrating to S/4HANA is complex enough. Ripping out the orchestration layer that manages your end-to-end business processes—financial closes that span from the wider enterprise to SAP, supply chain logistics, and multi-cloud data warehousing dependencies—is not the fast path to “modernization.” It is a sure-fire way to introduce operational risk, disruption, and hidden costs to your migration.
The good news? AutoSys is already S/4HANA ready.
For the vast majority of our customers, the orchestration move to S/4HANA is a highly manageable transition. You want to get to the new platform with the least amount of friction possible. Here is exactly what that looks like from an AutoSys perspective.
Scenario 1: S/4HANA on-premises (business as usual)
If you are upgrading to S/4HANA on-premises (or hosting it yourself in a public cloud IaaS) and maintain control of your operating systems, the "migration" for AutoSys is virtually non-existent.
-
The agent: Your AutoSys SAP Agent stays exactly where it is. (If it is already sitting on an adjacent server, it remains there).
-
The change: You will likely need to upgrade to the latest SAP Java Connector (JCo) and update your connection strings to point to the new S/4HANA hostnames and ports.
-
The result: Your existing Job Information Language (JIL) code, dependencies, and calendars continue to work. No rewriting. No re-testing of logic.
Scenario 2: RISE with SAP (The Move to Cloud)
Moving to RISE with SAP (Private Cloud Edition) introduces a modernized, strictly governed security model. To protect the integrity and maintainability of this managed service, SAP limits access when these agents are installed within the ECS landscape-- which can complicate support boundaries and OS-level interactions.
Our platform's flexible architecture means you do not have to wait, and you do not need to replace your enterprise scheduler. You can adopt a modern, "outside-in" architecture right now, which perfectly aligns with SAP's own best practices for maintaining a clean core while retaining absolute operational control.
Here is Broadcom’s architectural guidance for RISE with SAP:
1. Agent placement (The "Outside-In" Approach):
If your agent previously sat directly on the legacy SAP box, you will simply deploy the AutoSys SAP Agent to your own infrastructure (for example, an adjacent VM or "jump host" within your cloud environment). From there, it connects seamlessly and securely to S/4HANA via SAP’s certified RFC/XBP interfaces. The control and visibility remain exactly the same; only the agent's footprint changes. By decoupling the agent from the SAP OS, you are inherently keeping the SAP core clean.
2. File transfers:
Because the agent isn't local to the SAP server in this architecture, you cannot perform direct file creates/moves on the SAP OS level. Here are the modern pivot options:
-
Option 1: ECS-Managed Storage: If permitted, you can simply mount the ECS-managed storage directly to your network, allowing your existing file transfer processes and jobs to run exactly as they always have with zero disruption. Alternatively, you can utilize SFTP to securely exchange files via specific directories exposed through SAP Transaction AL11 or route them through an S3 bucket.
-
Option 2: Customer-Managed Storage: Alternatively, a customer-managed filestore provides a neutral integration layer that accommodates both SAP and the third-party software requiring data access. In this "wait-and-trigger" architecture, the storage acts as a stable landing zone where process synchronization is key: SAP monitors shared directories via AL11 to initiate ingestion only after a file has completely arrived, while third-party tools similarly wait for SAP to fully release an export before beginning their next process.
The logic of when the job runs and what it triggers downstream remains completely untouched.
Summary: Enterprise Orchestration over SAP Silos
Beware the "modernization" mirage pitched by niche scheduling tools. Your business processes do not live in an SAP silo. SAP is the heart of your enterprise, but AutoSys is the central nervous system connecting SAP to the wider enterprise, the data warehouses (like Snowflake), and your multi-cloud applications.
Breaking that enterprise-wide nervous system during a heart transplant is not a strategy I would recommend.
We have the tools, the API integrations, and the architectural blueprints to get you to S/4HANA and RISE without the drama.
Call to action
If you are planning your migration and have specific questions about agent placement for RISE or cloud storage integration (S3, GCS, Azure Blob), here’s how you can learn more:
-
Join any AutoSys Office Hours: Bring your questions directly to our engineering team.
-
Reach out: Contact your technical account team or sales representative. We have detailed migration guides ready for you.
Stay stable. Stay integrated.
