Yazılım Modernizasyonu - Legacy System Migration

Eski Teknolojiden Modern Altyapıya Güvenli Geçiş

10-15 yıllık kodunuz var mı? Eski teknolojiler yüzünden yeni özellik eklemek günler mi sürüyor? Güvenlik açıkları endişe mi veriyor? Yetenekli geliştiriciler o teknolojide çalışmak istemiyor mu?

Yazılım modernizasyonu ile eski sistemlerinizi modern, sürdürülebilir, ölçeklenebilir mimariye taşıyoruz. Risk minimize ederek, iş sürekliliğini koruyarak.

Neden Yazılım Modernizasyonu?

Legacy Sistemlerin Maliyeti:

• Bakım maliyeti 3-5x daha yüksek (yeni geliştirmeye göre)
• Yeni özellik geliştirme %60-70 daha yavaş
• Güvenlik açıkları riski (eski framework’ler, desteklenmiyor)
• Teknik borç birikmesi (kod karmaşıklaşıyor, anlaşılmıyor)
• Yetenekli geliştirici bulmak çok zor (kimse ASP.NET 2.0 bilmek istemiyor)

Modernizasyon Sonrası Kazançlar:

• ✓ Geliştirme hızı %40-60 artış
• ✓ Altyapı maliyeti %30-50 azalma (cloud efficiency)
• ✓ Bakım maliyeti %40 düşüş
• ✓ Sistem uptime %99.9+ (modern cloud SLA)
• ✓ Güvenlik posture güçleniyor
• ✓ Rekabetçi kalabilme (hızlı pivot, yeni özellikler)

---

Legacy Sistem Nedir ve Ne Zaman Modernize Edilmeli?

Legacy Sistem Tanımı

Legacy (Miras) Sistem: Eski teknolojilerle geliştirilmiş, hala kullanımda olan ama modern ihtiyaçlara cevap vermekte zorlanan yazılım sistemleridir.

Legacy Göstergeleri:

• 🚩 10+ yıllık kod tabanı
• 🚩 Eski teknoloji stack (örn: Java 6, PHP 5, .NET Framework 2.0)
• 🚩 Monolitik mimari (tek büyük uygulama)
• 🚩 Teknik dokümantasyon yok veya çok eski
• 🚩 Orijinal geliştiriciler ayrıldı, kimse tam bilmiyor
• 🚩 Automated test yok
• 🚩 Yeni özellik eklemek riskli ve yavaş
• 🚩 Deployment manuel, saatler sürüyor

Modernizasyon Sinyalleri

1. İş Etkisi:

Senaryo: E-ticaret sitesinde Black Friday
Problem: Traffic 10x artıyor, sistem çöküyor
Legacy Limitation: Monolithic architecture, manuel scale
Sonuç: 4 saatlik downtime, $250K kayıp satış

→ Modernizasyon gerekli: Cloud-native, auto-scaling

2. Maliyet:

Durum: Sunucu maliyetleri $8,000/ay
Analiz:
- Eski, inefficient kod
- Scale etmiyor, her zaman max capacity çalışıyor
- Manuel yönetim, DevOps 3 gün/hafta sadece buna harcıyor

Modern yaklaşım: Serverless/cloud, $2,500/ay, otomatik
→ Yıllık $66,000 tasarruf

3. Güvenlik:

