Cloud Migrasyonu

On-prem'in son demi.
Cloud'un ilk günü.

Sunucu odasında yaşlanan donanımdan AWS, GCP, Azure ya da hibrit modele kademeli, güvenli ve geri dönüşü hazır şekilde geçiyoruz. Sadece sanallaştırılmış kopya değil — gerçek cloud-native fırsatları, FinOps disipliniyle düşürülmüş maliyetler ve zero-downtime kesim planı.

"Lift-and-shift yapalım hızlı olsun" diyenlerin altıncı ay faturası iki katına çıkar. Doğru yol: önce assess, sonra mimari, en son taşıma. Biz bu sırayı atlamıyoruz.

Canlı migrasyon RUN-1
On-Prem DC
Yüksek CAPEX
erp-svc
api-gw
postgres-db
queue-worker
analytics-job
Cloud
AWS GCP AZ
ec2 / gke
rds / aurora
s3 / gcs
eks / aks
Esnek OPEX
Discover
Assess
Plan
Pilot
Migrate
Optimize
Operate
Zero downtime

Neden DIY migrasyon kırılır?

Cloud migrasyonu “kopyala-yapıştır” değildir. Yanlış yapılan migrasyon, sorunu büyüterek faturalandırır.

Sunucularını öylece sanal makineye taşıyıp "cloud'a geçtik" diyen firmaların %70'i ilk yıldan sonra OPEX'inin on-prem CAPEX'inden yüksek olduğunu fark eder. Sebep tek değil: lift-and-shift cloud-native fırsatları yakalamaz, paralel çalıştırma uzun sürerse çift maliyet doğurur, bağımlılıklar haritalanmamışsa zincirleme kesintiler yaşanır, güvenlik politikaları doğrudan kopyalanamayacağı için yeni saldırı yüzeyi açılır. Tüm bunlar önceden bilinen tuzaklar — ama disiplinli bir yaklaşım yoksa, hepsine teker teker düşülür.

01

Lift-and-shift tasarrufu yoktur

Sanal makineyi cloud'a kopyalamak demek; aynı boyutta sunucuyu artık aylık ödemek demektir. Cloud-native servisleri (managed DB, serverless, otomatik ölçek) kullanmıyorsanız, eski faturayı yeni formatta ödüyorsunuzdur.

02

Çift çalıştırma kanama gibidir

On-prem ile cloud aylarca paralel ayakta kalıyorsa, iki ödeme + iki operasyon ekibi anlamına gelir. Plan yoksa bu süre 3 aydan 18 aya uzar; bütçe biter, kesim ertelenir.

03

Keşfedilmemiş bağımlılıklar

Eski sistemlerde unutulmuş bir cron, paylaşılan dosya yolu, sabit IP'ye yapılmış istemci — taşıma sonrası zincir kırılır. Discovery aşaması atlanırsa, bağımlılıklar canlıda çöker.

04

Güvenlik politikası bire bir geçmez

On-prem firewall kuralları cloud security group + IAM + KMS kombinasyonuna çevrilmeli. Doğrudan kopyalama yapılırsa hem fazla geniş izin hem de eksik koruma çıkar.

05

Network ve DNS hesaplaması yanlış

Cross-AZ trafik, NAT gateway, VPC peering, egress data — fatura kalemi olarak ön plana çıkar. Mimari yanlış kurulursa aylık fatura beklenenin 3-5 katı olur.

06

Geri dönüş planı yok

Kesim günü beklenmedik sorun çıkarsa hangi adımla on-prem'e dönülecek? "Yapamayız" diyenler büyük risk alır; biz her aşamada rollback yolunu açık tutarız.

Görsel migrasyon paneli

Şeffaf takip: hangi iş yükü nerede, maliyet eğrisi, hangi 6R kararı.

Kanban — iş yükü akışı

Her iş yükü ayrı bir karttır.

On-Prem

REHOST
legacy-erp
RETAIN
tape-backup

Migrating

REPLATFORM
order-api
REHOST
billing-svc
REFACTOR
checkout-fn

Cloud-ready

DONE
auth-svc
DONE
cdn-edge
DONE
events-bus

CAPEX → OPEX dönüşümü

Birikmiş sermaye, akan operasyona dönüşür.

CAPEX OPEX Tasarruf Q1 Q2 Q3 Q4 Q5 Q6 Q7

CAPEX

−68%

OPEX

+42%

Net

−31%

6 R'nin haritası

