Microsoft Repolarını GitHub’a Taşıyor: Sahadan Notlar

Birkaç hafta önce bir müşterimde toplantıdaydık. Banka, Azure Repos üzerinde yaklaşık 600 repo yönetiyor (ki bu çoğu kişinin gözünden kaçıyor). Sorun şuydu: GitHub Copilot’un yeni agent özelliklerini görmüşler, “biz de bunu kullanalım” diyorlar — ama kod hâlâ Azure DevOps’ta. Toplantıda ortaya atılan soru aslında basitti: “Taşıyalım mı, taşımayalım mı?”

Cevap o kadar basit değil tabi. Microsoft kendi içinde bu işi nasıl yapıyor, ne kadar can yakmış, neyi öğrenmiş — bunlara bakmadan karar vermek bence hata ölür. Build 2026’da paylaşılan rakamlar ve özellikle Copilot, Agents, and Platforms (CAP) ekibinin tecrübesi, bu sorunun cevabını netleştirmek için baya malzeme veriyor. Ben de bu yazıda hem onların yaşadıklarını hem de kendi sahadan gözlemlerimi bir araya getirmek istiyorum.

Önce rakamlara bakalım: CAP ekibi ne yaptı?

Microsoft’un Copilot, Agents and Platforms organizasyonu — kısaca CAP — 53 ayrı Azure DevOps organizasyonu üstünde yaklaşık 4.000 aktif repo yönetiyordu. Dynamics CRM, omnichannel CRM gıbı hayatı servisleri düşünün; ufak bir startup hikâyesi değil bu, bayağı ciddi bir operasyon.

Altı ay içinde bu repoların yüzde 80’inden fazlasını GitHub’a taşımışlar. Sayıya vurunca 1.600+ repo ve 3.100+ geliştirici çıkıyor. Ekip kaç kişiymiş? İki engineering lead ve küçük bir destek grubu. Yanı ortada devasa bir migration army yok, tam tersine işin içi biraz şaşırtıcı derecede sade duruyor.

Bu rakamı ilk gördüğümde açık konuşayım, biraz duraksadım. Çünkü sahada repo taşımanın nasıl can sıktığını iyi biliyorum; 2019’da bir telekom müşterimde sadece 80 repo’yu TFVC’den Git’e almak iki ayımızı yemişti, testler uzadı, kenar durumlar çıktı, ekip de ara ara “bu iş neden bu kadar uzadı” diye birbirine baktı. Şimdi 1.600 repo, altı ay, küçük ekip… hmm, demek ki araçlar epey toparlamış. Ama işin aslı şu: Microsoft’un en karışık monorepoları hâlâ Azure DevOps’ta duruyor. “hepsini taşıdık, bitti gitti” değil bu hikâye. Daha çok “çoğunu düzgünce aldık, zor parçaları sona bıraktık” gıbı.

“Repo’nün nerede yaşadığı, artık AI’dan ne kadar değer ürettiğinizi doğrudan etkileyen stratejik bir karar.” — Bu cümleyi Build oturumunda duyduğumda not aldım. Sahada da aynen böyle.

Niye şimdi? AI denklemi değiştirdi

Açık konuşayım, üç yıl önce biri bana “Azure Repos’tan GitHub’a geç” deseydi, muhtemelen “ne gerek var” derdim (buna dikkat edin). İkisi de Git, ikisi de Microsoft tarafında duruyor, fiyatlar da aşağı yukarı belli; ama 2025-2026 dönemi işi biraz bozdu, hatta bayağı bozdu.

GitHub Copilot Coding Agent, Code Review ajanı, Copilot Chat’in repo bağlamlı çalışması, agentic capabilities… Bunlar önce GitHub’da çıkıyor. Azure Repos tarafına entegrasyon ya gecikmeli geliyor ya da bazı özelliklerde hiç gelmiyor. Yanı “AI-native” geliştirme yapmak istiyorsanız, repo’nün GitHub’da olması artık sadece güzel bir fikir değil; açıkçası neredeyse zorunluluk gıbı duruyor.

Bir de işin ekip tarafı var. Şöyle bir soru hep geliyor: “Repo GitHub’a giderse Azure Boards’taki iş yönetimimiz ne olacak, Azure Pipelines’taki build düzeni dağılıp gider mi?” Cevap kısa: gitmiyor. Boards ve Pipelines, GitHub repolarına bağlanabiliyor; yanı sancılı olan kısım çoğunlukla sadece kodun durduğu yer oluyor (iş takibi ve CI/CD aynı çizgide kalabiliyor), geri kalan taraf pek sarsılmıyor (ben de ilk duyduğumda şaşırmıştım)

Çok konuştum, örnekle göstereyim.

Bu arada benzer bir konu için CodeQL 2.25.5 Çıktı: GitHub Actions Taramaları Keskinleşti yazısına da bakmanızı öneririm — güvenlik tarafında GitHub dünyainin nereye kaydığını gayet net gösteriyor.

Taşıma araçları: GEI ve ELM

Burada iki ana araç var, ama işin rengi biraz senaryoya göre değişiyor: (kendi tecrübem)

• GitHub Enterprise Importer (GEI): Toplu, batch tarzı taşıma için kullanılıyor. Repo’yu kısa bir süreliğine kilitliyorsunuz, taşıyorsunuz, sonra developer’lar yeni adresten devam ediyor. Klasik yol bu.
• Enterprise Live Migrator (ELM): Bu daha yeni bir seçenek ve açık konuşayım, asıl farkı burada hissediyorsunuz. Geliştirme akışını kesmeden, repo aktifken taşıma yapmanıza izin veriyor. Hele bir de büyük monorepolar ve 7/24 çalışan ekipler için baya iş görüyor.

Bilmem anlatabiliyor muyum, Sahada şunu gördüm: Küçük-orta repolarda GEI fazlasıyla yeterli oluyor. Bir cumartesi gecesi planlanıyor, pazar sabahına kadar iş bitiyor; yanı kimse çok dramatik bir şey yaşamıyor. Ama 50+ GB’lık bir monorepo varsa. Gece-gündüz commit alıyorsa, o kilitleme penceresi insanın canını sıkabiliyor (hele release baskısı da varsa). ELM tam burada devreye giriyor.

İşte, araya gireyim: Evet.

Hangı senaryoda hangı araç?

İşte, peki neden?

Senaryo	Önerilen Araç	Yaklaşık Kesinti
10-200 repo, küçük-orta boy	GEI	Repo başına 5-30 dk
Büyük monorepo (10GB+)	ELM	Neredeyse sıfır
7/24 çalışan hayatı servis	ELM	Sıfır kesinti hedefi
Arşiv / nadiren commit alan repo	GEI	Önemsiz
LFS yoğun repo	GEI + manuel LFS	Planlı bakım

Şunu söyleyeyim, Lafı gevelemeden söyleyeyim: tablo aslında basit görünüyor ama pratikte karar bazen öyle düz ölmüyor. Mesela repo sayısı az olsa bile, eğer ekip sürekli push atıyorsa ya da LFS tarafı kabarıksa, GEI’nın “kısa kesinti” dediğiniz kısmı bir anda uzayabiliyor; buna karşılık ELM de her yerde sihirli değnek gıbı çalışmıyor.

Tam da öyle.

Şunu söyleyeyim, Neyse, çok dağıtmadan toparlayayım: düşük riskli ve sakın ortamlarda GEI hâlâ gayet mantıklı duruyor; canlılığın yüksek olduğu yerlerde işe ELM daha rahat ettiriyor. Bakın, siz ne dersiniz? Daha fazla bilgi için Kubernetes v1.36: Askıdaki Job’lara Kaynak Ayarı Geldi yazımıza bakabilirsiniz.

Pratik bir taşıma akışı: Adım adım ne yapıyoruz?

Geçen ay bir e-ticaret müşterimde 120 repoyu taşıdık. Şu adımları izledik; paylaşıyorum çünkü internette gördüğünüz dokümanlar genelde sadece “happy path” gösteriyor, işin çamurlu kısmını pek anlatmıyor.

1. Envanter çıkar. Hangı repo aktif, hangisi ölü, hangisi sahipsiz? Sahipsiz repolar için sahip bulmadan taşıma yapmayın; yoksa sonra “bu kimin?” muhabbetiyle uğraşırsınız, gereksiz yere vakit gider.
2. Bağımlılık haritası çıkar. Pipeline’lar hangı repolara bağlı? Service connection’lar nerede kullanılıyor? PAT token’lar kimde duruyor? Bunları önceden listeleyin, yoksa taşırken bir yerden patlıyor.
3. Pilot grup seç. 5-10 düşük riskli repo ile başlayın. Süreci öğrenin, hata yapın, ama ucuz hata yapın; yanı production’ın ortasında değil, daha sakın yerde takılın.
4. İletişim planı. “Pazartesi sabahı taşındık” diye developer’ı şaşırtmak en kötüsü. En az iki hafta önceden duyurun, hatta mümkünse küçük bir hatırlatma daha geçin; insanlar sürprizi sevmiyor.
5. Boards ve Pipelines bağlantılarını güncelle. GitHub Service Connection oluşturun, PR trigger’larını test edin. Burada iş biraz teknikleşiyor, ama açık konuşayım, asıl sorun çoğu zaman ayar değil alışkanlık oluyor.
6. Eski repoyu read-only yap, silme. En az 90 gün saklayın. “Bir yerde bir branch unutmuştuk” derdine düşersiniz; sonra herkes birbirine bakar, kimse tam emin olmaz. Evet, başa bela olabilir.

# GEI ile basit bir repo taşıma örneği
gh ado2gh migrate-repo \
--ado-source-org "myorg" \
--ado-team-project "myproject" \
--ado-repo "myrepo" \
--github-target-org "mygh-org" \
--github-target-repo "myrepo"
# Toplu taşıma için generate-script:
gh ado2gh generate-script \
--ado-source-org "myorg" \
--output migrate.ps1

Size bir şey söyleyeyim, Neyse uzatmayalım. Bu tıp geçişlerde en kritik konu araç değil; sıralama doğru olsun yeter. Yanlış sırayla giderseniz işler uzuyor, doğru sırayla giderseniz de şaşırtıcı biçimde daha az kriz çıkıyor.

Peki neden?

Şunu fark ettim: Cevap basit: önce neyi taşıdığınızı bilmeniz gerekiyor, sonra bağımlılıkları görmeniz lazım, en son da sistemi sessizce yeni yere alıştırmanız gerekiyor. İşte, siz ne dersiniz?

Türkiye’deki şirketler açısından durum

Şimdi gelelim asıl meseleye. Türkiye tarafında bu iş nasıl dönüyor, ona bakalım. Global trend bir yana, bizde iş biraz başka akıyor, hatta bazen aynı ürün bambaşka bir dert gıbı hissediliyor. Daha fazla bilgi için Foundry Managed Compute: Açık Modelleri Kendi GPU’nuzda yazımıza bakabilirsiniz.

Şimdi, size bir şey söyleyeyim, Birinçisi: Veri ikamet sorunu. Finans, kamu. Telekomda “kod nerede duracak?” sorusu hâlâ kritik. GitHub Enterprise Cloud’un data residency seçeneklerine AB bölgesi eklendi — bu iyi bir adım. Ama Türkiye bölgesi yok hâlâ. Bankacılık projelerinde gördüğüm kadarıyla, bazı kurumlar için bu durum doğrudan “GitHub Enterprise Server (self-hosted)” zorunluluğuna dönüyor; yanı bulutta kalmak istiyorlar ama regülasyon kapıya dayanıyor. Bulutta kalmak isteyen ama mevzuata takılan kurumlar için ya AB residency kabul edilebilir bir ara çözüm oluyor, ya da Azure Repos daha kalıcı bir seçenek olarak masada duruyor.

İkincisi: Maliyet hesabı. Azure DevOps’un kullanıcı başı fiyatı ile GitHub Enterprise’ın kullanıcı başı fiyatı ilk bakışta birbirine yakın görünebilir. Ama Copilot Business veya Enterprise eklediğiniz anda tablo değişiyor, çünkü kullanıcı başına aylık maliyet bir anda yukarı fırlıyor. TL bazında düşününce 500 kişilik bir geliştirme ekibi için yıllık fark, bütçe komitelerinde kaş kaldırttırabilecek seviyeye geliyor. Buradaki ana soru şu: AI özelliklerinden gerçekten kaç developer faydalanacak? Hepsine vermek zorunda değilsiniz. Copilot Usage Metrics API: Artık Kohortlu AI Adopsiyon Devri yazısında da anlattığım gıbı, kohort bazlı kullanım takibi yapıp lisansları akıllıca dağıtmak baya iş görüyor. Daha fazla bilgi için Foundry Agent Optimizer: Prompt’u Makine Yazsın Devri yazımıza bakabilirsiniz. Bu konuyla ilgili Microsoft konusundaki yazımız yazımıza da göz atmanızı tavsiye ederim.

Hmm, bunu nasıl anlatsamdı…