Risk: Framework desteği bitti (PHP 5.6, 2019'da EOL)
Tehdit: Bilinen güvenlik açıkları patch yok
Compliance: PCI-DSS, GDPR gereksinimleri karşılanmıyor

→ Modernizasyon critical, yasal/regulatory risk

4. Talent Problemi:

Gerçek: ASP.NET 2.0 bilen senior developer bulmak
Zaman: 6 ay arama, bulunamadı
Maliyet: Ekip içinde eğitim, motivasyon düşük

Modern stack: React, Node.js, Python
Zaman: 2 hafta, 20+ başvuru

→ Modernizasyon, talent akışını kolaylaştırır

---

Modernizasyon Stratejileri (The 5 Rs)

Gartner’ın 5R Modeli

1. Rehost (Lift and Shift)

Tanım: Kodu değiştirmeden, farklı altyapıya taşıma

Örnek:
Önce: On-premise sunucu (fiziksel/VM)
Sonra: AWS EC2, Azure VM

Değişen: Sadece altyapı
Değişmeyen: Kod, mimari

Avantajları:

• ✓ Hızlı (1-3 ay)
• ✓ Düşük risk
• ✓ Hemen cloud faydaları (uptime, backup)

Dezavantajları:

• ✗ Cloud-native değil, maliyet optimizasyonu yok
• ✗ Teknik borç devam ediyor
• ✗ Uzun vadede limited kazanç

Ne zaman kullanılır:

• Acil data center kapatma
• Hızlı cloud’a geçiş gerekiyor
• İlk adım (sonra Refactor)

---

2. Refactor (Re-platform)

Tanım: Minimum kod değişikliği ile cloud optimize etme

Örnek:
Önce: Monolithic Java app + MySQL (on-prem)
Sonra: Aynı app + Amazon RDS + Elastic Beanstalk

Değişiklikler:
- Database connection string
- Session management (sticky sessions → Redis)
- File storage (local disk → S3)
- Basit config değişiklikleri

Mimari: Hala monolithic ama cloud services kullanıyor

Avantajları:

• ✓ Orta hız (2-4 ay)
• ✓ Managed services faydası (RDS, Redis, etc.)
• ✓ Maliyet optimizasyonu başlıyor
• ✓ Düşük-orta risk

Dezavantajları:

• ✗ Hala monolithic mimari
• ✗ Scalability sınırlı
• ✗ Teknik borç tam çözülmüyor

---

3. Rearchitect (Re-design)

Tanım: Mevcut kodu modern mimariye dönüştürme

Örnek: Monolith → Microservices

Önce:
┌─────────────────────────────┐
│   Monolithic Application    │
│  - User Management          │
│  - Product Catalog          │
│  - Order Processing         │
│  - Payment                  │
│  - Notifications            │
└─────────────────────────────┘

Sonra:
┌───────────┐  ┌───────────┐  ┌───────────┐
│   User    │  │  Product  │  │   Order   │
│  Service  │  │  Service  │  │  Service  │
└───────────┘  └───────────┘  └───────────┘
     │              │              │
┌───────────┐  ┌───────────┐
│  Payment  │  │   Notify  │
│  Service  │  │  Service  │
└───────────┘  └───────────┘

Değişiklikler:

• Kod modüllere ayrılıyor
• Bağımsız deploy edilebilir servisler
• API gateway, service mesh
• Event-driven communication
• Polyglot (her servis farklı dilde olabilir)

Avantajları:

• ✓ Scalability (her servis bağımsız scale)
• ✓ Independent deployment
• ✓ Team autonomy
• ✓ Teknoloji flexibility

Dezavantajları:

• ✗ Yüksek complexity
• ✗ Uzun süre (6-18 ay)
• ✗ Yüksek maliyet
• ✗ Distributed system challenges

Ne zaman:

• Büyük, yüksek traffic sistemler
• Sık deployment gerekiyor
• Farklı ekipler, farklı servisler
• Uzun vadeli strateji

---

4. Rebuild (Re-build)

Tanım: Sıfırdan yeniden yazma (aynı gereksinimler)

Scenario:
Eski: PHP 5, custom framework, jQuery, MySQL
Yeni: React + Node.js + PostgreSQL, modern best practices

Kod: %100 yeni yazılıyor
Fonksiyonalite: Aynı (mevcut özellikleri replicate)

Ne zaman:

• Kod tam anlaşılmıyor (spagetti)
• Test edilemiyor
• Teknoloji stack tamamen ölmüş (Flash, Silverlight)
• Lisans problemi (eski vendor artık yok)

Avantajları:

• ✓ En temiz kod
• ✓ Modern best practices
• ✓ Teknik borç sıfırlanıyor

Dezavantajları:

• ✗ En uzun süre (12-24 ay)
• ✗ En yüksek maliyet
• ✗ En yüksek risk (scope creep, feature parity)
• ✗ Business value yok (aynı fonksiyonalite)

---

5. Replace (Re-purchase)

Tanım: COTS (Commercial Off-The-Shelf) ürün satın alma

Örnek:
Eski: 15 yıllık custom CRM
Yeni: Salesforce satın al

Eski: Custom email marketing tool
Yeni: Mailchimp, HubSpot

Ne zaman:

• Commodity functionality (CRM, ERP, etc.)
• Custom avantajınız yok
• Bakım maliyeti çok yüksek
• SaaS alternatifi iyi

Avantajları:

• ✓ Hızlı (1-3 ay)
• ✓ Düşük başlangıç maliyeti
• ✓ Bakım yok (SaaS vendor yapar)
• ✓ Sürekli güncelleme

Dezavantajları:

• ✗ Özelleştirme sınırlı
• ✗ Vendor lock-in
• ✗ Uzun vadede subscription maliyeti
• ✗ Data ownership

---

Strateji Seçimi: Karar Matrisi

                  Süre    Maliyet   Risk   Teknik Borç   ROI
------------------------------------------------------------
Rehost            Kısa    Düşük     Düşük  Devam ediyor  Düşük
Refactor          Orta    Orta      Orta   Kısmi çözüm   Orta
Rearchitect       Uzun    Yüksek    Yüksek Temizleniyor  Yüksek
Rebuild           Çok Uzun Yüksek   Yüksek Sıfırlanıyor  Orta
Replace           Kısa    Orta      Orta   Ortadan       Orta

Önerimiz: Strangler Fig Pattern (aşamalı modernizasyon)

---

Strangler Fig Pattern (Önerilen Yaklaşım)

Konsept

Martin Fowler’ın Strangler Fig Pattern: Yeni sistem eski sistemi zamanla “boğar”, sonunda tamamen değiştirir.

Başlangıç:
┌─────────────────────┐
│   Legacy System     │  ← Tüm traffic buraya
│   (Monolith)        │
└─────────────────────┘

Adım 1: Proxy Layer Ekle
           ┌─────────┐
           │ Proxy/  │
           │ Routing │
           └─────────┘
                │
     ┌──────────┴──────────┐
     ↓                     ↓
┌─────────┐         ┌──────────┐
│ Legacy  │         │New Module│
│ System  │         │ (users)  │
└─────────┘         └──────────┘

Adım 2: Daha Fazla Modül Yeni Tarafa Geçiyor
           ┌─────────┐
           │ Routing │
           └─────────┘
                │
     ┌──────────┼──────────┐
     ↓          ↓          ↓
┌─────────┐ ┌──────┐ ┌──────────┐
│ Legacy  │ │ User │ │ Product  │
│(Orders) │ │Service│ │ Service  │
└─────────┘ └──────┘ └──────────┘

Adım N: Legacy Tamamen Elimine
           ┌─────────┐
           │ Routing │
           └─────────┘
                │
     ┌──────────┼──────────┬──────────┐
     ↓          ↓          ↓          ↓
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ User   │ │Product │ │ Order  │ │Payment │
│Service │ │Service │ │Service │ │Service │
└────────┘ └────────┘ └────────┘ └────────┘

Legacy sistem → Decommission

Avantajları:

• ✓ Risk minimize (incremental)
• ✓ Her adımda value deliver
• ✓ Rollback kolay (routing değiştir)
• ✓ Business continuity korunuyor
• ✓ Team learning (her modül ile öğrenme)

---

Teknoloji Modernizasyonu Yol Haritası

Faz 1: Assessment ve Planlama (2-4 Hafta)

Code Analysis:

# Static code analysis tools
SonarQube: Code quality, technical debt
  - Complexity metrics
  - Code smells
  - Security vulnerabilities
  - Test coverage

# Dependency analysis
Dependencies: Hangi library/framework kullanılıyor?
  - Deprecated mi?
  - Security advisory var mı?
  - Yeni versiyonu var mı?

# Architecture discovery
- Modul dependencies (hangi modul neyi çağırıyor?)
- Database schema analizi
- API inventory

Current State Documentation:

• Architecture diagram (as-is)
• Data flow diagrams
• Integration points
• Pain points (nerede en çok sorun?)

Prioritization:

Impact vs Effort Matrix:

                    High Impact
                        │
         ┌──────────────┼──────────────┐
         │ Quick Wins   │ Major         │
 Low     │              │ Projects      │
 Effort  │ (Burada      │ (Strateji)    │
         │  başla)      │               │
         ├──────────────┼──────────────┤
         │ Fill-in      │ Hard Slogs    │
         │              │ (Avoid if     │
         │              │  possible)    │
         └──────────────┼──────────────┘
                        │
                    Low Impact

Örnek:
Quick Win: API documentation update, logging iyileştirme
Major Project: Monolith → Microservices (user service first)
Hard Slog: Tüm sistemi rebuild (değmez)

---

Faz 2: Foundation Hazırlık (4-8 Hafta)

1. CI/CD Pipeline Kurulumu

# .github/workflows/ci.yml
name: CI/CD

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run tests
        run: npm test
      - name: Code coverage
        run: npm run coverage

  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - name: Build Docker image
        run: docker build -t app:${{ github.sha }} .
      - name: Push to registry
        run: docker push app:${{ github.sha }}

  deploy-staging:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to staging
        run: kubectl apply -f k8s/staging/

2. Automated Testing

// Strangler pattern için critical: Regression test
describe('User API - Backward Compatibility', () => {
  test('Old API format still works', async () => {
    const response = await request(app)
      .get('/api/users/123')  // Old endpoint
      .expect(200);

    expect(response.body).toHaveProperty('userId'); // Old field name
    expect(response.body).toHaveProperty('fullName');
  });

  test('New API format works', async () => {
    const response = await request(app)
      .get('/api/v2/users/123')  // New endpoint
      .expect(200);

    expect(response.body).toHaveProperty('id'); // New field name
    expect(response.body).toHaveProperty('name');
  });
});

3. Monitoring ve Observability

// Logging (structured)
const logger = require('winston');

logger.info('User created', {
  userId: user.id,
  service: 'user-service',
  version: 'v2',
  duration: 45 // ms
});

// Metrics (Prometheus)
const promClient = require('prom-client');
const httpRequestDuration = new promClient.Histogram({
  name: 'http_request_duration_ms',
  help: 'Duration of HTTP requests in ms',
  labelNames: ['method', 'route', 'status_code']
});

// Tracing (Distributed - OpenTelemetry)
const tracer = require('./tracer');
const span = tracer.startSpan('getUserById');
span.setAttributes({ userId: '123', service: 'user-service' });
// ... operation ...
span.end();

---

Faz 3: İlk Modül Migration (8-12 Hafta)

Stratejik Modül Seçimi:

Kriterler:

1. Well-bounded: Net sınırları var (az dependency)
2. High value: Sık kullanılıyor, business critical
3. Low risk: Başarısızlık sistemi çökertmez
4. Learning opportunity: Team’in öğrenmesi için iyi

Örnek: User Service (İyi İlk Seçim)

Neden User Service?
✓ Bounded: User CRUD, authentication, profile
✓ High value: Her işlem kullanıcı gerektirir
✓ Low risk: Read-heavy, write az
✓ Learning: Modern auth (JWT, OAuth) öğrenme

Migration Adımları:

1. Dual Write (2 hafta)
   - Yeni user service geliştirilir
   - Legacy'ye yazma devam ediyor
   - Aynı anda yeni service'e de yazıyor
   - Read legacy'den

2. Shadow Mode (2 hafta)
   - Her read, hem legacy hem yeni service'den
   - Sonuçlar compare ediliyor
   - Farklılıklar log'lanıyor
   - User'a legacy sonuç dönüyor

3. Canary Release (2 hafta)
   - %5 traffic yeni service'e
   - Monitoring heavy
   - Sorun varsa hemen rollback
   - %5 → %25 → %50 → %100

4. Legacy Decommission
   - Yeni service %100 traffic alıyor
   - Legacy user code silinebilir

Kod Örneği: Dual Write

// Legacy'de yeni service entegrasyonu
async function createUser(userData) {
  try {
    // Legacy database'e kaydet (eski)
    const legacyUser = await LegacyDB.users.create(userData);

    // Aynı anda yeni service'e de gönder (dual write)
    await fetch('http://user-service/api/users', {
      method: 'POST',
      body: JSON.stringify(userData)
    }).catch(err => {
      // Yeni service başarısız olursa log et ama hata verme
      logger.error('New user service failed', err);
    });

    return legacyUser; // Legacy sonuç dön (güvenli)

  } catch (error) {
    logger.error('User creation failed', error);
    throw error;
  }
}

---

Faz 4: Data Migration

En Kritik ve Riskli Kısım

Stratejiler:

1. Dual Write + Backfill

┌──────────────────────────────────────────────────┐
│              Timeline                            │
├──────────────────────────────────────────────────┤
│ T0: Sadece Legacy DB                             │
│   [Legacy DB] ← write                            │
│                                                  │
│ T1: Dual Write Başla                             │
│   [Legacy DB] ← write                            │
│   [New DB]    ← write (async, best effort)       │
│                                                  │
│ T2: Backfill (Geçmiş Data Migration)             │
│   [Legacy DB] → [Sync Tool] → [New DB]           │
│   (Historical data copy)                         │
│                                                  │
│ T3: Validation                                   │
│   Compare: Legacy DB vs New DB                   │
│   (Consistency check)                            │
│                                                  │
│ T4: Read from New                                │
│   [New DB] ← read                                │
│   [Legacy DB] ← write (still dual write)         │
│                                                  │
│ T5: Full Cutover                                 │
│   [New DB] ← read & write                        │
│   [Legacy DB] ← decommission                     │
└──────────────────────────────────────────────────┘

2. Change Data Capture (CDC)

// Debezium ile CDC example
// Legacy DB'deki her değişikliği real-time yakalayıp yeni DB'ye uygula

const debezium = require('debezium');

debezium.connect({
  connector: 'mysql',
  host: 'legacy-db.example.com',
  database: 'legacy_db',
  table: 'users'
});

debezium.on('change', async (event) => {
  if (event.operation === 'INSERT') {
    await NewDB.users.create(transformUser(event.data));
  } else if (event.operation === 'UPDATE') {
    await NewDB.users.update(event.data.id, transformUser(event.data));
  } else if (event.operation === 'DELETE') {
    await NewDB.users.delete(event.data.id);
  }
});

function transformUser(legacyUser) {
  // Legacy format → New format transformation
  return {
    id: legacyUser.user_id,        // snake_case → camelCase
    name: legacyUser.full_name,
    email: legacyUser.email_address,
    createdAt: legacyUser.created_date
  };
}

3. Schema Migration

-- Legacy schema
CREATE TABLE users (
  user_id INT PRIMARY KEY,
  full_name VARCHAR(255),
  email_address VARCHAR(255),
  created_date DATETIME
);

-- Modern schema
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name VARCHAR(255) NOT NULL,
  email VARCHAR(255) UNIQUE NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  deleted_at TIMESTAMP NULL  -- Soft delete
);

CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_users_created_at ON users(created_at);

---

Faz 5: Monolith → Microservices Dönüşümü

Domain-Driven Design (DDD) ile Bounded Contexts

E-commerce Domain Model:

┌─────────────────────────────────────────────────────┐
│              Catalog Context                        │
│  - Product                                          │
│  - Category                                         │
│  - Inventory                                        │
└─────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────┐
│              Order Context                          │
│  - Order                                            │
│  - OrderItem                                        │
│  - Shipping                                         │
└─────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────┐
│              Payment Context                        │
│  - Payment                                          │
│  - Transaction                                      │
│  - Refund                                           │
└─────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────┐
│              Customer Context                       │
│  - Customer                                         │
│  - Address                                          │
│  - Wishlist                                         │
└─────────────────────────────────────────────────────┘

Her context → Bir microservice

Communication Patterns:

1. Synchronous (REST API)

// Order Service calls Product Service
const getProduct = async (productId) => {
  try {
    const response = await fetch(`http://product-service/api/products/${productId}`);
    return await response.json();
  } catch (error) {
    // Circuit breaker, fallback
    logger.error('Product service unavailable', error);
    return null; // Graceful degradation
  }
};

2. Asynchronous (Event-Driven)

// Event: OrderCreated
// Product Service subscribes and updates inventory

