Cloud migration · Kubernetes
Kubernetes migration in Saudi Arabia: one decision per application
A Kubernetes migration moves applications from servers or virtual machines to containers running on a Kubernetes cluster. It goes wrong when it is treated as packaging: the application is wrapped in a container, deployed, and nothing improves. Interkey plans and carries out Kubernetes migration for organisations in Saudi Arabia, starting from the application rather than the platform, and operates the cluster afterwards.
In short
- What it is: moving applications onto Kubernetes, decided one application at a time, including the ones that should not move.
- First step: an inventory with a decision and a reason for every application, then the fixes each one needs before it can run as several identical instances.
- Key decision: managed Kubernetes from a cloud provider, or self-managed in the Kingdom. Where the data may live usually settles it.
- Where it works: from VMs, bare metal or a cloud account, in Saudi Arabia, delivered from Riyadh in Arabic and English.
- After go-live: Interkey can operate the cluster under a written managed-services scope.
What a Kubernetes migration is, and why packaging is not enough
Containerising is well understood as an idea and often mishandled in practice. The usual failure is a Kubernetes migration that only wraps an existing application in a container. The application still holds state locally, still assumes it is the only instance, and still cannot be restarted without a coordinated outage.
So the work starts from the application. What prevents this system from running as several interchangeable instances? Typical answers are local session state, filesystem assumptions and hard-coded configuration. Those are fixed before the orchestration layer is expected to solve them.
Which route fits each application
Every application in the inventory ends up in one of these rows. A programme where everything is a rewrite has not been assessed, and neither has one where everything is moved unchanged.
| Route | What it means | When it is the right call |
|---|---|---|
| Leave it | The application stays where it is and comes off the programme | It is stable, meets its obligations and nobody is waiting on it. |
| Retire | Switched off, with its data archived as the retention obligation requires | A handful of users and a successor already exists |
| Rehost | The same application on new infrastructure, with minimal change | A hard deadline such as a data-centre exit. It inherits every existing inefficiency |
| Replatform | The same application adapted to run as containers, with managed services underneath where they fit | The default for most workloads worth moving: real operational gain, bounded change, no rewrite |
| Rewrite | The application is rebuilt | Only where the current implementation is itself the constraint on the business |
The same answers are set out on the cloud migration page.
How the migration runs
-
Inventory and classify.
Every application, its dependencies, its data classification and its owner.
-
Decide per application.
The routes above applied entry by entry, with the reason recorded.
-
Unblock the application.
Fix what stops it running as several instances, then design the container images and the build pipelines so that deployment becomes routine rather than an event.
-
Build the cluster.
Cluster architecture and sizing for the workloads it will carry, with ingress, secrets, observability hooks and the pipeline that deploys to it.
-
Move in dependency order.
Start with something real but recoverable. Estates move piece by piece with the old system live for a long time, and the platform has to accommodate that.
-
Operate and decommission.
Somebody owns the new environment, and the old one is switched off.
Managed or self-managed Kubernetes
Take a cloud provider's managed service when your data is allowed to live there. Choose self-managed only when a constraint forces it.
| Question | Managed service | Self-managed, in the Kingdom |
|---|---|---|
| Where workloads may run | The provider's regions, which is fine when your obligations allow it | Your infrastructure inside the Kingdom, the usual reason to choose it |
| Control plane | The provider handles upgrades, availability and patching | You or your partner own versions, upgrades and rollback discipline |
| Day-two ownership | You still own alerting, cost and the upgrades of what runs on it | Somebody owns versions, capacity review and on-call for years |
| What you give up | Residency control and some architectural freedom | The provider's automation: you buy control with engineering effort |
Interkey does the day-two work on the Saudi working week, or backs the team that does.
What a production cluster has to be able to show
A security review will ask for these. Building them in from the start costs far less than retrofitting them under audit pressure:
- role-based access control that maps to real teams, not one shared admin credential;
- admission policy that refuses what is not allowed to run;
- image scanning and a private registry, so provenance is known;
- secrets kept outside the codebase, with rotation that actually happens;
- an upgrade cadence with a tested rollback, and backup and restore proven by an actual restore.
What goes wrong, and what it costs
Migrations rarely fail at the technical step. They fail because the programme never finishes and the organisation ends up running two estates, because the business case was a hosting comparison, or because nobody owned the destination. Budget for the overlap, for the egress cost of leaving again, and for a team that now runs services rather than servers. Moving the database engine at the same time is a second migration sold as one, so plan it separately: see database migration.
Relateddatabase migration
How Interkey delivers it
Docker and Kubernetes are technologies Interkey implements and operates, and the engineers on the cluster are Interkey's own team in Riyadh. The platform build is scoped as a fixed piece of work: cluster, ingress, secrets, observability hooks and the deployment pipeline. Operation afterwards is a written scope under managed services. Pricing follows that scope, with cloud consumption shown as the provider's cost.
The first conversation covers what runs where today, such as VMs, bare metal or a cloud account, and whether the constraint is residency, cost or release speed. See also Docker and Kubernetes implementation and Kubernetes monitoring.
Questions buyers ask about Kubernetes migration
Does every application need to move to Kubernetes?
No. A stable application that deploys fine as it is gains nothing from moving. An assessment should end with a list of applications that stay where they are.
Do we have to rewrite the application first?
Not usually. Most workloads worth moving are replatformed: adapted to run as containers, with bounded change. A rewrite is justified only where the current implementation is itself the constraint on the business.
Should we choose managed or self-managed Kubernetes?
Managed when your data is allowed to live in the provider's regions. Self-managed, in the Kingdom, when your obligations require it. That choice is made in the first conversation, before any cluster is built.
How long does a Kubernetes migration take?
Longer than the plan, because the schedule is usually set by other teams' change windows and dependency chains. What we can give early is a realistic first phase.
Who runs the cluster after go-live?
Whoever is named before the build starts: your team, or Interkey under a managed-services scope. Not deciding is the one answer that does not work.
Next
Related pages
Next step
Discuss a Kubernetes migration
Tell us what runs where today, such as VMs, bare metal or a cloud account, and whether the constraint is residency, cost or release speed. That is enough to start.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia