1. Legacy Projeyi Devralırken İlk Adımlar
İlk adım “koda bakmak” değil, erişimi ve sahipliği netleştirmektir. Domain/DNS, hosting, repo, deploy pipeline, izleme araçları… Bunlardan biri eksikse, envanter ve risk haritası çıkarmadan teknik analiz bile sağlıklı ilerlemez.
24–72 saat içinde netleştirilecekler (minimum set)
- •Domain/DNS erişimi, CDN/WAF panel erişimi
- •Hosting/Cloud hesabı, prod/staging erişimleri
- •Repo erişimi, branch stratejisi, CI/CD
- •Log/monitoring araçları (varsa), alert kanalları
- •3rd-party entegrasyon listesi (otel: PMS/OTA/rezervasyon; B2B: CRM/ödeme/SSO)
Soru : Legacy web projesi devralırken ilk 90 günde ne yapmalıyım?
Cevap: İlk günlerde erişimleri, envanteri ve devralma dokümantasyonu setini toparlayın; ilk 2–4 haftada risk haritası çıkarıp monitoring kurun; sonra quick win’lerle kritik akışları stabilize edip 90 gün sonunda orta vadeli roadmap ve iletişim ritmini netleştirin.
Ne yapmalıyım?
- • Erişim envanteri olmadan prod’a dokunma.
- • “Kritik akış listesi” çıkar; test senaryosu yaz.
- • İlk hafta içinde iletişim kanallarını ve escalation’ı belirle.
2. Teknik Envanter ve Risk Haritası
Erişimler tamamlandıktan sonra hedef; teknik borç envanteri çıkarırken teknik borcu “hisle” değil, kanıtla görünür kılmaktır. Envanter, risk haritasının hammaddesidir.
Teknik envanter bileşenleri
- •Uygulama stack’i: framework, runtime, bağımlılıklar
- •Altyapı: server/container, CDN, DB, cache
- •Deploy zinciri: build, artifact, rollback yöntemi
- •Güvenlik: IAM, MFA, secrets yönetimi, patch durumu
- •SEO/performans: CWV, indexability, redirect/canonical durumları
Teknik + güvenlik risklerini görünür kılmak için; erişim güvenliği, bağımlılık durumu, yönlendirme yapısı ve özellikle legacy projelerde teknik SEO riskleri birlikte değerlendirilmelidir:
- •Sunucu ve erişim güvenliği kontrolü
- •Crawl, indexleme, canonical ve Core Web Vitals kontrolü
- •Legacy kod, bağımlılık ve altyapı bileşen envanteri
Risk haritası (risk-first maintenance)
Basit ama işe yarayan format: Risk → Etki → Olasılık → Kanıt → Aksiyon
- •Etki: gelir akışı, güvenlik, marka, operasyon
- •Olasılık: sık tekrar, eski stack, kontrol eksikliği
Key Statistics / Data Point (yumuşatılmış): Yapılandırılmış envanter ve risk analizi yapılan projelerde, ileride çıkacak büyük bakım işlerinin önceden roadmap’e alınabildiği sık görülür.
Ne yapmalıyım?
- • Riskleri 3 seviyeye ayır: kritik/yüksek/orta.
- • Kritik riskleri önce “stabilize et”, sonra “iyileştir”.
- • Risk haritasını yönetimle 1 sayfada paylaş.
3. Hızlı Kazanımlar (Quick Wins) vs Büyük Sorunlar
Quick win; düşük eforla yüksek risk azaltan iştir. Büyük sorunlar ise parçalanarak roadmap’e alınmalıdır. En büyük hata, ilk 2 haftada “büyük yeniden yazım”a kalkışmaktır.
Quick win örnekleri
- •Monitoring ve temel alarmlar (uptime, error rate)
- •Güvenlik: MFA, kritik secrets rotasyonu, temel patch
- •Rezervasyon/login gibi kritik akışlarda smoke test
- •404/500 artışı yapan noktalarda hızlı fix
- •Basit cache/CDN ayar düzeltmeleri
Büyük sorun (big rock) örnekleri
- •Major versiyon upgrade / kapsamlı refactor
- •Mimari yeniden düzenleme
- •Entegrasyonların yeniden tasarımı
- •Büyük SEO mimarisi değişiklikleri
Soru : Hızlı kazanım (quick win) ve büyük riskleri nasıl ayırırım?
Cevap: Quick win, düşük eforla kritik risk veya kullanıcı etkisini hızla düşüren iştir (monitoring, MFA, kritik akış smoke test). Büyük riskler ise yüksek eforlu ve çok bileşen etkileyen işlerdir; parçalanıp ilk 90 gün bakım stratejisi ile roadmap’e alınmalı ve change yönetimiyle yürütülmelidir.
Ne yapmalıyım?
- • İlk 2 haftayı quick win + stabilizasyon haftası yap.
- • Big rock’ları roadmap’e slotla (tek seferde yüklenme).
- • Her quick win sonrası ölç: incident azaldı mı, MTTR düştü mü?
4. İletişim ve Beklenti Yönetimi
Legacy devralmada başarısızlık çoğu zaman iletişimden gelir: “Ne yaptınız?” sorusu yanıtsız kalırsa güven düşer. İlk 90 gün boyunca düzenli ritim ve ilk 90 gün risk ve quick win raporlaması şarttır.
Haftalık ritim önerisi
- •15 dk durum özeti: yapılanlar / riskler / sıradaki
- •“Kritik akış sağlığı” raporu (otel: rezervasyon; B2B: login/rapor)
- •Açık riskler ve mitigasyon planı
Yönetim dili: risk ve değer
- •Risk azalması (kritik açıklar kapandı)
- •Operasyon sürekliliği (uptime, hata oranı)
- •Hız ve güven (deploy geri alma ihtiyacı azalıyor)
Ne yapmalıyım?
- • İlk hafta: iletişim ritmini kilitle.
- • Her hafta: risk haritasını güncelle (kapanan riskler).
- • 90 gün sonunda: roadmap + SLA + süreç önerisiyle kapanış sunumu yap.
5. Otel ve B2B İçin İlk 90 Gün Planı
İlk 90 gün planını fazlara bölmek, hem teknik hem iş tarafında öngörü yaratır. Aşağıdaki fazlar; otel ve B2B kritik akışlarına göre uyarlanmıştır. Özellikle otel web projelerinde legacy devralma, rezervasyon akışı, kampanya performansı ve sezon hazırlığıyla birlikte ele alınmalıdır.
Faz-1 (Gün 1–14): Erişim + Envanter + Stabilizasyon
- •Erişim envanteri (DNS/hosting/repo/secrets)
- •Kritik akış smoke test
- •Monitoring/log kurulumu
- •İlk quick win’ler
Faz-2 (Gün 15–45): Risk haritası + güvenlik/performans ilk düzeltmeler
- •Güvenlik taraması ve patch planı
- •Performans/CWV baseline
- •Entegrasyon health kontrolleri
- •Big rock backlog’u parçalama
Faz-3 (Gün 46–90): Roadmap + süreç standardı + kalibrasyon
- •Change yönetimi ve release takvimi önerisi
- •SLA/ticketing alan seti (varsa)
- •Dokümantasyon/runbook başlatma
- •6–12 ay bakım/ürün roadmap hizası
Ne yapmalıyım?
- • Fazları tarihle yaz ve yönetimle paylaş.
- • Her faz sonunda “kapanış ölçümü” yap (risk, KPI).
- • 90 gün sonunda sürdürülebilir bakım modeline geç (SLA, ticketing, runbook).
6. Legacy Web Projesi İlk 90 Gün Envanter & Risk Checklist’ini İndir — Yazılım / Legacy Devralma (v1.0)
Legacy Web Projesi İlk 90 Gün Envanter & Risk Checklist’ini İndir — Yazılım / Legacy Devralma (v1.0)
Bu checklist; legacy proje devralırken erişim/altyapı envanterini toparlamayı, risk haritasını çıkarmayı, monitoring/log kurulumunu ve quick win’lerle stabilizasyonu 90 gün faz planına bağlamayı sağlar. Otel projelerinde rezervasyon/entegrasyon; B2B’de login/raporlama akışlarını önceliklendirir. Amaç, rastgele müdahaleyi azaltıp kontrollü iyileştirmeye geçmektir.
Kim Kullanır?
Ajans/dev lead + PM/ops + müşteri tarafı owner (ortak yürütür).
Nasıl Kullanılır?
- Gün 1–14 envanter ve erişimleri tamamla, kritik akışları stabilize et.
- Gün 15–45 risk haritasını çıkar, güvenlik/perf bulgularını kapatmaya başla.
- Gün 46–90 roadmap ve süreç standardını kur; sürdürülebilir bakıma geç.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Domain/DNS/CDN/WAF erişimleri tamam
- ▢ ✅ Hosting/Cloud + prod/staging erişimleri tamam
- ▢ ✅ Repo + CI/CD + rollback yöntemi net
- ▢ ✅ Secrets/IAM/MFA kontrol edildi
- ▢ ✅ Entegrasyon listesi çıkarıldı (otel: PMS/OTA/rez; B2B: SSO/CRM/ödeme)
- ▢ ✅ Monitoring/log + alert kanalı kuruldu
- ▢ ✅ Kritik akış smoke test senaryosu yazıldı
- ▢ ✅ Risk haritası (ilk 10) ve sahipleri belirlendi
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
7. Competitor Gap’i Kapatan “İlk 90 Gün Bakım Modeli”
TR’de legacy devralma çoğu zaman “kod okuyalım” seviyesinde kalır; erişim, risk haritası, monitoring ve iletişim ritmi birlikte ele alınmaz. Bu rehberin farkı; 90 günü fazlara bölüp “kontrollü onboarding” modelini otel/B2B kritik akışlarına bağlamasıdır.
Süreç sonunda yalnız sorun listesi değil, uygulanabilir bir plan görmek istiyorsanız Bakım ve Destek hizmetiyle legacy takeover planınızı kontrollü başlatın. Kapsam, destek modeli ve ilk analiz süreciyle ilgili detaylar için Bakım ve Destek hakkında sık sorulan sorular sayfasına da bakabilirsiniz.
Bir Sonraki Adım
Devralma sürecini risk-first yaklaşımla yönetip sürpriz krizleri azaltmak isteyen ajans ve otel/B2B ekipleri için.
Sık Sorulan Sorular
Legacy web projesi devralırken ilk 90 günde ne yapmalıyım?▾
Kod ve altyapı envanteri nasıl çıkarılır?▾
Otel/B2B legacy projesi için nereden başlamalıyım?▾
Hızlı kazanım (quick win) ve büyük riskleri nasıl ayırırım?▾
Devralma sürecinde iletişimi nasıl yönetmeliyim?▾
İlgili İçerikler