// Order Service (Publisher)
const EventBus = require('./event-bus');

async function createOrder(orderData) {
  const order = await OrderDB.create(orderData);

  // Publish event
  await EventBus.publish('OrderCreated', {
    orderId: order.id,
    items: order.items,
    customerId: order.customerId,
    timestamp: new Date()
  });

  return order;
}

// Product Service (Subscriber)
EventBus.subscribe('OrderCreated', async (event) => {
  // Update inventory
  for (const item of event.items) {
    await InventoryDB.decrementStock(item.productId, item.quantity);
  }
  logger.info(`Inventory updated for order ${event.orderId}`);
});

3. API Gateway Pattern

Client → API Gateway → Microservices

┌──────────┐
│  Client  │
│ (Web/App)│
└────┬─────┘
     │
     ↓
┌──────────────────────────────┐
│       API Gateway            │
│  - Routing                   │
│  - Authentication            │
│  - Rate limiting             │
│  - Request aggregation       │
└──────────────────────────────┘
     │
     ├────────┬────────┬────────┐
     ↓        ↓        ↓        ↓
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ User   │ │Product │ │ Order  │ │Payment │
│Service │ │Service │ │Service │ │Service │
└────────┘ └────────┘ └────────┘ └────────┘

---

Cloud Migration

Lift and Shift → Cloud-Native

