Yazılım firmasını değiştiriyoruz: devir teslimde neleri istemek zorundasınız?

Yazılımınızı yapan firmadan ayrılma kararı aldınız ve karşı taraf "kodu gönderiyoruz" dedi. Devir teslim bu değil. Gerçek ölçüt tek bir cümlede duruyor: yeni ekip, eski ekibe hiç soru sormadan sıfırdan bir geliştirme ortamı kurabiliyor, uygulamayı derleyebiliyor, üretime bir sürüm çıkarabiliyor ve bir şey ters giderse geri alabiliyor mu? Bunu yapabilmek için koddan fazlası gerekir: alan adı ve DNS kaydının sahipliği, bulut ve mağaza hesapları, derleme hattı, sırlar, veri ve kimsenin yazmadığı işletme bilgisi. Bu yazı, ayrılırken yazılı olarak istemeniz gereken listeyi ve devralan ekibin ilk iki haftada ne yapması gerektiğini anlatıyor.

Ayrılık çoğu zaman iyi bir atmosferde olmuyor. O yüzden sıralama önemli: istenecekler listesini ayrılık kararını duyurmadan önce hazırlayın, hesap sahipliklerini de mümkünse duyurudan önce kontrol edin. Firmanın çalışanının kişisel e-postasıyla açılmış bir alan adı hesabını, ilişki soğuduktan sonra talep etmek çok daha zordur.

Devir teslim kod teslimi değil, hesap teslimidir

İlk iş envanter. Tek sayfalık bir tablo çıkarın ve her satır için üç kolon doldurun: hesap hangi e-posta adresiyle açılmış, faturası kime gidiyor, yönetici kim.

Tipik liste şöyle uzar: alan adı kayıt firması, DNS yönetimi, bulut hesabı ya da sunucu sağlayıcısı, kod deposu, CI/CD ortamı, Apple ve Google geliştirici hesapları, hata takip aracı, log ve izleme servisi, analitik ve Search Console, e-posta gönderim servisi, SMS sağlayıcısı, sanal POS ve ödeme kuruluşu paneli, e-fatura entegratörü, harita ve diğer API anahtarları, tasarım dosyaları, paket kayıt defteri (npm, Docker Hub gibi) hesapları.

Bu tabloyu doldururken şu ayrımı yapın: sizin adınıza açılmış ama yönetimi onlarda olan hesaplar kolay vakadır, yöneticiyi değiştirir bitirirsiniz. Zor olan, firmanın kendi hesabının içinde sizin için açılmış alt yapılardır. Orada devir teknik bir işlem değil, çoğu zaman yeni bir hesap açıp taşınma anlamına gelir ve gün alır.

Alan adı ve DNS: kilit süresi sizi bekletebilir

Alan adı, kaybedildiğinde geri alınması en pahalı varlıktır. Kayıt firmasındaki kayıt sahibinin (registrant) şirketiniz olduğunu, iletişim e-postasının şirket alan adında ve erişebildiğiniz bir adres olduğunu doğrulayın.