Üçüncüsü: Kültürel direnç. Bu daha sinsi bir konu, açık konuşayım. 10 yıldır Azure Repos kullanan ekipler için GitHub’ın PR akışı, yetkilendirme modeli. Branch protection ayarları — kendi adıma konuşayım — ilk anda biraz yabancı geliyor; hani sistem kötü olduğu için değil, alışkanlık başka yere oturduğu için. Eğitim ihtiyacı da burada ortaya çıkıyor. Birkaç şirkette şunu gördüm: Taşıma yapılıyor, herkes “tamamdır” diyor,. Developer’lar yeni özelliklerin %30’unu bile kullanmıyor (bazısı bilerek dokunmuyor, bazısı da neyi niye yaptığını anlamıyor). Buna hazırlıklı olmak lazım.

Araya gireyim: Evet. Daha fazla bilgi için Gateway API’yi kind ile Deneme: Lokal Lab Kurulumu yazımıza bakabilirsiniz.

Neyse uzatmayalım; Türkiye’de mesele sadece teknik seçim değil, veri yerleşimi, bütçe ve ekip alışkanlığı aynı anda masaya geliyor. Siz ne dersiniz?

Enterprise mi startup mı? Karar matrisi

Küçük ekip / startup iseniz

Peki, bilmem anlatabiliyor muyum, Lafı dolandırmadan söyleyeyim: GitHub’a geçin. Zaten büyük ihtimalle oradasınız,. Işin bir kısmı çoktan çözülmüş oluyor; Azure Repos’un kurumsal tarafta verdiği o sıkı entegrasyonlar (Boards ile bağlantı, Test Plans tarafı, falan) size pek dokunmuyorsa, açıkçası burada kalmanın ekstra bir getirisi yok (ben de ilk duyduğumda şaşırmıştım). AI özellikleri var, ekosistem geniş, açık kaynak tarafı da baya iş görüyor.

Orta ölçekli şirket (50-500 developer)

Burada hibrit model bana daha mantıklı geliyor, ama hemen atlamayın (bizzat test ettim). Yeni projeleri GitHub’da başlatın, mevcut Azure Repos işlerini de öyle bir anda söküp atmayın; bakım modunda tutmak çoğu zaman daha az sancılı oluyor. Acele etmeyin. Bir yandan ELM olgunlaşırken, siz de eğitim, süreç. Ekip alışkanlıklarını hazırlarsınız (çünkü asıl mesele tool değil, geçişi taşıyan insanlar). 12-18 aylık bir plan kulağa uzun geliyor ama gerçekçi olan da bu.

Şimdi gelelim işin can alıcı noktasına.

Büyük kurumsal (500+ developer, regülasyon ağır)

Burada üç soruyu cevaplamadan tek adım atmayın:

1. Veri ikametinde AB benim için yeterli mi, yoksa Türkiye’de fiziksel sunucu mu lazım?
2. Copilot lisans maliyetimi karşılayabilir mıyım, yoksa kısmi geçiş mi yapayım?
3. Mevcut Azure Pipelines yatırımım ne olacak — GitHub Actions’a mı taşıyayım, hibrit mi gideyim?

Bu sorular netleşmeden başlayan bir migration, ortada kalıyor. Maalesef. Ben bunu gördüm; hem de birkaç kez. Hani kağıt üstünde her şey tamam gıbı duruyor ya, sonra compliance ekibi başka konuşuyor, altyapı tarafı başka yere çekiyor, iş bir anda uzayıp gidiyor. Neyse uzatmayalım: önce çerçeveyi çizin, sonra taşıma işine girin.

Sahadan bir hata hikâyesi

Kısacası, geçen ay bir taşımada garip bir şey öldü: GEI ile 40 repo taşıdık, ilk bakışta her şey yolundaydı. Ama iki gün sonra build pipeline’larından biri takılmaya başladı (yanlış duymadınız). Sebep de şuydu; pipeline, GitHub’daki yeni repo’ya bağlanmıştı ama branch policy “main” diye arıyordu. Eski Azure Repos’ta default branch “master” idi, GEI bunu da aynen taşımıştı. Yeni GitHub repo’sunda da “master” olarak kalmıştı. Fakat ekipten biri, hani şu “modernleşelim” refleksiyle, GitHub tarafında default’u “main”e çevirmişti; kimse de pipeline ayarına dönüp bakmamıştı.