Her iş yükü için doğru stratejiyi seçiyoruz — körü körüne taşımak değil.

R

Rehost

Aynen taşı. Lift-and-shift; en hızlı, en az fayda. Süreç kazansa da maliyet aynı kalır.

R

Replatform

Hafif değişiklikle taşı. Managed DB, otomatik yedekleme. Orta efor, gerçek tasarruf.

R

Refactor

Yeniden yaz. Serverless, mikroservis, event-driven. Yüksek efor, en yüksek tasarruf.

R

Repurchase

SaaS'a geç. Eski özel yazılım yerine standart SaaS al. Süreç kısa, model değişir.

R

Retire

Kaldır. Kimsenin kullanmadığı eski servisler hiç taşınmadan kapatılır.

R

Retain

On-prem'de tut. Regülasyon, latency, donanım yatırımı — bazı şeyler taşınmaz.

Kimler için?

Cloud kararının "şimdi" anlam kazandığı sekiz tipik durum.

01

Kurumsal donanım yenileme

Sunucular 5-7 yaşında, garanti bitti, yenileme teklifi geldi. Aynı parayı 3 yıllık cloud taahhüdüne dönüştürmek mantıklı an.

02

Colo'dan büyüyen SaaS

Müşteri sayısı arttı, kabinetler doldu, yeni colo açmak ölçek hatası. Multi-region cloud doğru çözüm.

03

Donanım sınırına dayanan e-ticaret

Black Friday + kampanya peak'leri donanımı zorluyor; otomatik ölçek olmadan müşteri kaybı yaşanıyor.

04

M&A sonrası konsolidasyon

İki şirket, üç datacenter, dört farklı yığın. Cloud tek hedef altyapıda birleştirme için zemindir.

05

Regüle sektör + lokasyon

KVKK, BDDK, finans, sağlık — veri lokasyonu + audit izlenebilirliği şart. Cloud doğru bölgeyle uyumu kolaylaştırır.

06

PaaS'tan mezun olan startup

Heroku/Render/Vercel limitlerini aştınız; gerçek mimari kontrol gerek. Cloud + IaC ile profesyonelleşme.

07

Kamu / eğitim modernizasyonu

On-prem ESKİ ama yatırım bütçesi sınırlı; OPEX modeli + esnek kapasite tek çıkış.

08

Üretim + IoT veri

Fabrikadan akan sensör verisi, edge + cloud katmanlı mimari ister. On-prem tek başına yetmiyor.

10 disiplin tek ekipte

Migrasyon, mimari, FinOps, güvenlik — hepsi aynı odanın aynı sprintinde.

Cloud migrasyonunu farklı tedarikçilere bölmek = sorumluluk dağılır, riskler arasında düşer. Tek ekip + tek roadmap ile her aşama birbirini destekler; karar yavaşlığı kaybolur.

01

Discovery & assessment

Otomatik envanter, bağımlılık haritalama, kullanım profili. Hangi iş yükü hangi 6R kategorisine.

02

TCO modelleme & business case

3 ve 5 yıllık TCO; Reserved/Savings/Spot kombinleri; karar kuruluna sunulabilir iş davası.

03

Hedef mimari tasarımı

Multi-AZ, multi-region, well-architected; failover, DR, RTO/RPO hedefli.

04

Pilot migrasyon

Düşük riskli iki iş yükü ile bilgi + güven kazanımı; sonraki dalgalar için referans.

05

Veritabanı migrasyonu

PostgreSQL, MySQL, Oracle, SQL Server, MongoDB — minimum kesinti ile cutover.

06

Network & VPN

Site-to-site VPN, Direct Connect/ExpressRoute, VPC peering, hybrid DNS.

07

Güvenlik politikası eşleştirme

On-prem firewall + AD + GPO → IAM + SCP + KMS + audit. Hiçbir yetki kaybolmaz.

08

Maliyet optimizasyonu (FinOps)

Right-sizing, scheduling, RI/SP planning, anomaly detection, showback/chargeback.

09

Runbook & operasyon devri

Çalıştırma yordamları, alarm setleri, on-call eğitimi; ekibinize teslim edilmiş sistem.

10

Post-migration optimization

İlk 90 günde maliyet + performans tuning; sürekli iyileştirme döngüsü.

Süreç