Faz 1: Rehost (IaaS)

On-Premise:
[App Server] + [Database Server] + [File Server]
  (Fiziksel sunucular)

AWS Rehost:
[EC2 Instance] + [RDS Instance] + [EBS Volumes]
  (Aynı setup, virtual)

Değişen: Altyapı fiziksel → virtual
Kod: Hiç değişmiyor

Faz 2: Re-platform (PaaS)

AWS Refactor:
[Elastic Beanstalk] + [RDS] + [S3]

Değişiklikler:
- File storage: Local disk → S3
  app.use('/uploads', express.static('uploads')); // ✗ Eski
  const s3 = new AWS.S3(); // ✓ Yeni

- Session: Memory → Redis/ElastiCache
- Config: Hard-coded → Environment variables
- Logs: File → CloudWatch

Faz 3: Cloud-Native (Containerization + Orchestration)

# Dockerfile
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

# Kubernetes Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: user-service
  template:
    metadata:
      labels:
        app: user-service
    spec:
      containers:
      - name: user-service
        image: user-service:v2.1.0
        ports:
        - containerPort: 3000
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: url
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
  ports:
  - port: 80
    targetPort: 3000
  type: LoadBalancer
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: user-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: user-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Kazançlar:

• Auto-scaling (traffic’e göre otomatik)
• Self-healing (pod çökerse restart)
• Zero-downtime deployment (rolling update)
• Resource efficiency (bin packing)

---

Risk Yönetimi

Potansiyel Riskler ve Mitigation

1. Feature Parity Riski

Risk: Yeni sistemde eski özellik eksik

Mitigation:
- Comprehensive feature inventory (başlangıçta)
- User journey mapping
- UAT (User Acceptance Testing) her fazda
- Regression test suite (automated)
- Beta kullanıcılar (early feedback)

2. Data Loss Riski

Risk: Migration sırasında data kaybı

Mitigation:
- Multiple backups (migration öncesi, sırası, sonrası)
- Dry-run migrations (test environment)
- Dual write period (overlap, redundancy)
- Data validation scripts
- Rollback plan (her zaman)

3. Downtime Riski

Risk: Migration sırasında sistem down

Mitigation:
- Blue-Green Deployment
  Blue (Legacy - çalışıyor)
  Green (New - hazır ama live değil)
  → Switch → Green live, Blue backup

- Canary Deployment
  %5 traffic new → %25 → %50 → %100