Şöyle söyleyeyim, Çözüm aslında basitti, ama tespiti epey vakit yedi (en azından benim deneyimim böyle). Evet. Buradaki ders net: Taşıma sonrası ilk hafta, bütün pipeline’ların yeşil kaldığını günde bir gözle takıp edin. Otomatik alert’ler fena değil, iş görüyor; ama bazen ekranın başına geçip kendi gözünüzle bakmanız gerekiyor, çünkü küçük bir branch adı bile bütün akışı sessizce bozabiliyor.

Evet, doğru duydunuz.

Boards ve Pipelines — bunlar ne olacak?

En sık gelen soru bu. Olduğu gıbı kalıyor, kısacası. Microsoft da zaten bunu açık açık söylüyor: GitHub’a geçin ama Azure Boards ve Azure Pipelines’ı kullanmaya devam edin; yanı illa full GitHub stack’e atlamak zorunda değilsiniz, işin aslı biraz daha rahat (inanın bana)

Boards ile GitHub entegrasyonu artık baya oturmuş durumda. Issue’lar work item’lara bağlanabiliyor, commit mesajına “AB#1234” yazınca ilişki otomatik kuruluyor; Pipelines tarafında da GitHub Service Connection üzerinden trigger’lar çalışıyor, secret’lar güvenli şekilde akıyor, hani parçalı geçiş dediğimiz model tam burada iş görüyor. Hatta büyük kurumların bir kısmı için bu yol, düz geçişten daha mantıklı bile gelebiliyor.

Ve işler burada ilginçleşiyor.

Sıkça Sorulan Sorular

Azure Repos’tan GitHub’a geçmek zorunda mıyım?

Kısaca hayır. Azure Repos kapanmıyor, hâlâ aktif olarak geliştiriliyor. Ama yanı, GitHub Copilot’un en yeni agentic özelliklerini kullanmak istiyorsanız repo’nün GitHub’da olması ciddi bir avantaj sağlıyor — bence bu farkı zamanla daha net hissedeceksiniz. Karar tamamen sizin iş ihtiyacınıza bağlı.

Pull Request geçmişi ve code review yorumları taşınır mı?

GEI, PR geçmişini, yorumları, branch’leri ve tag’leri taşıyor. Ama work item bağlantıları gıbı bazı Azure DevOps’a özel meta veriler birebir taşınmıyor — yanı bazı şeyler kaybolabilir. Tecrübeme göre, önceden bir (belki yanılıyorum ama) test ortamında deneme yapıp beklediğinizden farklı çıkanları not etmek gerçekten hayat kurtarıyor. Bunu atlamamanızı şiddetle öneririm.

GitHub Enterprise Cloud Türkiye’de veri ikameti destekliyor mu?

Şu an için Türkiye bölgesi yok. AB bölgesi data residency mevcut. Açıkçası, Türkiye’de fiziksel veri tutma zorunluluğu olan kurumlar için GitHub Enterprise Server (self-hosted) çok daha uygun bir seçenek olabilir. E peki, sonuç ne öldü? Hukuk ve compliance ekibinizle önceden oturup değerlendirmenizi öneririm — sonradan sürprizle karşılaşmak istemezsiniz.

Migration sırasında geliştiriciler ne kadar süre çalışamaz?

GEI ile küçük-orta repolarda repo başına 5-30 dakika arası bir kilitleme penceresi genellikle yeterli oluyor. ELM işe neredeyse sıfır kesinti hedefliyor — hani repo aktif kullanılırken bile taşıma yapılabiliyor. Bence yine de planlamayı hafta sonu ya da yoğun olmayan saatlere koymak ekstra güvence sağlar (en azından benim deneyimim böyle)

Azure Pipelines’ı GitHub Actions’a çevirmem gerekir mi?

Bence, Hayır, gerekmiyor. Azure Pipelines, GitHub repolarıyla sorunsuz çalışıyor — yanı yatırım yaptığınız pipeline’ları olduğu gıbı koruyabilirsiniz. GitHub Actions’a geçiş aslında ayrı bir karar ve ayrı bir maliyet/fayda analizi gerektiriyor. Aceleye getirmeyin, bence iki şeyi aynı anda yapmaya çalışmak gereksiz yere karmaşıklaştırıyor işi.

Kaynaklar ve İleri Okuma

Açıkçası,
Microsoft DevOps Blog — Repositories to GitHub orijinal yazısı
GitHub Enterprise Importer (GEI) Resmî Dokümantasyonu
Azure Boards. Pipelines GitHub Entegrasyonu — Microsoft Learn
(kendi tecrübem)