Devir için mevcut kayıt firmasından bir yetkilendirme kodu (uzun süredir EPP ya da auth code diye bilinen, ICANN'in gözden geçirilmiş transfer politikasında TAC adını alan kod) almanız gerekir. Bir de kilit süresi var: ICANN transfer politikası yeni kayıttan ve önceki bir devirden sonra 60 güne kadar firmalar arası transfere izin vermez, kayıt sahibi bilgisi değiştiğinde de benzer bir kilit devreye girebilir. Politikanın revizyonuyla bu süreler kısalıyor, ama planınızı "gerekirse aynı gün taşırız" varsayımı üzerine kurmayın.

Alan adını taşımadan da yapabileceğiniz bir şey var ve genellikle daha acildir: DNS yönetimini kendi hesabınıza alın. Ondan önce mevcut bölgenin tam bir dökümünü isteyin. Kayıtların bir kısmı görünmez işler yapar: e-posta gönderiminizi ayakta tutan SPF, DKIM ve DMARC kayıtları, alan adı doğrulama kayıtları, mağaza ve ödeme sağlayıcılarının istediği TXT kayıtları. Bunların bir tanesini taşımayı unutmak, e-posta kimlik doğrulama zincirinizi sessizce bozar ve sorunu bir hafta sonra "şifre sıfırlama e-postası gitmiyor" olarak duyarsınız.

Bulut hesabı başkasının organizasyonunun içindeyse

Yaygın kurulum şu: sistemleriniz, yazılım firmasının AWS organizasyonu altında bir üye hesapta duruyor ve fatura onların ana hesabına gidiyor. Bu hesabı bağımsız hale getirmek birkaç tıklama değildir. AWS, bir üye hesabın organizasyondan çıkarılabilmesi için o hesabın kendi ödeme yöntemine, seçilmiş bir destek planına ve doğrulanmış iletişim bilgilerine sahip olmasını şart koşar; bunlar tamamlanmadan çıkarma işlemi hata verir. Aynı mantık diğer sağlayıcıların takım ve organizasyon yapılarında da karşınıza çıkar.

İki soruyu baştan cevaplayın. Hesap gerçekten devredilebilir mi, yoksa firmanın başka müşterilerinin de içinde olduğu ortak bir yapıda mı duruyorsunuz? İkincisi ortaksa devir mümkün değildir, taşınma gerekir ve bu ayrı bir proje olarak planlanmalıdır. İkinci soru: devir sonrası fatura nereye gidecek, kredi kartı kimin? Bu ayrıntı yüzünden kapanan ortamlar görüyoruz. Devirden sonra maliyetin beklediğinizden yüksek çıkması da olağandır, çünkü eski firma indirimli taahhütlerini ya da kendi rezervasyonlarını yanında götürür. Bulut maliyetini gözden geçirmeyi devir sonrasının ilk ayına koyun.

Mağaza hesapları ve imzalama anahtarı

Mobil uygulamanız varsa iki ayrı ve birbirine benzemeyen süreçle uğraşacaksınız.

Apple tarafında uygulama devri App Store Connect üzerinden yapılır ve kuralları nettir. Devri yalnızca hesap sahibi (Account Holder) başlatabilir, alıcı tarafın kabul için 60 günü vardır. Uygulamanın App Store'da yayımlanmış en az bir sürümü olması gerekir; inceleme sürecinde, yayın bekler durumda ya da ön siparişte olan bir uygulama devredilemez. Uygulama içi satın alma ürün kimlikleri alıcı hesaptaki ürünlerle çakışmamalıdır. Apple'ın kendi yönergesindeki uyarıyı atlamayın: uygulama devir tamamlandığında eski hesaptan çıkar, bu yüzden meta veriler ve satış geçmişi devir öncesinde dışa aktarılmalıdır.

Google tarafında uygulama devri, iki geliştirici hesabının da aktif olmasını ve her iki hesabın kuruluş ücretine ait işlem kimliklerinin (transaction ID) bulunmasını gerektirir. Asıl kritik nokta ise imzalama anahtarıdır. Ağustos 2021'den sonra oluşturulan uygulamalar Android App Bundle ile yayımlanmak zorunda ve bu da Play App Signing kullanımını gerektiriyor, yani imzalama anahtarı Google'ın tarafında duruyor. Daha eski uygulamalarda anahtar hâlâ yazılım firmasının bir makinesinde ya da bir kasa dosyasında olabilir. O anahtar kaybolursa mevcut uygulamaya güncelleme yayımlayamazsınız, kullanıcılarınızı yeni bir uygulama kaydına taşımak dışında çıkış yolu kalmaz. Devir teslim listesinin en üstüne yazılacak maddelerden biri budur. Mağaza tarafındaki diğer sürtünme noktaları yayın süreci ve red nedenleri yazısında duruyor.

Depo, derleme hattı ve sıfırdan kurulum testi

Kod deposunu devralırken tek bir zip dosyasıyla yetinmeyin, geçmişiyle birlikte devralın. Commit geçmişi, bir hatanın ne zaman ve neden girdiğini bulmanın en hızlı yoludur ve sıfırlanmış bir geçmiş, elinizdeki en iyi belgeyi siler.

GitHub'da depo devri işi büyük ölçüde halleder: sorunlar, birleştirme istekleri, wiki, yıldızlar ve commit geçmişi taşınır, eski adrese giden git bağlantıları yönlendirilir. Bilmeniz gereken iki ayrıntı var. GitHub Pages bağlantıları yönlendirilmez, yani depo üzerinden yayımlanan bir sayfa varsa kırılır. Bir de webhook'lar, depo sırları ve dağıtım anahtarları devirden sonra da ilişkili kalır, bu da bir sonraki bölümün konusu.

Kodun kendisinden daha çok unutulan şey derleme hattıdır. CI/CD yapılandırması, ortam değişkenleri, derleme sırasında kullanılan özel paket kayıt defterleri, imzalama sertifikaları, veritabanı şema göç dosyaları, sunucu sağlama betikleri, zamanlanmış görevler (cron) listesi. Bunların yarısı genellikle kimsenin depoya koymadığı yerlerde durur. Nasıl bir hat kurulması gerektiğine dair karşılaştırma için küçük ekipler için CI/CD yazısına bakabilirsiniz.

Tek gerçek doğrulama testi şu: yeni ekipten bir kişi, tertemiz bir makinede, yalnızca teslim edilen belgelere bakarak projeyi ayağa kaldırsın. Takıldığı her adım, devir teslim eksiğinizin listesidir. Bu testi eski firma hâlâ sözleşmeliyken yapın, ayrılıktan iki ay sonra değil.

Eski ekibin gördüğü her sır, artık eski bir sırdır

Devir tamamlandığında rotasyon listesi çıkarın ve baştan sona uygulayın: veritabanı parolaları, dış servis API anahtarları, ödeme ve SMS sağlayıcısı kimlik bilgileri, webhook imzalama sırları, oturum ve JWT imzalama anahtarları, SSH ve dağıtım anahtarları, sunucu yönetici hesapları, panel kullanıcıları, VPN erişimleri. Eski firmanın kişisel hesaplarını organizasyonlarınızdan çıkarın, verdiğiniz OAuth uygulama izinlerini ve kişisel erişim jetonlarını iptal edin. Elde kalan veri kopyalarının silinmesini de yazılı olarak talep edin.

Bunu "güvensizlik" olarak sunmayın, çünkü değil. Kimlik bilgisi paylaşımı yıllara yayıldığında kimin neyi gördüğünü kimse hatırlamaz ve anahtarlar koda, betiklere, eski bilgisayarlara dağılır. GitGuardian'ın Mart 2026'da yayımladığı rapora göre yalnızca 2025 yılında herkese açık GitHub depolarına 28,6 milyon yeni sabit kodlanmış kimlik bilgisi eklendi, bir önceki yıla göre %34 artış. Özel depolarda tablonun daha iyi olduğunu varsayacak bir sebep yok.

Sırlar git geçmişine girmişse geçmişi temizlemeye çalışmak yerine anahtarı geçersiz kılın; sızmış bir anahtarın tek gerçek çözümü döndürmektir. Kalıcı çözüm için koda gömülü sır yönetimi yazısındaki kasa yaklaşımına geçin. Rotasyonu planlarken yan etkileri de hesaba katın: oturum imzalama anahtarını değiştirmek bütün kullanıcıları çıkışa zorlar, webhook sırrını değiştirmek karşı tarafta da güncelleme gerektirir. Bu yüzden rotasyon bir gecede değil, sıraya konmuş ve haber verilmiş bir çalışma olmalıdır.

Veri: yedek dosyası değil, kullanılabilir veri

"Veritabanı yedeğini verdik" cümlesi çoğu zaman yeterli değildir. Şunları isteyin: şema dokümantasyonu ya da en azından okunabilir bir şema dökümü, kullanıcı yüklemelerinin bulunduğu obje depolama kovalarının tam kopyası, varsa arama indeksinin nasıl yeniden üretileceği, ve verinin içinde şifreli tutulan alanlar varsa anahtarların nerede olduğu.

İki kontrol yapın. Birincisi, teslim edilen yedeği boş bir ortama gerçekten geri yükleyin; test edilmemiş yedek, yedek değildir. İkincisi, kayıt sayılarını canlı sistemle karşılaştırın. Mutabakat mantığını ve prova disiplinini eski sistemden yeni sisteme veri taşıma yazısında ayrıntılı anlatmıştık.

Belge yazdırmak yerine kayıt alın

Ayrılan firmadan 200 sayfalık bir dokümantasyon istemek iyi niyetli ama verimsiz bir taleptir. Kimse onu yazmaz, yazarsa da okunmaz. Onun yerine iki saatlik üç oturum planlayın ve ekran paylaşımıyla kaydedin: bir, sistemin mimarisi ve dış bağımlılıkları; iki, üretime sürüm çıkma ve geri alma adımları, canlıda yapılan düzenli manuel işler; üç, bilinen sorunlar, kırılgan yerler, "buraya dokunmayın" listesi ve son bir yılın en büyük arızaları.

Yanına iki kısa yazılı belge isteyin. Birincisi ortam ve hesap listesi (hangi ortam nerede, hangi adresle giriliyor). İkincisi üçüncü taraf sözleşmeleri ve yenileme tarihleri, çünkü unutulan bir lisans yenilemesi devirden üç ay sonra kendini kesinti olarak gösterir. Bilginin tek kişide toplanmasının nasıl kırılacağını tek kişi bağımlılığı yazısında ele almıştık.

Ayrılma maddesini sözleşmeye ilk gün koyun

Bu yazıdaki her şeyin kolay tarafı, ayrılma koşullarının sözleşmede yazılı olduğu durumdur. Finans sektörü bunu düzenlemeyle öğrendi: Avrupa Birliği'nin 17 Ocak 2025'ten beri uygulanan DORA düzenlemesi, kritik veya önemli işlevleri destekleyen bilgi teknolojisi hizmetleri için belgelenmiş ve yeterince test edilmiş çıkış stratejileri bulundurmayı zorunlu kılıyor. Kapsamda olmasanız bile maddelerin mantığı aynı.

Sözleşmede aranacak dört şey var: fikri mülkiyetin ve kaynak kodun size ait olduğunun açıkça yazılması, hesapların şirket adına açılacağı taahhüdü, fesih halinde belirli bir süre (30 ila 90 gün arası yaygındır) geçiş desteği verileceği, ve verinin yaygın kullanılan bir formatta teslim edileceği. Bunları kaynak kod mülkiyeti ve emanet ile yazılım bakım ve destek sözleşmesi yazılarında ayrıntılandırmıştık. Geçiş desteğinin saat ücreti de baştan belirlenmiş olsun; ayrılık anında pazarlık edilen destek pahalıdır.

Devralan ekibin ilk iki haftası

Yeni ekibin ilk refleksi genellikle "bunu sıfırdan yazalım" olur. Bu refleks bazen haklıdır ama ilk iki haftada verilecek karar değildir, çünkü o sırada elinizde henüz veri yoktur. Önce durum tespiti yapın.

Şu sırayla ilerleyin: sıfırdan kurulum testini tamamlayın, üretime küçük ve zararsız bir değişiklik çıkarıp geri alın (hattın gerçekten çalıştığını böyle öğrenirsiniz), bağımlılıkların sürümlerini ve desteği biten bileşenleri tarayın, açık zafiyetleri listeleyin, otomatik testlerin gerçekte ne kadarını kapsadığına bakın, lisans uyumunu kontrol edin, altyapı faturasını ve kullanılmayan kaynakları gözden geçirin, son üç ayın hata ve kesinti kayıtlarını okuyun.

Çıkan listeyi tek bir kovaya atmayın. Güvenlik ve süreklilik riskleri hemen, iş hedeflerini engelleyen darboğazlar sonraki çeyrekte, geri kalanı normal geliştirme temposunda. Önceliklendirmeyi savunulabilir yapmanın yolu için teknik borcu ölçme ve önceliklendirme yazısına bakın. Yeniden yazma kararını ise veriyle verin, ilk izlenimle değil: eski yazılımı yenilemek mi, sıfırdan yazmak mı sorusunun cevabı genelde ikisinin ortasında.

Geçiş günü ve paralel pencere

Devri tek bir güne sıkıştırmayın. İşleyen model şu: eski firma sözleşmesi bitmeden önce yeni ekip erişimleri alır, sıfırdan kurulum testini yapar ve üretime ilk sürümü eski ekip hâlâ ulaşılabilirken çıkarır. Bu ilk sürüm küçük olsun, bir metin değişikliği bile olur. Amaç özellik teslim etmek değil, zincirin tamamının çalıştığını kanıtlamak.

Paralel pencerede kimin nöbetçi olduğunu yazılı hale getirin. "Sorun olursa ararız" bir plan değildir, özellikle karşı taraf artık ücret almıyorsa.

Bu hafta atabileceğiniz adımlar

1. Hesap envanteri tablosunu çıkarın: her hesap hangi e-postayla açılmış, faturası kime gidiyor, yöneticisi kim.
2. Alan adı kayıt sahibini ve iletişim e-postasını doğrulayın, DNS bölgesinin tam dökümünü alın.
3. Mobil uygulamanız varsa imzalama anahtarının kimde olduğunu bugün öğrenin.
4. Rotasyon listesini şimdiden hazırlayın, böylece devir günü sıralı bir işe dönüşür.
5. Yeni sözleşmeye geçiş desteği ve veri teslim maddelerini koyun, ayrılırken değil başlarken.

Wedevit olarak bu süreci iki yönde de yürütüyoruz: ayrılmakta olan tarafta istenecekler listesini ve erişim devrini yönetiyor, devralan tarafta sıfırdan kurulum testi, sır rotasyonu ve teknik durum tespitiyle başlıyoruz. Çıkan tabloyu yeniden yazma değil, önceliklendirilmiş bir yol haritası olarak teslim ediyoruz. Tüm çalışma uzaktan yürütülür.