Infrastructure migration
Virtual machines, storage, networking — including Windows and Linux servers, VMware estates and NFS/SMB storage.
AWS MGNDataSyncStorage Gateway
Migration
Move the estate.
Without moving the risk.
Wave-based migration — MAP-funded on AWS, minimal disruption to run-the-business operations.
What we do
Phoenix delivers wave-based cloud migrations — infrastructure, applications, databases and specialised workloads (SAP, Windows, custom estates). Most engagements run inside the AWS Migration Acceleration Program (MAP), which funds the migration and gives us a proven methodology to structure the work.
We plan the move, prove it with a pilot wave, then execute at scale — with the managed-services team already in place for day one after cut-over.
Inside the practice
What's in scope.
Application migration
Packaged applications, custom code, integration and messaging — replatformed or lifted-and-shifted based on what earns its keep.
Custom appsMiddlewareIntegration
Database migration
Oracle, SQL Server, MySQL and PostgreSQL — homogeneous or heterogeneous. RDS, Aurora and self-managed options assessed against workload.
AWS DMSSCTRDSAurora
Workload migration
SAP on AWS (via RISE or self-managed), Windows-heavy estates, HPC and specialised workloads that need a considered approach.
SAP on AWSRISEWindows
How Phoenix delivers
The approach.
Assess
Migration Readiness Assessment (MRA)
Discovery, TCO modelling, wave planning, dependency mapping — the shape and size of the migration before commit.
Mobilize
Foundations & pilot
Landing zone in place, tooling stood up, pilot wave migrated end-to-end to prove the path.
Migrate
Wave-based execution
Waves grouped by business unit, criticality or dependency. Cut-over rehearsals, then production cut-overs with rollback plans.
Modernize
Value lift after go-live
Post-migration modernization identified during the move gets scheduled and delivered — not left on a slide.
What you get
Named deliverables.
Every engagement lands specific artefacts — not slides.
Migration Readiness Assessment with TCO model and wave plan.
Pilot wave migrated and validated by the business.
Production waves cut over on schedule with rollback plans.
Handover to the managed-services team for day-two operations.
Post-migration modernization backlog agreed with the customer.
Customer stories
Customers on this journey.
Real Phoenix engagements — measured outcomes at MEA scale.
Pharmaceutical distribution·Egypt
Pharmaoverseas Group
Egypt's largest pharma distributor moves SAP to the cloud.
2,500 Users digitalized50% Uptime improvement
Manufacturing (Plumbing)·Egypt · Germany
EGIC Group
Plumbing market-leader upgrades SAP to RISE on AWS in a month.
80% Uptime improvement100% Hardware cost reduction
Real Estate·Egypt · MENA
Arab Developers Holding
Real-estate group refactors SAP to HANA — with GenAI on top.
90% Backup time reduction11×9s Data durability (S3)
More cloud services
The wider cloud practice.
FAQ
Frequently asked
Which of the 7 R's do you use per workload?
Chosen per workload in the assessment. Rehost (lift-and-shift) for straightforward moves under time pressure; Replatform for right-sized instance / OS / DB versioning; Refactor / Re-architect for workloads that benefit from being cloud-native; Retire and Retain where migration doesn't make business sense.
Are you MAP-eligible? What does that mean commercially?
Yes — Phoenix is an AWS Migration Acceleration Program (MAP) partner. For qualifying workloads, AWS co-invests migration credits alongside the customer's spend, which materially offsets programme cost. The scoping workshop confirms MAP eligibility per workload.
How do you handle SAP-specific migrations — HANA and classic ECC?
SAP-on-AWS migrations follow the SAP-Certified reference architectures. HANA workloads use certified instance families (X2iedn / R5b / U7in and successors) and Amazon EBS with the right IOPS profile. Classic ECC with any-DB migrates under SAP OS/DB migration procedure or is combined with a HANA conversion as one programme.
How is cutover risk managed?
Wave planning with defined go/no-go gates, dress rehearsals, and reversible cutover procedures where the source stays live until success is confirmed. Business continuity is planned around defined RTO/RPO targets; disaster recovery is stood up before, not after.
What happens after go-live — do we handle run ourselves?
Optional. Phoenix hands over to your team with runbooks and documentation, or transitions the workload into our Cloud & Data Managed Services (CloudOps + DataOps + MLOps) so ongoing operations, patching and cost management continue under SLA.
Talk to us
The earliest conversations
are usually the most useful.
Whether you're scoping an SAP move to cloud, restarting a stalled programme, or just trying to figure out where data and AI fit — start with a conversation.