The systems around SAP, hosted properly in the same cloud.
SAP rarely runs alone. We host the applications around it, such as Odoo, HR systems, integration middleware, file servers, EDI gateways, websites and databases, on AWS, Microsoft Azure or Google Cloud, close to your SAP landscape. They get the same security, backup, monitoring and network design as SAP, instead of living on ageing servers in a back room.
Why the workloads around SAP matter
When SAP moves to RISE with SAP or to cloud infrastructure, the systems that feed it often stay behind: an EDI server talking to customers, a file share used for bank files, an integration server, an HR or payroll system, a company website and a few departmental databases. These are often the least patched and least backed up systems in the estate, and every interface to SAP now crosses a long network path. Moving them to the same cloud and region, on a planned design, cuts latency to SAP, removes hardware risk and puts them under the same controls.
Ageing servers
Many surrounding systems run on hardware and operating systems near end of support. A failure there can stop orders, payroll or bank files reaching SAP.
Interfaces across long links
If SAP is in a cloud region and its interfaces are still on-premises, every call crosses a WAN link. Hosting both in the same region reduces latency and failure points.
Uneven security and backup
Smaller systems often miss patching, MFA and tested backups. Bringing them into a governed landing zone applies the same standards everywhere.
Personal data on scattered servers
HR, CRM and website systems hold personal data. Sri Lanka's Personal Data Protection Act core duties apply from 1 January 2027, and they cover where and how that data is kept.
What we do
We assess, move and run the non-SAP applications that support your business and your SAP landscape.
Odoo hosting
We host Odoo on your own cloud account, on virtual machines or containers with a managed PostgreSQL database, when you need more control than Odoo Online or Odoo.sh. We set up backups, upgrades, monitoring and integration with SAP where both run side by side.
HR and business applications
We host or connect applications such as MIHCM and other line of business systems, using the deployment model the vendor supports. Identity, network and backup follow the same design as the rest of your estate.
Integration middleware
We host integration servers and message queues, or move them to managed services such as SAP Integration Suite, Azure Logic Apps, Amazon SQS or Google Cloud Pub/Sub. Interfaces to SAP are documented and monitored.
EDI and B2B exchange
We set up AS2 and SFTP exchange with trading partners, using AWS Transfer Family with AWS B2B Data Interchange, Azure Logic Apps integration accounts, or your EDI software on cloud VMs. Messages are translated and passed to SAP as IDocs or API calls.
File servers and shares
We replace on-premises file servers with managed SMB and NFS file services joined to your directory. Shares used by SAP interfaces, such as bank or print files, are placed close to the SAP systems.
Websites and databases
We host company websites, portals and departmental databases on managed web, container and database services. Patching, scaling and backups are handled by the platform or by us.
How it works
- 1
Inventory
We list each application, its servers, data, users, interfaces to SAP and vendor support terms. We note which ones hold personal data and their recovery needs.
1 to 2 weeks - 2
Decide the target
For each workload we choose to rehost on VMs, move to a managed service, replace with SaaS or retire. Vendor supported deployment options guide the choice.
1 to 2 weeks - 3
Build the platform
We extend your landing zone with the networks, identity, backup and monitoring these workloads need, in the same region as SAP where it helps. Everything is built as code.
2 to 4 weeks - 4
Migrate in waves
We move workloads in small groups, test interfaces to SAP and with users, then cut over in agreed windows. Old servers stay available until each move is signed off.
2 to 8 weeks per wave - 5
Run
We hand over runbooks or run the workloads under our managed service, with patching, backup checks and monitoring. Costs are reviewed and rightsized after the first months.
Ongoing
Native services for common non-SAP workloads
The managed services we typically use for each type of workload on each cloud.
| Need | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| Virtual machines for packaged apps | Amazon EC2 | Azure Virtual Machines | Compute Engine |
| Managed PostgreSQL, for example Odoo | Amazon RDS for PostgreSQL, Amazon Aurora | Azure Database for PostgreSQL flexible server | Cloud SQL for PostgreSQL, AlloyDB |
| Managed SQL Server | Amazon RDS for SQL Server | Azure SQL Database, Azure SQL Managed Instance | Cloud SQL for SQL Server |
| Windows file shares | Amazon FSx for Windows File Server | Azure Files | Google Cloud NetApp Volumes |
| EDI and B2B exchange | AWS Transfer Family, AWS B2B Data Interchange | Azure Logic Apps with integration account | Partner EDI software on Compute Engine |
| Integration and messaging | Amazon SQS, Amazon EventBridge | Azure Logic Apps, Azure Service Bus | Application Integration, Pub/Sub |
| Websites and containers | AWS Amplify Hosting, Amazon ECS | Azure App Service, Azure Kubernetes Service | Cloud Run, Google Kubernetes Engine |
Keeping the surrounding systems close to SAP
Under RISE with SAP, SAP hosts and runs your SAP Cloud ERP Private systems on the hyperscaler and region you choose, but it does not host your other applications. Placing EDI gateways, file shares, integration servers and databases in your own account on the same hyperscaler and region, connected to RISE by peering, keeps interface traffic short and private. If you run ECC or SAP S/4HANA yourself on cloud, these workloads sit in the same landing zone as SAP. Either way, we design the interfaces: IDocs and RFC for EDI and file based flows, OData and APIs for portals and apps, and SAP Integration Suite where integration should run on SAP BTP. With no hyperscaler region in Sri Lanka, we help you choose a region such as Mumbai, Hyderabad or Singapore that suits both SAP and your other systems.
- Same hyperscaler and region as RISE with SAP or your own SAP systems
- Private peering between your workload network and SAP
- Interfaces documented and monitored end to end, including IDoc and API flows
- Shared identity, backup and security controls across SAP and non-SAP systems
© 2026 Mawkish Technologies. This guide, its diagrams and illustrations are protected by copyright. You’re welcome to learn from it and to quote it with credit and a link. Reproducing it, by hand or through AI, and publishing it as your own is not allowed. Read our copyright notice
Deliverables
- Inventory of non-SAP workloads with a target decision for each
- Landing zone extension for the workloads, built as code
- Migrated workloads with tested interfaces to SAP
- Backup, monitoring and patching set up and verified
- Data protection notes covering where personal data is stored
- Runbooks and an agreed operating model
Frequently asked
Why host Odoo ourselves instead of using Odoo Online?
Odoo offers Odoo Online, Odoo.sh and on-premise deployment. Hosting on your own cloud account suits you when you need custom modules, direct database access, specific data location or close integration with SAP and other systems. We help you choose based on those needs.
Can our EDI run in the cloud?
Yes. AWS Transfer Family supports AS2 and SFTP and works with AWS B2B Data Interchange for X12 translation, and Azure Logic Apps supports AS2, X12 and EDIFACT through integration accounts. If you use a specific EDI product, we can host it on cloud VMs instead.
Does RISE with SAP include hosting for our other applications?
No. RISE with SAP covers SAP's own systems that SAP runs for you. Your other applications need their own hosting, which we set up in your cloud account and connect privately to the RISE environment.
Which region should we use from Sri Lanka?
There is no AWS, Azure or Google Cloud region in Sri Lanka. India regions include Mumbai and Hyderabad on AWS, Pune, Chennai, Mumbai and Hyderabad on Azure, and Mumbai and Delhi on Google Cloud, with Singapore also available. We usually place these workloads in the same region as SAP.
Do we have to move everything at once?
No. We move workloads in waves, starting with those that support SAP interfaces or run on the oldest hardware. Each move is tested and signed off before the old server is switched off.
Often paired with this
Plan your move with people who know SAP.
One working session with our cloud and SAP architects. You leave with the options, the risks and a first plan.
- Your landscape reviewed
- The right cloud and region
- A first roadmap
Sources
- Azure regions list, Microsoft Learn
- AWS B2B Data Interchange supports all X12 transaction sets, AWS
- AWS Transfer Family custom directories for AS2 files, AWS
- Automate B2B messages with Azure Logic Apps, Microsoft Learn
- Odoo source install documentation
- Data protection compliance regime takes effect on 1 Jan 2027, Daily FT
- Google Cloud NetApp Volumes Active Directory integration
- Infrastructure Manager locations incl. Mumbai and Delhi, Google Cloud
- AWS Launch Wizard in Hyderabad Region, AWS
Our Almwyn Brief is the name we give to how we handle Hosting for Non-SAP Workloads: one accountable partner, from the first meeting to long after go-live.
AWS, Microsoft Azure, Google Cloud and SAP are trademarks of their respective owners.