Outcome · Cloud freedom without lock-in
Cloud where it pays. On-prem where it must.
The choice between 'all cloud' and 'all on-prem' is a false binary. The real question is which workloads belong where, on what economic and compliance terms. Hybrid Cloud Architecture makes that decision deliberate, not accidental.
PDPL-aware · NCA-ECC aligned
Workload-by-workload placement · PDPL-aware data residency · Vendor-portable design
The problem we solve.
Most cloud strategies are vendor strategies wearing a strategy hat.
Organisations rarely arrive at a single-cloud commitment by deliberate choice. They arrive there through accidents of migration: the team that started on AWS, the SaaS vendor that demanded Azure, the data residency requirement that forced a regional region. By the time anyone draws the architecture diagram, the lock-in has already happened.
At the same time, KSA PDPL and sector-specific data residency requirements are tightening. Some workloads must stay regional; some must stay on-prem; some can run anywhere. A hybrid architecture that respects those constraints, and stays portable, is what separates cloud strategy from cloud consequence.
A posture you can prove.
A workload-aware hybrid posture you can defend on cost, on residency, and on portability.
PILLAR.01 · Workload
By-workload placement
Each workload assessed for the right home — cloud, on-prem, edge, or split — based on residency, performance, and total cost.
PILLAR.02 · PDPL
Compliant by design
Data residency mapped to KSA + regional regulatory requirements before any migration starts. No "discovered" residency violations later.
PILLAR.03 · Portable
Architecture
Designs that survive a vendor switch — not because you will switch, but because the option preserves your leverage.
30–50%
TCO improvement
Typical range for organisations correcting all-cloud or all-on-prem positions to a right-sized hybrid posture.
// outcome metric
What this looks like delivered.
A typical engagement runs 6–12 weeks across workload assessment, placement decisions, and topology design. We do not bundle migration with the design, the recommendation has to stand on its own before any workload moves.
Assess
- Workload inventory
- Cost & performance baseline
- Residency requirements
Decide
- Cloud / on-prem placement
- Vendor selection
- Total cost model
Topology
- Network connectivity
- Identity federation
- Data movement design
Operate
- Hybrid operating model
- FinOps cadence
- Portability checkpoints
Four homes. One placement decision.
The output of the Assess + Decide phases is a workload-by-workload placement matrix. Every workload lives in exactly one of these four categories, chosen deliberately, on cost, residency, and elasticity.
Bursty workloads with no residency lock and elastic capacity needs. The cloud bill follows demand, no rack-and-stack overhead.
- Marketing analytics
- Dev / test environments
- Public-facing web
- Batch processing
Steady-state core stays on-prem; burst tiers, analytics, or DR live in cloud. The most common shape across regulated enterprises.
- Core ERP with cloud analytics
- On-prem DB with cloud DR
- Banking core with cloud channels
- Internal systems with public APIs
Crown-jewel workloads with strict residency, predictable load, or sector regulator commitments. Modernised, but local.
- Core banking ledger
- Sovereign government data
- Patient records (NHA scope)
- Sensitive R&D / IP
Workloads that must stay local for latency or operational autonomy, at branches, plants, retail sites, or remote facilities.
- Branch point-of-sale
- Industrial OT / SCADA
- In-store inference
- Disconnected operations
Three services. One delivered outcome.
This outcome is composed from our services. Each does one thing well, together they ship the posture above.
// service.01
Cloud Services
Cloud-native expertise across AWS, Azure, and Huawei Cloud — provider-neutral assessment, regional landing zones.
Open Cloud Services // service.02Infrastructure Services
On-prem foundations — for the workloads that should stay or must stay, with cloud-grade automation overlay.
Open Infrastructure Services // service.03Migration
When a workload should move — controlled cutover engineering with the residency and downtime constraints handled.
Open MigrationHonest questions.
Q.01How is workload placement actually decided?
Each workload is assessed on three axes, residency (must stay in KSA, can leave), elasticity (predictable vs bursty load), and total cost. The output is a placement matrix per workload, signed off by the business owner before any migration is planned.
Q.02Do you do the migration too, or just the design?
Both, but never in the same engagement. The recommendation has to stand on its own first. If the placement decisions hold up, migration follows as a separately scoped engagement composed from our Migration service.
Q.03How do you avoid lock-in if we go cloud-heavy?
By designing for portability: provider-neutral identity, containerised workloads where the economics pay off, infrastructure-as-code that targets more than one cloud, and an annual portability checkpoint baked into the operating model.
Q.04What about PDPL and sectoral residency requirements?
Residency is the first filter in the placement matrix, not the last. Workloads that must stay regional are tagged before any cost or performance scoring, so the answer is never "we discovered later that this can't move".
Q.05What is the typical TCO improvement you see?
30–50% range for organisations correcting all-cloud or all-on-prem positions to a right-sized hybrid posture. The improvement comes from moving the right workloads, not from negotiating a better cloud bill.
// 07 · Engage
Want a vendor-neutral read on your cloud strategy?
30-minute review of your current cloud posture, with workload-by-workload analysis of where you are paying for the wrong fit. No deck, no pitch.