Cloud Migration & Application Modernisation: Cloud Migration

A legacy application that has become hard to maintain, an on-prem server room running out of capacity, a large investment line item every time the hardware needs refreshing: this is a very common picture in the technology infrastructure of mid-to-large businesses in Turkey. A monolith that has grown over the years runs on a single server; the team that wrote it has long since dispersed, no one dares touch it, and even the smallest change takes weeks. Servers are ageing, UPS and cooling costs are piling up, and the backup strategy is at the "hopefully it works" level. To scale when demand rises, you have to order a new physical server and wait for months. On the infrastructure side of digital transformation, this is the first thing we touch: moving off on-prem and the old monolith into a cloud architecture that migrates gradually with managed risk, scales, is observable, and keeps cost under control.

Our Approach

On a cloud migration project we'd start not by writing code but by building a real inventory of the existing system. Which applications are running, how they depend on each other, which databases exist, what the real traffic pattern is. Every step taken without mapping these produces surprises later. From that inventory we'd make a decision for each workload within the 6R framework: rehost (move as-is), replatform (improve with small touches), refactor (renew the architecture), repurchase (move to off-the-shelf SaaS), retain (keep on-prem for now), or retire (shut it down). We do not have to refactor every application; in most cases the right call is to rehost quickly and invest where the real bottleneck is. We decide which application deserves which treatment based on a balance of business value and risk.

The second critical decision is gradual migration with strangler-fig. The "big bang" projects that try to turn an old monolith into microservices overnight are the most common failure, in Turkey as everywhere. Instead, we'd put an API gateway / reverse proxy in front of the monolith, then extract one business capability at a time (such as billing, user management, reporting) into a separate service and route traffic over piece by piece. The old code stays as a fallback until the extracted piece runs stably. This keeps every step small, testable, and reversible; the business is never locked into a rewrite that drags on for months. The beauty of this approach is that you see value in production from the first week. You do not wait for the whole system to be finished.

The third layer is containerisation and scalability. We'd containerise the applications with Docker and run them on Kubernetes, so the "works on my machine" problem disappears and deployment is identical in every environment. With Kubernetes HPA (Horizontal Pod Autoscaler) it scales out automatically when load rises and scales back down at low traffic: you pay for real usage instead of renting a fixed large server. We manage the entire infrastructure as code with Terraform (IaC); every resource becomes versioned, reviewable, and reproducible, and there are no more "hand-built servers nobody understands". We'd choose between AWS, Azure, and GCP together with you, based on your existing capability, data residency requirements, and cost profile.

The final layer is CI/CD, observability, and safe deployment. Every change is automatically tested and deployed with GitHub Actions or GitLab CI; instead of risky manual night-time releases, you get small and frequent deployments during the day. We collect metrics with Prometheus + Grafana and distributed traces with OpenTelemetry; which services a request passed through and where it slowed down become clear. For going live we use blue-green or canary deploy: we open traffic to the new version first at 5 percent, then 25 percent if there is no issue, then full, and on any mishap we can roll back to the old version within seconds. Our goal: deployment should be an ordinary, boring operation, not a night-time event where everyone holds their breath.

Our Preferred Technology Stack

We typically reach for the following, adapted per project to your existing stack, cloud provider preference, and workload profile.