- Feature flags
  if (featureFlag.newUserService) {
    return newUserService.getUser(id);
  } else {
    return legacyUserService.getUser(id);
  }

4. Performance Degradation Riski

Risk: Yeni sistem daha yavaş

Mitigation:
- Load testing (pre-production)
  Apache JMeter, k6, Locust
  Hedef: 1000 req/sec, p95 < 200ms

- Performance monitoring (production)
  APM tools: New Relic, Datadog

- Database query optimization
  - Indexes
  - Query analysis (EXPLAIN)
  - N+1 problem'lerini önleme

---

Fiyatlandırma

1. Assessment ve Strateji (Danışmanlık)

Kapsam:

• Kod analizi (SonarQube, dependency check)
• Architecture review
• Modernizasyon stratejisi raporu
• ROI analizi
• Roadmap (12-24 ay)

Süre: 2-4 hafta

Ücret:

• Küçük sistem (< 50K LOC): $8,000-12,000
• Orta sistem (50-200K LOC): $15,000-25,000
• Büyük sistem (200K+ LOC): $30,000-50,000

---

2. Refactoring ve Re-platforming

Örnek: Monolith → Cloud-Optimized Monolith

Scope:

• Rehost to AWS/Azure
• Refactor for cloud services (S3, RDS, etc.)
• CI/CD pipeline setup
• Monitoring ve logging

Süre: 3-6 ay

Ücret:

• Development: $60,000-120,000
• Cloud infrastructure setup: $15,000-30,000
• Training ve documentation: $10,000

Total: $85,000-160,000

---

3. Microservices Transformation

Örnek: Monolith → Microservices (5-10 services)

Faz 1: Foundation (3 ay)

• CI/CD, containerization, Kubernetes setup
• API Gateway, service mesh
• İlk 2 servis migration
• Ücret: $80,000-120,000

Faz 2: Core Services (6 ay)

• 3-5 ana servis migration
• Event-driven architecture
• Data migration
• Ücret: $150,000-250,000

Faz 3: Long Tail (3-6 ay)

• Kalan servisler
• Legacy decommission
• Optimization
• Ücret: $80,000-150,000

Total: $310,000-520,000 (12-15 ay)

Alternatif: Phased payment (aylık $25,000-35,000)

---

4. Full Rebuild

Örnek: Legacy .NET Framework 2.0 → Modern .NET 8 + React

Scope:

• Requirements re-gathering
• Modern architecture design
• Full stack development
• Data migration
• Testing ve QA
• Training

Süre: 12-18 ay

Ücret:

• Küçük uygulama (10-15 ekran): $150,000-250,000
• Orta uygulama (30-50 ekran): $300,000-500,000
• Büyük enterprise app: $500,000-1,000,000+

Risk: Yüksek, önerilmiyor (Strangler pattern tercih)

---

Başarı Hikayeleri

Vaka 1: E-ticaret Platformu - Monolith to Microservices

Durum:

• Şirket: Online perakende, 500K aktif kullanıcı
• Legacy: 12 yıllık PHP monolith, MySQL
• Sorun: Scaling zor, deployment 4 saat, sık outage

Öncesi Metrikler:

Deployment frequency: Ayda 1 kez (riskli)
Lead time for changes: 2-3 hafta
Downtime: Ayda 4-6 saat
Infrastructure cost: $12,000/ay (over-provisioned)
Developer productivity: Yeni feature 3-4 hafta

Modernizasyon Stratejisi:

Faz 1 (3 ay): Foundation

• Docker containerization
• Kubernetes cluster (AWS EKS)
• CI/CD pipeline (GitHub Actions)
• Monitoring stack (Prometheus + Grafana)

Faz 2 (6 ay): Strangler Pattern

Migration sırası:
1. Product Catalog Service (read-heavy, bağımsız)
2. User Service (authentication, profile)
3. Cart Service (session'dan DB'ye taşıma)
4. Order Service (kritik ama iyi bounded)
5. Payment Service (üçüncü-party integration izole)

Her servis:
- Node.js + Express (team biliyordu)
- MongoDB (product, cart) ve PostgreSQL (user, order)
- REST API + gRPC (internal comm)

Faz 3 (3 ay): Optimization

• Event-driven architecture (RabbitMQ)
• Caching layer (Redis)
• CDN for static assets
• Auto-scaling policies

Sonrası Metrikler (12 ay sonra):

Deployment frequency: Günde 10-15 kez
Lead time for changes: 2-3 gün (83% azalma)
Downtime: Ayda 0-10 dakika (99%  iyileşme)
Infrastructure cost: $7,500/ay (%38 azalma + daha performanslı)
Developer productivity: Yeni feature 3-5 gün (%75 hızlanma)
Scalability: Black Friday 15x traffic, 0 issue

ROI:

Yatırım:
- Development (12 ay): $420,000
- Infrastructure migration: $40,000
- Training: $15,000
Total: $475,000

