Skip to main content
EN ع
Talk to sales
Migration Services · KSA & MENA

Migration Services

Move workloads, applications, and data with confidence — datacenter relocations, cloud migrations, database moves, SAP and ERP, mainframe modernisation. Discovery-led, wave-based, and rollback-tested.

Plan your migration See migration types
0+ datacenter migrations
0+ workloads to cloud
100% rollback-tested cutovers
// 01 · The migration arc

From source to target — without drama.

Discovery, design, migrate, validate. Every workload follows the same loop, rehearsed before the real cutover.

// 02 · What we move

Six surfaces. One playbook.

From server-room consolidation to mainframe modernisation — the full migration surface for regulated environments in KSA and across MENA.

MIG.01

On-prem to cloud

AWS, Azure, GCP, Huawei, Oracle. Lift-and-shift through full refactor — the 6 R's applied to the workload, not the slide.

MIG.02

Datacenter relocation

Site consolidation and physical relocation with rehearsed cutover weekends and async replication — measured in seconds of user-visible downtime.

MIG.03

Cloud to cloud

Provider-to-provider for cost optimisation, vendor consolidation, or regional sovereignty — including moves into local cloud regions.

MIG.04

Database migration

Oracle, SQL Server, PostgreSQL, MongoDB, MySQL. Heterogeneous migrations with schema conversion and zero-data-loss replication.

MIG.05

SAP & ERP

S/4HANA conversions, Oracle EBS uplifts, and Dynamics 365 moves — with downtime windows costed against business calendars.

MIG.06

Mainframe & legacy

Modernisation, replatforming, and tenant migrations off end-of-life systems — without losing the business logic embedded in them.

// 03 · The 6 R's

Six strategies. One workload at a time.

Not every workload should move the same way. The 6 R's framework — applied to 5,000+ migrated workloads — picks the right strategy per application, not per slide.

01

Rehost — lift & shift

Move the workload as-is. Fastest path off a depreciating datacenter, used as the first wave on most large estates.

  • Best for · speed · low risk
02

Replatform — light lift

Targeted optimisation during the move — managed databases, containers, autoscaling. Same code, better operating posture.

  • Best for · operational gain
03

Refactor — cloud-native highest payoff

Re-architect to event-driven, serverless, or microservices. Reserved for workloads where the unit economics actually pay back the engineering investment.

  • Best for · scale · agility
04

Repurchase · Retire · Retain

Sometimes the right call is to swap to SaaS, switch off the workload entirely, or keep it on-prem on purpose. We name that decision instead of brute-forcing the move.

  • Best for · realism · TCO
// 04 · Industries we migrate

Same playbook. Different regulators.

Every regulated sector in KSA has its own residency, retention, and recoverability rules. We adapt the migration plan to the regulator before we adapt it to the cloud.

SAMA · CSF

Banking & financial services

SAMA Cyber-Security Framework workloads with strict data-residency, replicated core-banking systems, and zero-data-loss tolerance during cutover.

NHA · PHR

Healthcare & hospitals

NPHIES and electronic patient record systems migrated under National Health Authority residency rules, with no patient-record exposure during the move.

NCA · ECC

Government & public sector

NCA-ECC-aligned cloud landing zones in local cloud regions, with mandated audit trails, classification labels, and air-gapped backups.

PDPL

Retail & e-commerce

Order-management, POS, and loyalty systems migrated around peak trading calendars — Ramadan, White Friday, Eid — never against them.

SCADA · OT

Energy & utilities

OT/IT segmentation preserved across the move. Historian and SCADA stacks migrated with full process-control continuity and rehearsed safe-state cutovers.

CITC

Telecom & service providers

OSS/BSS, billing, and subscriber-data platforms migrated under CITC licence conditions — with carrier-grade redundancy preserved through the cutover.

// 05 · Cutover rehearsal timeline

T-4 weeks to T+30. Rehearsed twice.

The cutover weekend is not the first time we run the runbook — it's the third. Two rehearsals against production-shaped data come first, with a documented go/no-go gate before the real one.

Discovery wrap T-4 W Dependency map signed off
Rehearsal 01 T-3 W Dry-run against snapshot
Rehearsal 02 T-1 W Full timing & rollback test
Go / No-Go T-2 D All stakeholders, single call
Cutover weekend T = 0 DNS shift · validate · release
Performance baseline T+7 D Steady-state metrics signed
Hand-off T+30 D Hypercare ends · ops in
// 06 · Methodology

