Can VirtuWa and VMware run side by side during migration?

Yes. Most programs run both platforms in parallel through the migration window so workloads move in waves rather than in a single cutover event.

What happens to VM disks during conversion?

Virtual disks are converted to KVM-compatible formats and validated for boot, performance and application behaviour before the source workload is decommissioned.

How is downtime minimized?

Waves are sequenced by downtime tolerance, cutovers are rehearsed, and each wave has a documented rollback path back to the source environment.

What about backup and disaster recovery after migration?

Hemaya Backup & DR policies are applied as part of the target design, so protection is in place before a workload is considered migrated.

Do we need to rewrite automation?

Existing automation is reviewed during assessment. VirtuWa exposes REST APIs and a Terraform provider through Mehad, so most infrastructure-as-code patterns can be reproduced.

What is private cloud migration and when does it make sense?

Private cloud migration moves workloads from an existing virtualization platform or public cloud onto dedicated infrastructure you or a regional provider operate. It makes sense when data residency, compliance, cost predictability or performance require more control over where workloads run.

How do we plan a migration?

Start with a full inventory: virtual machines, dependencies, storage and network patterns and change windows. Workloads are then scored by risk and downtime tolerance and grouped into migration waves.

How are application dependencies between VMs handled?

Dependencies are mapped during discovery, and tightly coupled services are migrated in the same wave so components of one application are not split across two environments.

What are the most common migration risks?

Undiscovered dependencies, network configuration differences, untested performance assumptions and no clear rollback path. Discovery, pilot and validation stages exist to surface these before cutover.

How is performance validated after migration?

Performance baselines are captured in the source environment before the move and compared against the same measurements in the target after migration, before a workload is accepted into steady-state operations.

Can we roll back if a wave does not go well?

Yes. The source workload remains recoverable until validation is signed off, and every wave has a documented rollback path.

What about licensing and cost during the parallel run?

Both platforms run together during the transition, so licence overlap is planned into the wave schedule to keep the period of duplicated cost as short as possible.

Will our team need new skills to operate the platform after migration?

The platform is built on KVM, Linux and open standards, and day-to-day operations run from Lejam Cloud Manager with an Arabic-first interface. Operational enablement is part of the transition to steady state.

Solution

VMware migration, without the guesswork

Move virtual workloads from VMware to VirtuWa through a seven-stage program built around discovery, validation and rollback — so migration is a planned engineering exercise, not a leap.

Request a Migration Assessment Request a POC

Why teams move

What is driving VMware migration decisions

Most migration programs start with commercial pressure and end up being about control: licensing exposure, packaging changes, single-vendor dependency, and the desire to operate infrastructure on open, portable foundations.

Licensing exposure

Renewal and bundling changes have made multi-year cost forecasting harder.

Vendor lock-in

Proprietary formats and tooling limit portability and negotiating position.

Data residency

Regulatory expectations around where workloads and data physically run.

Support responsiveness

Time-zone and language gaps slow down critical incident handling.

Operational control

Teams want direct control of the platform they are accountable for.

Open foundations

Preference for Linux, KVM, QEMU, libvirt and standard APIs.

The journey

A seven-stage migration program

Each stage has entry criteria, validation evidence and a defined rollback path.

1
Discovery
Inventory clusters, hosts, VMs, storage, networks, dependencies and licensing exposure.
2
Assessment
Score every workload for migration complexity, downtime tolerance and target sizing.
3
Design
Design the target ASAS HV / Lejam environment: clusters, storage, networking, RBAC and protection.
4
Pilot
Migrate a representative non-critical wave and validate performance, tooling and operations.
5
Migration waves
Convert and move workloads in planned waves with rollback defined for each wave.
6
Cutover
Rehearsed cutover windows with validation checklists and documented fallback.
7
Operate & optimize
Hand over to steady-state operations with monitoring, backup policies and automation in place.

Scope

What gets migrated, and how

Workloads and data

Virtual machine compute, memory and disk configuration
Virtual disk conversion to KVM-compatible formats
Guest OS boot and driver validation
Application-level validation before decommissioning the source

Platform and operations

Network topology, VLANs and segmentation mapping
Storage layout, performance profiles and capacity planning
RBAC model, audit logging and operational runbooks
Backup policies and disaster recovery plans on the target

Side by side

Source and target at a glance

Area	VMware source	VirtuWa target
Hypervisor	ESXi	ASAS HV (KVM/QEMU)
Management	vCenter and add-on modules	Lejam Cloud Manager
Migration tooling	Vendor and partner tooling	Jisir Migration
Protection	Add-ons or third-party products	Hemaya Backup & DR
Automation	PowerCLI, vendor APIs	REST API and Terraform provider via Mehad
Operating language	English	Arabic and English
Support model	Global support organisation	Regional engineering and support

Start with an assessment, not a commitment

We will inventory your environment, score the workloads and return a phased migration plan with effort and risk per wave.

Request a Migration Assessment Try the Online Demo

FAQ

VMware migration questions

Timelines depend on workload count, dependency complexity and change windows. A discovery and assessment typically takes two to four weeks, after which migration waves are scheduled against your maintenance calendar.