Kazanç (Yıllık):
- Infrastructure savings: $54,000
- Developer productivity (10 dev × 30% faster × $80K salary): $240,000
- Downtime azalması (lost revenue): ~$180,000
Total: $474,000/yıl

ROI: 1 yılda geri ödeme, sonrası her yıl $474K+ kazanç

---

Vaka 2: Finans Kuruluşu - Legacy .NET 2.0 to Cloud-Native

Durum:

• Şirket: Finans teknolojileri, kredi skorlama
• Legacy: .NET Framework 2.0, Windows Server 2008, SQL Server 2008
• Sorun:
  • Güvenlik (Windows 2008 support bitti)
  • Compliance (PCI-DSS, audit fails)
  • Performance (single server, no scale)
  • Talent (kimse .NET 2.0 bilmiyor)

Çözüm:

Replatform Stratejisi (Rebuild yerine)

Faz 1 (2 ay): Lift and Shift

• Windows Server 2008 → Azure VM (Windows Server 2022)
• SQL Server 2008 → Azure SQL Database
• Minimal kod değişikliği
• Immediate benefit: Security patch, backup

Faz 2 (4 ay): Framework Upgrade

• .NET Framework 2.0 → .NET Framework 4.8
  • Incremental: 2.0 → 3.5 → 4.0 → 4.8
  • Her adımda test, deploy, validate
• Breaking changes fix
• Automated test yazma (regression)

Faz 3 (6 ay): Modernization

• .NET Framework 4.8 → .NET 8 (cross-platform)
• Monolith → Modular monolith (microservices’e hazırlık)
  • Scoring engine modul
  • API layer refactor
  • Background jobs separation
• Containerization (Docker)
• Azure Kubernetes Service deployment

Faz 4 (3 ay): Cloud-Native Features

• Azure Active Directory integration (SSO)
• Application Insights (monitoring, telemetry)
• Azure Key Vault (secrets management)
• Auto-scaling rules
• Multi-region deployment (DR)

Sonuçlar (15 ay sonra):

Güvenlik:
- Windows 2008 → 2022 (patched, supported)
- .NET 2.0 → .NET 8 (modern security features)
- Compliance: PCI-DSS passed, SOC 2 Type II certified

Performance:
- Single server → Auto-scaled (2-10 instances)
- Response time: 800ms → 120ms (%85 iyileşme)
- Throughput: 100 req/sec → 2000 req/sec

Reliability:
- Uptime: %97 → %99.95
- RTO: 4 saat → 15 dakika
- RPO: 24 saat → 5 dakika

Cost:
- On-prem: $18,000/ay (hardware, license, DC)
- Azure: $14,000/ay (%22 azalma)

Developer Experience:
- .NET 2.0 bilmek zorunda → Modern C#
- Deployment: Manuel, 6 saat → Automated, 15 dakika
- Yeni dev onboarding: 3 ay → 2 hafta

ROI:

Yatırım: $380,000 (15 ay)

Kazanç:
- Infrastructure: $48,000/yıl
- Downtime prevention: ~$120,000/yıl
- Developer productivity: ~$100,000/yıl
- Compliance (fine prevention): Priceless
Total: $268,000+/yıl

ROI: ~17 ayda geri ödeme

---

Sık Sorulan Sorular

Strateji

S: Modernizasyon mı yoksa rebuild mi? Nasıl karar veririm?

C: Decision tree:

1. Sistem kritik mi, downtime tolere edilemez mi?
   → Evet: Strangler pattern (aşamalı)
   → Hayır: Değerlendir

2. Code quality nasıl? (Technical debt seviyesi)
   → Anlaşılır, test edilebilir: Refactor/Rearchitect
   → Spagetti, kimse anlamıyor: Rebuild (son çare)

3. Business value var mı rebuild'de?
   → Sadece aynı features: Rebuild değmez
   → Yeni features, yeni model: Rebuild düşünülebilir

4. Zaman ve bütçe?
   → Limitli: Refactor/Replatform (pragmatik)
   → Bol: Rearchitect (ideal ama lüks)

Önerimiz: %90 durumda Strangler pattern (incremental modernization)

S: Tüm sistemi bir anda mı migrate edelim, yoksa aşamalı mı?

C: Aşamalı, kesinlikle. Neden:

• Risk minimize (bir modül başarısız olsa bile, sistem çalışıyor)
• Öğrenme (her modülde öğrendiklerinizi sonrakine uygulama)
• Business value (her adımda value deliver, %100 bitene kadar bekleme yok)
• Rollback kolay
• Budget spread (tüm bütçeyi başta harcama)

---

Teknik

S: Microservices’e geçmeli miyiz?

C: “It depends.” Microservices magic değil, trade-off:

Ne zaman evet:

• ✓ Büyük ekip (50+ developer)
• ✓ Yüksek scale ihtiyacı (farklı parçalar farklı scale)
• ✓ Sık deployment (her gün, hatta saatte)
• ✓ Polyglot (farklı diller/teknolojiler)