Discovery'den steady operasyona: 6 adımda kademeli geçiş.

  1. 01

    Hafta 1-3 · Discovery & assess

    Otomatik tarama + saha workshop; tüm iş yükleri, bağımlılıklar, kullanım profilleri.

  2. 02

    Hafta 3-6 · Plan & TCO

    Hedef mimari, 6R kararları, dalga planı, 3-5 yıllık TCO, geri dönüş yolu.

  3. 03

    Hafta 6-10 · Pilot

    2 düşük riskli iş yükü; landing zone, IaC, izleme, runbook taslakları test edilir.

  4. 04

    Hafta 10-26 · Migrasyon dalgaları

    2-3 haftalık dalgalarda taşıma; her dalga sonunda kabul testi + rollback hazır.

  5. 05

    Hafta 26-32 · Optimize

    Right-sizing, RI/SP satın alımı, otomatik scheduling, anomaly detection.

  6. 06

    Hafta 32+ · Operate & handover

    Runbook, alarm, eğitim, devir; sürekli iyileştirme + aylık FinOps review.

Kullandığımız araçlar

Discovery, taşıma, otomasyon, FinOps — endüstri standardı.

AWS Migration Hub Azure Migrate GCP Migration Center CloudEndure Carbonite Migrate Velostrata Terraform Ansible Datadog CloudHealth Apptio

Müşteri hikâyeleri

Farklı sektör, aynı disiplin, ölçülebilir sonuç.

Üretim DC −%47

Çok lokasyonlu üretici

2 datacenter, 180 sunucu AWS'e taşındı. 14 ay sonra datacenter maliyeti %47 düştü; donanım yenileme bütçesi tamamen iptal.

SaaS 8 hafta

B2B SaaS — 200 servis

200 mikroservis 8 hafta içinde EKS'e taşındı; ortalama deploy süresi 42 dk → 6 dk.

E-ticaret MTTR −%73

Yüksek trafikli e-ticaret

Multi-region cloud + edge cache; MTTR 4 saat → 65 dakika; kampanya günü sıfır kesinti.

Fintech PCI ✓

Ödeme platformu

PCI-DSS uyumlu landing zone + hibrit; veri lokasyonu korunarak audit sürecine girdi.

Medya −%58 / 3×

Yayın platformu

Video transcoding spot instance + lambda; aylık fatura %58 düştü, throughput 3x arttı.

Lojistik Real-time

Kargo & track

Real-time tracking için Kinesis + DynamoDB; on-prem batch sistem retire edildi.

Sık sorulanlar

Müşterilerin en çok sorduğu 8 soru

