Cross-border E-commerce
UBI CAPITAL
A cross-border e-commerce company migrating its SAP S/4HANA from GCP to AWS, building a highly available and elastic SAP environment.
Project Overview
UBI is a cross-border e-commerce company focused on overseas markets. Its business covers independent site operations, overseas warehouse management and multi-channel sales, serving customers across Europe, America, Southeast Asia and beyond.
UBI relies on the SAP system (S/4HANA) as its core ERP, supporting key operations such as finance, procurement, inventory and order management. The SAP system originally ran on GCP; as the business grew, pain points emerged around global low-latency access, cost control and compliance. UBI decided to migrate SAP from GCP to AWS — leveraging AWS's global infrastructure and SAP-certified instance types to build a highly available and elastic SAP environment.
Industry
Cross-border E-commerce
Services
SAP GCP → AWS Migration
1. Client Introduction
UBI is a cross-border e-commerce company specializing in overseas markets, engaged in independent site operations, overseas warehouse management and multi-channel sales, with its business reaching Europe, America and Southeast Asia. As the business scales rapidly, the company's demands for a core ERP system also grow.
UBI uses SAP S/4HANA as its core ERP, supporting finance, procurement, inventory and order management. To align with the global business layout, the SAP system must provide stable, low-latency services to users in multiple regions, while meeting data compliance requirements in different countries and regions. With business growth, the original architecture on GCP faced several bottlenecks, prompting the decision to migrate to AWS.
2. Project Background
Customer Requirements
- Migrate to AWS: Move the SAP S/4HANA environment from GCP to AWS, building a stable, elastic and cloud-native ERP infrastructure.
- High availability & DR: Ensure the SAP system remains available during hardware failure or region outage, guaranteeing business continuity.
- Cost optimization: Reduce infrastructure cost through elastic scaling and right-sized resource selection while meeting SAP performance requirements.
- Global access: Serve users in multiple regions with low latency, improving the experience for global teams and partners.
Source Architecture (GCP)
Current GCP Architecture Components
Load Balancing
Cloud Load Balancing (global HTTP(S)), providing global access for the SAP front-end and web servers
Application
SAP S/4HANA application server on Compute Engine, spec n2-highmem-16 (16 vCPU / 128GB RAM)
Database
Cloud SQL for PostgreSQL, 8 vCPU / 32GB RAM, total database size ~20 GB
Storage
Cloud Storage (GCS) for backup and archive data
3. Business Requirements
3.1 Core Pain Points
- Cross-region latency: GCP's nodes are concentrated in a few regions, causing poor access for users in Europe and America and affecting daily operations.
- Cost pressure: SAP requires high-memory instances; running them as fixed VMs on GCP leaves little room to optimize the large license and compute bills.
- Insufficient HA: The original single-node deployment lacks a complete HA and DR mechanism, with business-interruption risk during failure.
- Compliance complexity: Cross-border data flows must meet the compliance requirements of different regions, demanding finer-grained permission and audit management.
3.2 Optimization Goals
Goal: Build an SAP S/4HANA environment on AWS around EC2 + EBS, achieving high availability, elastic scaling and global low-latency access, while meeting the security and compliance requirements of cross-border e-commerce.
4. AWS Service Mapping
| AWS Service | Purpose | Priority |
|---|
| Amazon EC2 | SAP-certified instances (e.g. memory-optimized) hosting the SAP S/4HANA application and database tier | P0 |
| Amazon EBS | Block storage for the SAP system, using gp3 for general workloads and io2 for high IOPS | P1 |
| Amazon S3 | Backup and archive storage for SAP data, supporting low-cost long-term retention | P2 |
| Amazon RDS (PostgreSQL) | Replaces Cloud SQL, holding peripheral business data | P1 |
| Elastic Load Balancing | Replaces Cloud Load Balancing, providing L7 load balancing and health checks | P1 |
| Amazon VPC | Network isolation, dividing public and private subnets, controlling access security | P1 |
| Amazon CloudWatch | Monitors EC2, EBS and RDS metrics, supporting alarms and auto-actions | P2 |
| AWS Lambda | Automated orchestration: SAP start/stop, backup scheduling, auto-scaling triggers | P2 |
| Amazon Route 53 | DNS resolution and traffic management, supporting multi-region failover | P3 |
| AWS Certificate Manager | SSL certificate management, providing HTTPS encryption | P3 |
| AWS KMS | Data encryption key management, meeting data security compliance | P1 |
5. Architecture Design
The target architecture is built in the AWS Frankfurt region (eu-central-1), adopting a highly available deployment across two Availability Zones to support global business access.
Target Architecture Layers
Access Layer
Route 53
ACM Certificate
ALB
SAP Application Layer
EC2 (SAP HANA)
EC2 (SAP PAS)
Auto Recovery
VPC Private Subnet
Data Layer
RDS PostgreSQL
S3 Backup/Archive
KMS Encryption
High Availability & Backup
EBS Snapshots
S3 Cross-region Archive
Multi-AZ Deployment
Operations & Monitoring
CloudWatch
Lambda Automation
Key Design Decisions
- SAP-certified instances: Choose SAP-certified EC2 types (e.g. memory-optimized) to meet SAP S/4HANA's performance and compatibility requirements.
- High availability across AZs: Deploy the SAP application and database across two AZs, enabling failover to ensure continuous service.
- Compute-storage separation: System data on EBS, backups and archives on S3 — balancing performance with cost-efficiency.
- Security & compliance: All data encrypted in transit and at rest via KMS; fine-grained IAM permission and CloudTrail audit meet cross-border compliance.
6. Non-Functional Requirements
Availability
Core SAP services target 99.95%; multi-AZ deployment ensures failover in case of single-point failure.
Performance
HANA query response < 1 second; batch jobs run in parallel; EBS io2 meets high IOPS for the database.
Security
VPC isolation, Security Group least-privilege, KMS encryption, CloudTrail audit — meeting cross-border data compliance.
Cost
On-demand for the SAP tier, scheduled stop/start for non-production, S3 for cheap archive — estimated 30–40% lower cost.
Maintainability
Infrastructure as code, automated backup and recovery, full monitoring/alerting across all key components.
Scalability
EC2 supports vertical scaling; RDS and S3 scale horizontally; architecture adapts to future business growth.
7. Migration Plan
The overall migration is divided into five phases, expected to complete in 12 weeks. Migrate non-core data first, then the SAP environment, and finally cut over traffic.
Phase 1 · Preparation (Week 1-2)
Environment Setup & Assessment
Set up VPC, subnets and security groups on AWS; prepare SAP-certified EC2 and EBS; assess the current GCP SAP environment and produce a detailed migration checklist.
Phase 2 · Data Migration (Week 3-5)
Database & Backup Migration
Migrate 20GB from Cloud SQL to RDS PostgreSQL via logical backup + incremental sync; copy backup data from GCS to S3, ensuring consistency and integrity.
Phase 3 · SAP Deployment (Week 6-8)
SAP Environment Build
Deploy SAP S/4HANA on EC2 in the AWS Frankfurt region; configure EBS storage and multi-AZ high availability; complete connectivity tests with RDS and S3.
Phase 4 · Cutover (Week 9-10)
Traffic Switch & Validation
Cut over the SAP system from GCP to AWS via Route 53; monitor availability and performance throughout; keep GCP as a rollback backup.
Phase 5 · Wrap-up (Week 11-12)
Optimization & Ops Handover
Tune EC2/EBS specs and Auto Scaling; configure CloudWatch alarms; complete ops documentation; decommission GCP once billing stops.
Migration Risks & Mitigations
| Risk | Impact | Mitigation |
|---|
| Long SAP migration window | Business interruption | Complete non-core migration first; cut over SAP in a maintenance window with rollback plan |
| Data inconsistency | Data loss | Dual-write during migration (GCP + AWS); verify consistency before cutover |
| Performance degradation | Poor user experience | Performance test in AWS environment before cutover; tune EC2/EBS specs |
| Rollback needed | Business interruption | Keep GCP running 30 days after AWS is stable, switchable back at any time |
8. Project Team
Project Manager
Liu Siyuan
Oversees project schedule, coordinates client and internal resources
Architect
Zhao Mingzhe
AWS architecture design, SAP high-availability solution, migration technical review
SAP Basis Engineer
Sun Jiayi
SAP S/4HANA deployment, HANA configuration and tuning
DevOps Engineer
Zhou Yuhang
Automated migration scripts, monitoring/alerting, ops handover
Key Milestones
| Milestone | Time | Deliverable |
|---|
| Migration plan approved | Week 2 | Architecture design doc, migration plan |
| Data migration complete | Week 5 | Data consistency report |
| SAP deployment complete | Week 8 | Environment acceptance, test records |
| Cutover go-live | Week 10 | Go-live confirmation, monitoring report |
| Project acceptance | Week 12 | Ops documentation, project summary |
Need SAP migration or cloud architecture optimization?
We provide a free SAP-on-AWS assessment and cost-saving analysis.
Contact Us