Four phases. One delivery loop.

Every migration runs the same loop — discover, design, migrate, validate. Wave size and durations change with the estate, the sequence does not.

  1. 01

    Discover

    Application discovery, dependency mapping, and risk assessment using Cloudamize, Movere, Azure Migrate, and AWS Application Discovery Service — validated by stakeholder interviews.

  2. 02

    Design

    Wave planning, target architecture, cutover runbooks, rollback procedures, and downtime windows agreed against the business calendar.

  3. 03

    Migrate

    Pattern-matched execution. Pre-rehearsed cutover weekends. AWS MGN, Azure Migrate, Carbonite, Zerto, Veeam, Commvault — whatever the workload needs.

  4. 04

    Validate

    Functional testing, performance baselines, security review, and 30-day hypercare with a senior engineer on standby and daily standups.

// 07 · Risk & rollback matrix

Four things that break migrations.

The post-mortems of failed migrations always name one of these four. Each carries a named mitigation we build into the plan — not the apology.

Risk · 01

Data loss during transit

A backup that was never restored, a database that drifted, a transaction that fell between the dual-write windows.

Mitigation: async replication validated against checksum, point-in-time rollback for 30 days post-cutover, and a tested restore — every backup we take, we also restore.
Risk · 02

Downtime overrun

The 4-hour weekend window becomes 14 hours because dependency X took longer than the discovery doc estimated.

Mitigation: two rehearsal weekends timed end-to-end before the real one, with a go/no-go gate at T-2 days. If the rehearsal can't hit the SLA, we re-plan — we don't push forward.
Risk · 03

Compatibility surprises

An undocumented dependency, an EOL library that the new platform doesn't run, or a configuration baked into the old hypervisor that doesn't transfer.

Mitigation: agentless discovery against the live estate plus stakeholder interviews — two-to-three weeks of mapping before a single workload is touched.
Risk · 04

No clean way back

The migration goes live, something is wrong, and the team realises the rollback was never really tested under load.

Mitigation: a documented, timed rollback path for every wave, exercised in rehearsal 02. We measure rollback as a hard timing, not a checkbox — and we abort if we miss it.
// 08 · Migration tooling

Tooling-neutral. Patterns over products.

// 09 · Outcomes

Outcomes powered by this service.

What this enables once the cutover is done.

Always-on · Outcome

Always-on operations with tested recovery

Same migration practice, framed as the operational posture: rehearsed runbooks, regulator-ready evidence, and a recovery story you have actually executed — not just documented.

Read the outcome page
// 10 · FAQ

Common questions.

Q.01Can you guarantee zero downtime during migration?

We engineer for it. Most cutovers use async replication, rehearsed runbooks, and DNS shifting so user-visible downtime is measured in seconds. For workloads where any downtime is unacceptable, we use blue/green or active-active patterns and rehearse the cutover end-to-end before the real one.

Q.02Do you handle cloud-to-cloud migrations?

Yes. About a quarter of our migrations move workloads between clouds — typically for cost optimisation, vendor consolidation, or regional sovereignty (moving to local cloud regions).

Q.03How long does dependency mapping take?

Two to three weeks for a 200-application estate. We use a mix of agentless discovery (Cloudamize, Movere, Azure Migrate) and stakeholder interviews to validate the machine-generated map.

Q.04What are typical migration timelines?

A 200-VM datacenter relocation runs 8–14 weeks end-to-end. A multi-region cloud migration of 1,500 workloads runs 4–9 months in waves of 50–80 workloads. SAP and mainframe projects are scoped individually.

Q.05Do you provide post-cutover support?

Yes. Every migration includes 30-day hypercare — a senior engineer on standby, daily standups, performance baselines, and a documented hand-off into managed operations or your internal team.

// 11 · Engage

Ready to plan your migration?

Talk to a senior NAS migration architect about scope, residency, and downtime windows. Migration assessment back within a week.

Plan your migration Always-on outcome
Playbook · PDF

Cloud migration playbook

Field-tested playbook covering phased delivery, residency, wave planning, cutover rehearsal, and post-go-live hypercare. Free to download.

Download the playbook Evidence

See it shipped

Published case studies for evidence of what migration engagements look like delivered end-to-end.

Case studies