Tek bir doğru cevap yok; iş yükü bazında karar veriyoruz. Hızlı bir veri merkezi kapatma hedefiniz varsa ve servis cloud-native fırsatlardan çok faydalanmıyorsa lift-and-shift mantıklıdır — örneğin nadir kullanılan internal bir araç. Ancak ürünün kritik bileşenleri için (yüksek trafikli API, ana veritabanı, queue altyapısı) replatform ya da refactor yapmak ilk yıldan itibaren maliyeti %30-60 düşürür. Doğru yaklaşım: 6R analiziyle her iş yükünü ayrı ayrı kategorize etmek, sonra dalga planında karışık yürütmek. Hibrit strateji her zaman saf bir stratejiden daha gerçekçidir.
AWS en geniş servis kataloğu ve en yaygın ekosisteme sahip; çoğu durumda güvenli ön seçim. GCP veri/ML iş yüklerinde ve Kubernetes (GKE) tarafında öne çıkar; daha temiz network mimarisi sunar. Azure ise Microsoft stack (AD, .NET, SQL Server, M365) ile sıkı entegrasyondan dolayı kurumsal müşterilerde tercih edilir. Multi-cloud şart değil — gereksiz karmaşıklık getirir. Bunun yerine cloud-agnostic katmanlar (Kubernetes, Terraform) ile başlamayı öneriyoruz; ileride taşıma esnekliği kalır. Seçim için ekibinizin tecrübesi, hedef pazar, regülasyon ve mevcut anlaşmalar belirleyicidir.
Boyuta göre değişir. 20-50 sunuculuk orta boy bir altyapı 3-6 ay; 100-300 sunucu + birkaç veritabanı içeren bir kurumsal ortam 6-12 ay; çok lokasyonlu büyük portföy 12-24 ay sürebilir. Önemli olan toplam süre değil, dalga ritmidir: 2-3 haftalık dalgalarla taşıma yaparız, her dalgada 5-15 iş yükü. Bu sayede risk dağıtılır, ekibiniz öğrenir, geri dönüş yolu sürekli açık kalır. Big-bang yenileme yapmıyoruz; sebebi açık: kesim günü çıkacak ufak bir hata bile büyük krize döner. Kademeli yaklaşım her zaman güvenli.
Doğru tasarlanırsa evet, %20-50 net tasarruf normaldir. Yanlış tasarlanırsa cloud daha pahalıdır. Tasarruf kaynakları: kullanılmayan saatlerde otomatik durdurma, Reserved Instance + Savings Plan ile %40-65 indirim, spot instance ile batch iş yüklerinde %70-90, managed servislerle operasyon ekibi giderinden tasarruf. Maliyet artıran kaynaklar: cross-AZ trafik, egress data transfer, over-provisioned instance, izlenmeyen test ortamları. Bu yüzden FinOps disiplini şart: aylık kullanım analizi, anomaly detection, right-sizing tavsiyeleri. Müşterilerimizin %88'i ilk 12 ay sonunda eski TCO'larının altında çalışıyor.
Hedefimiz iş yükü başına 0-30 dakika kesinti. Stateless web uygulamaları için blue-green deployment ile sıfır kesinti yapılabilir. Veritabanları için iki yaklaşım var: (1) AWS DMS / Google DMS / Azure DMS gibi araçlarla sürekli replication, kesim anında 1-5 dakika lag bekleyip DNS'i çeviriyoruz; (2) bakım pencere içinde planlı kesim, genelde gece 2-6 saatlik bir aralık. Toplam saat kritik bir parametre olduğu için iş ihtiyaçlarına göre seçim yaparız. Tüm cutover'lar provada simüle edilir; canlıda sürpriz olmaz. Eğer planlanan süreyi aşan bir sorun çıkarsa hazır rollback ile on-prem'e geri dönülür.
Genelde evet, ama dönüştürmek gerek. VMware veya Hyper-V tabanlı yedekler doğrudan AWS/GCP/Azure formatına dönüştürülerek booted edilir — bu yüzden ilk pilot olarak yedeklerden bir kopya cloud'da ayağa kaldırılır; veri ve uyumluluk test edilir. Ancak yedek = migrasyon değildir; yedekteki konfigürasyon eskimiş olabilir, lisanslar farklı işleyebilir, network ayarları yeniden yapılmalı. Yine de yedekler büyük bir başlangıç hızlandırıcısıdır. Cloud-native yedek stratejisini de geçişle birlikte kuruyoruz: snapshot otomasyonu, cross-region replikasyon, immutable backup — fidye yazılımına karşı bile dayanıklı.
Türkiye merkezli müşteriler için AWS İstanbul region, Microsoft Azure Türkiye bölgesi ya da Türk hyperscaler ortakları kullanılabilir. AB merkezli operasyonlar için Frankfurt, Amsterdam, Dublin gibi AB region'ları + DSGVO uyumlu landing zone öneriyoruz. KVKK + GDPR için kritik kontroller: veri ikametgâhı (residency) garantili region seçimi, encryption-at-rest + encryption-in-transit, audit log 7 yıl saklama, IAM rol bazlı erişim, DPO'ya aylık compliance raporu. Hassas iş yüklerini lokal tutup geri kalanı public cloud'a taşıyan hibrit modeller de mümkün. Hukuki ekibinizle birlikte uyum matrisi hazırlıyoruz.
Evet — her aşamada planlıyoruz. İlk 90 gün rollback en kolay aşamadır; on-prem sistem hala canlı, DNS değişimi tersine alınarak trafiği geri yönlendirebiliriz. 90-180 gün arasında on-prem sönmeye başlar; dönmek için yeniden donanım sözleşmesi gerekir, ama veriler hala senkronize tutulduğu için mümkündür. 12 ay sonra full geri dönüş pratik değildir; ancak hibrit moda geçip bazı kritik iş yüklerini özel data centera çekmek hep mümkündür. Cloud kararının geri dönülmez olduğu hissi yanlış; doğru planla esneklik korunur. Vendor lock-in'i minimize etmek için cloud-agnostic katmanlar kuruyoruz (Kubernetes, Terraform, açık standartlar).

On-prem yükünden disiplinli bir cloud'a.

30 dakikalık ücretsiz görüşmede mevcut altyapınızı, donanım yenileme tarihini ve cloud taşıma senaryolarını birlikte değerlendirelim — net bir 3 adımlı yol haritası ile çıkın.

sonuç