Ne zaman hayır (Modular monolith yeterli):

• ✗ Küçük ekip (< 10 developer)
• ✗ Startup (hız lazım, complexity değil)
• ✗ Low traffic (ölçeklendirme sorun değil)
• ✗ Tightly coupled domain

Unutmayın: “Monolith First” (Martin Fowler) - İlk başta monolith iyi, sonra split.

S: Data migration en riskli kısım, nasıl güvenli yaparız?

C: Katmanlı yaklaşım:

1. Backups (Paranoid level)

- Full backup (migration öncesi)
- Incremental backups (her adımda)
- Test restore (backup'lar çalışıyor mu?)
- Immutable storage (S3 versioning)

2. Dry Runs

- Test environment'ta 5-10 kez migrate et
- Her seferinde yeni öğreniyorsun, script iyileştiriyorsun
- Production'da ilk kez değil

3. Validation Scripts

-- Row count check
SELECT
  'legacy' as source, COUNT(*) as count FROM legacy.users
UNION ALL
SELECT
  'new' as source, COUNT(*) as count FROM new.users;

-- Data integrity check
SELECT user_id FROM legacy.users
WHERE user_id NOT IN (SELECT id FROM new.users);
-- Eksik kayıt var mı?

-- Checksum validation
SELECT SUM(CAST(user_id AS BIGINT)) FROM legacy.users;
SELECT SUM(CAST(id AS BIGINT)) FROM new.users;
-- Toplam eşleşiyor mu?

4. Rollback Plan

Her zaman rollback planı:
- Dual write period (her iki DB de güncel)
- Feature flag (eski DB'ye dön)
- DNS switch (worst case, eski sunucuya dön)

---

Maliyet ve ROI

S: Modernizasyon ROI’si nedir? Bütçeyi nasıl justifylarım?

C: TCO (Total Cost of Ownership) hesabı:

Legacy TCO (Yıllık):

Infrastructure: $15,000 (eski sunucular, lisans)
Maintenance: $120,000 (developer time, %60'ı sadece bugfix)
Downtime: $80,000 (lost revenue, SLA penalty)
Security risk: $?? (Breach cost unknown ama high risk)
Opportunity cost: $?? (Yeni feature yapamama)
---------------------------------------------------------
Total: $215,000+

Modernize TCO (Yıllık, migration sonrası):

Infrastructure: $10,000 (cloud, efficiency)
Maintenance: $50,000 (developer time, %80'i yeni features)
Downtime: $10,000 (minimal, HA architecture)
Security: Low risk (modern, patched)
New features: Competitive advantage
---------------------------------------------------------
Total: $70,000

Savings: $145,000/yıl

Migration Cost: $300,000 (one-time)

ROI: $300K / $145K/year = 2 yıl geri ödeme

Sonrası: Her yıl $145K+ savings/benefit

---

Organizasyonel

S: Ekibimiz eski teknolojilerde uzman, yeni teknolojileri öğrenebilirler mi?

C: Evet, ama structured approach:

1. Training (Formal)

• Online courses (Udemy, Pluralsight, etc.)
• Workshops (1-2 hafta intensive)
• Certification programs (optional ama motivasyon)

2. Pairing (Pratik)

• Senior dev + junior dev pairing
• Code review culture
• Knowledge sharing sessions

3. Safe-to-fail Environment

• Non-production pilot projects
• Hackathons
• “Learning time” (Friday afternoon, etc.)

4. Hiring (Hybrid)

• 1-2 experienced developer in new tech (seed the team)
• They mentor existing team

Deneyim: Genellikle team adapt ediyor, modern tech daha kolay (developer-friendly)

---

Hemen Başlayın

Adım 1: Ücretsiz Modernizasyon Assessment

1 saatlik system review:

• Codebase overview (ne kadar eski, ne kadar karmaşık?)
• Pain points neler? (deployment, performance, talent?)
• Current costs (infrastructure, maintenance)
• Strategic goals (business objectives)

Çıktı:

• Modernization readiness score
• Recommended strategy (Rehost, Refactor, Rearchitect)
• Ballpark estimate (time, cost)
• ROI projection

Adım 2: Pilot Project

Önerilen yaklaşım: Bir modül ile başla

• Low-risk, high-value module seç
• 8-12 hafta pilot
• Success metrics tanımla
• Learnings’i dokümante et

Adım 3: Full Roadmap

Pilot başarılıysa:

• 12-24 aylık modernization roadmap
• Phased approach
• Budget allocation
• Team ramp-up plan

---

İlgili Çözümler:

• Kurumsal Yazılım Danışmanlığı
• Sistem Entegrasyonu
• Cloud DevOps
• Mikroservis Mimarisi

Popüler Aramalar: yazılım modernizasyonu, legacy migration, kod refactoring, monolith to microservices, cloud migration, sistem yenileme, teknoloji güncelleme, eski yazılım yenileme