Yazılım Firmasını Değiştirirsek Sistemimiz Ne Olur? Mevcut Projeyi Başka Ekibe Devretme Rehberi

Kısa cevap

Çoğu durumda yazılım firmasını değiştirmek, mevcut sistemi sıfırdan yaptırmak anlamına gelmez. Yeni ekip kaynak koda, repository geçmişine, production altyapısına, database ve dosyalara, environment yapılandırmasına, üçüncü taraf servis hesaplarına ve yeterli teknik dokümantasyona erişebiliyorsa mevcut proje devralınıp geliştirilmeye devam edilebilir. Asıl risk firmanın değişmesi değil, sistemin önceki firmaya teknik olarak bağımlı tasarlanmış olmasıdır. Sağlıklı geçiş modeli şöyledir: Mevcut Sistemi Envanterle ↓ Kod ve Hesap Erişimlerini Al ↓ Yedekleri Doğrula ↓ Yeni Ekibe Read-Only Erişim Ver ↓ Teknik Audit Yap ↓ Local / Staging Kurulumu Doğrula ↓ Deployment'ı Tekrarla ↓ Secret ve Yetkileri Rotate Et ↓ Kontrollü Sorumluluk Devri ↓ Eski Vendor Erişimlerini Kapat Özellikle kritik sistemlerde önce yeni ekibin sistemi çalıştırabildiği doğrulanmalı, sonra eski firmanın erişimleri kaldırılmalıdır.

Yazılım firması değişince sistemi yeniden yazmak gerekir mi?

Hayır, otomatik olarak gerekmez. Şu koşullarda mevcut sistemi devam ettirmek genellikle mümkündür:

• kaynak kod mevcut,
• kullanılan teknoloji hâlâ desteklenebilir,
• database erişilebilir,
• production ortamına erişilebiliyor,
• sistem çalışıyor,
• kritik servis hesapları biliniyor,

yeni ekip projeyi kurabiliyor. Bu durumda yapılacak iş: rewrite değil, technical takeover olabilir.

Ne zaman yeniden yazma gündeme gelir?

Ancak bazı projelerde audit sonunda:

• kaynak kod eksik,
• production kodu repository'den farklı,
• teknoloji çok eski veya destek dışı,
• kritik güvenlik sorunları var,
• database yapısı sürdürülemez,
• sistem aşırı kırılgan,

mevcut mimari yeni ihtiyaçları karşılamıyor sonucu çıkabilir. O zaman: Devam et vs Refactor et vs Kademeli yenile vs Baştan geliştir kararı ayrı verilmelidir. Bu konuyu 22. makalede daha detaylı ele alacağız. Önemli olan: Yazılım firmasının değişmesi tek başına rewrite gerekçesi değildir.

Yeni firma ilk olarak ne ister?

Profesyonel bir devralma sürecinde yeni ekibin ilk ihtiyacı genellikle:

Kod + Çalışan sistem + Erişim + Veri modeli + Deployment bilgisi olur. Yeni firma önce sistemin nasıl çalıştığını anlamalıdır. Bu nedenle ilk birkaç gün doğrudan yeni özellik geliştirmek yerine teknik keşif yapılması normaldir.

Devralma sürecini 4 ana başlıkta düşünün

1. Kod

repository

branches

commit history

dependencies build.

2. Altyapı

cloud

hosting database storage DNS.

3. Entegrasyonlar

ödeme

e-mail SMS AI ERP üçüncü taraf API'leri.

4. Bilgi

mimari

deployment business rules bilinen sorunlar teknik borç. Bunlardan biri eksikse geçiş hâlâ yapılabilir. Ancak risk ve başlangıç süresi büyür.

1. Repository kontrolüyle başlayın

Yeni ekibin ilk ihtiyacı:

gerçek production kodunun bulunduğu repository olmalıdır.

Kontrol edin:

GitHub / GitLab / Bitbucket?

↓

Repository nerede?

↓

Şirket erişebiliyor mu?

↓

Default branch hangisi?

↓

Production buradan mı deploy ediliyor?

Repository başka firmanın hesabındaysa ne olur?

GitHub repository'lerinin başka kullanıcı veya organization hesabına transfer edilmesi destekleniyor. Transfer sırasında commit geçmişi korunuyor; issues, pull requests, releases ve birçok repository öğesi de yeni sahibiyle birlikte taşınabiliyor. GitHub eski repository adresine yapılan Git işlemlerini de yeni konuma yönlendirebiliyor. (GitHub Docs) Dolayısıyla: old-agency/project altında duran proje gerektiğinde: your-company/project gibi şirket organization'ına taşınabilir.

Repository transferinde her şey otomatik düzelir mi?

Hayır. GitHub, transfer sırasında webhooks, secrets ve deploy keys gibi bazı unsurların repository ile ilişkili kalabildiğini belirtiyor. Bu nedenle transfer sonrasında:

• deploy key,
• webhook,
• GitHub App,
• Actions secret,

collaborator listesi ayrıca incelenmelidir. (GitHub Docs) Özellikle eski vendor tarafından kontrol edilen credential varsa: transfer sonrası rotate/revoke edilmelidir.

Yeni firmaya hemen Admin vermeli misiniz?

Çoğu geliştiricinin ilk aşamada admin yetkisine ihtiyacı yoktur. GitHub organization repository'lerinde:

• Read,
• Triage,
• Write,
• Maintain,

Admin gibi farklı roller bulunur ve GitHub her kullanıcıya görevini yapması için gereken seviyede erişim verilmesini önerir. (GitHub) Örneğin takeover'ın ilk audit aşamasında: Read yeterli olabilir. Geliştirme başlayınca: Write verilebilir. Admin yalnızca gerçekten repository ayarlarını yönetecek sınırlı kişilere bırakılabilir.

2. Production kodu gerçekten repository'deki kod mu?

Bu kritik bir testtir. Bazı eski projelerde geliştirici: local bilgisayar ↓ manuel dosya upload ↓ production yapmış olabilir. Son repository commit'i: 6 ay önce ama production içinde sonraki değişiklikler bulunabilir. Bu durumda repository: tek gerçek kaynak — source of truth değildir.

Nasıl kontrol edilir?

Yeni ekip:

• production build sürümünü,
• deployed commit bilgisini,
• dosya farklarını,

release/deployment geçmişini inceleyebilir. Amaç: Repository = Gerçek çalışan sistem olduğunu doğrulamaktır. Bu yapılmadan yeni development branch açmak risklidir.

3. Proje local ortamda kurulabiliyor mu?

Yeni ekibin önemli kabul testlerinden biri:

git clone ↓ dependencies ↓ environment ↓ database ↓ run akışının çalışmasıdır. Eğer proje yalnızca eski geliştiricinin bilgisayarında çalışıyorsa ciddi handover problemi vardır.

İyi bir README neleri açıklamalı?

Minimum olarak:

• runtime sürümü,
• dependency kurulumu,
• environment variable isimleri,
• development command,
• test command,
• build command,
• migration komutları,

gerekli servisler. Örneğin: Node version Package manager Database Local setup Build Test Deploy gibi. README tek başına yeterli olmayabilir ama devralma süresini ciddi biçimde azaltır.

4. Environment variable'ları kontrol edin

Yeni firma repository'yi aldı. Ama: DATABASE_URL AUTH_SECRET SMTP_PASSWORD PAYMENT_KEY yok. Sistem çalışmaz. Bu nedenle environment configuration ayrıca devredilmelidir.

Secret'ları WhatsApp'tan göndermek doğru mu?

Hayır. Daha iyi süreç: Yeni ekip ↓ Kurumsal secret/cloud hesabına erişim ↓ Gerekli credential şeklindedir. Devralma tamamlandıktan sonra eski firmanın kullandığı uzun ömürlü credential'ların değiştirilmesi önerilir. AWS de uzun süreli access key yerine mümkün olduğunda temporary credentials ve IAM role kullanımını; artık ihtiyaç duyulmayan kullanıcı, rol, permission ve credential'ların düzenli olarak kaldırılmasını öneriyor. (AWS Dokümantasyonu)

Firma değişiminde secret rotation neden önemli?

Eski firma dürüst olsa bile:

• eski developer laptop'unda,
• CI loglarında,
• password manager'da,

eski environment backup'ında credential bulunabilir. Dolayısıyla erişimi kapatmak: GitHub user remove ile bitmez. Ayrıca: API keys Cloud credentials Database passwords Webhook secrets Deploy tokens gözden geçirilmelidir.

Hepsini aynı saniyede değiştirmek gerekir mi?

Hayır. Yanlış sırayla yapılan mass rotation production'ı düşürebilir. Daha güvenli: Envanter ↓ Yeni credential oluştur ↓ Yeni sistemde kullan ↓ Test et ↓ Eski credential revoke modelidir.

5. Cloud hesabı kimin?

Bu soru geçiş sürecinin en kritiklerinden biridir. Örneğin: AWS Azure Google Cloud Vercel Render DigitalOcean kullanılıyor olabilir.

Kontrol edin:

Account/team owner kim?

Vercel projesi başka hesaba aktarılabilir mi?

Evet. Vercel'in güncel dokümantasyonuna göre projeler takımlar arasında transfer edilebiliyor ve platform transferi downtime oluşturmadan yapmayı hedefliyor. Deployment'lar, project configuration, çoğu environment variable, domain/alias, Git repository bağlantısı ve bazı diğer ayarlar transfer edilebiliyor. (Vercel) Ancak önemli bir ayrım var. Vercel transferinde her şey taşınmıyor Vercel'e göre örneğin:

• bazı integrations,
• monitoring verileri,
• runtime/build log geçmişi,
• bazı log drains,

belirli storage bileşenleri otomatik transfer edilmeyebilir veya ayrı migration gerektirebilir. (Vercel) Bu çok önemli bir genel prensibi gösterir: “Project transfer” düğmesine basmak tam teknik handover anlamına gelmeyebilir. Her platformun “transferred / not transferred” listesi ayrı kontrol edilmelidir.

Cloud hesabı taşınmak zorunda mı?

Eğer cloud zaten şirket hesabındaysa:

Old vendor access → remove New vendor access → add yeterli olabilir. Bu, 20. makalede anlattığımız şirket kontrollü cloud modelinin en büyük avantajıdır.

6. Database'i nasıl devralmalısınız?

Önce şunları bulun:

Database engine?

Version?

Location?

Size?

Backup?

Migration history?

Örneğin: PostgreSQL 17 Managed Database 18 GB Daily Backup gibi.

Yeni firmaya production database'i hemen açmalı mısınız?

Her kullanıcıya full write access vermek gerekmez. İlk audit'te: Read-only erişim yeterli olabilir. Daha sonra gerekli operasyon rolleri tanımlanabilir. Burada least-privilege yaklaşımı kullanılmalıdır. Devirden önce backup alın Kritik bir takeover öncesinde en azından: Database backup + File storage backup doğrulanmalıdır. Sadece: “Otomatik backup açık.” demek yerine mümkünse restore edilebilirliği de değerlendirin. Çünkü backup'ın değeri, gerektiğinde geri yüklenebilmesiyle ortaya çıkar.

Database'i hemen başka altyapıya taşımak gerekir mi?

Hayır. Firma değiştirirken aynı anda: Developer + Cloud + Database + Framework değiştirmek gereksiz risk yaratabilir. Mümkünse önce: operasyonel sahipliği devralın. Sonra altyapı optimizasyonu ayrı proje olarak değerlendirilebilir. Bu prensip geçiş sırasında değişken sayısını azaltır.

7. Dosya storage'ı unutmayın

Database elinizde olabilir. Ama: PDF Image Invoice Contract Attachment dosyaları başka yerde tutuluyor olabilir. Örneğin:

• S3,
• Vercel Blob,
• Cloudinary,
• local disk,

Firebase Storage. Bunlar ayrı envanterlenmelidir. En sık görülen hata Database backup alındı. Ama customer document'ları: old-agency-storage-account içinde kaldı. Sistem açılır fakat bütün ekler kayıp görünür. Bu nedenle: Database ≠ Bütün veriler ayrımını yapmak gerekir.

8. Domain ve DNS'e dokunurken dikkat

Firma değişikliğinin ilk gününde domain'i taşımak çoğu zaman gerekli değildir. Eğer: Domain → Company DNS → Company zaten doğruysa yalnızca gerekli deployment kayıtları güncellenir. Ancak domain eski firmanın hesabındaysa kontrolün şirkete geçirilmesi ayrıca planlanmalıdır.

DNS değişikliği neden kritik?

Yanlış değişiklik:

• siteyi,
• API'yi,
• e-mail'i,

subdomain'leri aynı anda etkileyebilir. Örneğin: app.example.com api.example.com mail records aynı zone içinde olabilir. Bu nedenle yeni ekip DNS üzerinde değişiklik yapmadan önce mevcut kayıtların export/screenshot/envanterini almalıdır.

9. Üçüncü taraf servisleri envanterleyin

Modern uygulamanın yalnızca:

Frontend + Database olması nadirdir. Şunlardan bazıları bulunabilir:

• payment,
• e-mail,
• SMS,
• WhatsApp,
• AI API,
• analytics,
• monitoring,
• maps,
• storage,

captcha. Her biri için: Soru

Cevap

Servis ne?

...

Hesap sahibi kim?

...

Faturalandırma kimde?

...

Production key nerede?

...

Webhook var mı?

...

Vendor erişimi var mı?

... hazırlanmalıdır. Payment sisteminde özellikle dikkat Örneğin eski vendor: Stripe/Webhook yapılandırmasını yönetiyor olabilir. Sadece yeni API key üretmek yeterli olmayabilir. Ayrıca:

• webhook endpoint,
• signing secret,
• return URL,

live/test mode kontrol edilmelidir. Bu prensip bütün harici API'ler için geçerlidir.

10. CI/CD pipeline'ını devralın

Production deploy nasıl oluyor?

Model A

main merge

↓ GitHub Actions ↓ Production Model B Vercel Git Integration Model C Developer laptop ↓ Manual deploy Yeni ekip bunu bilmelidir. En sağlıklı takeover testlerinden biri Yeni ekip: küçük güvenli değişiklik ↓ staging deploy ↓ test yapabilmelidir. Sonra gerekiyorsa production release yapılır. Bu: yeni ekibin sistemi gerçekten teslim aldığını gösteren daha güçlü testtir. Kaynak kodu okumak sistemi devralmak değildir Şu iki seviye farklıdır: Seviye 1 Kod erişimimiz var. Seviye 2 Sistemi build edip test edip deployment yapabiliyoruz. Gerçek takeover ikinci seviyedir.

11. Cron job ve background worker'ları bulun

Web uygulaması yalnızca kullanıcı request'lerinden oluşmayabilir. Örneğin: Every day 03:00 → invoice sync Every hour → price update Queue worker → e-mail Cron → reports çalışabilir. Bunlar unutulursa sistem başlangıçta çalışıyor gibi görünür fakat birkaç gün sonra operasyonlar bozulur. Hidden automation en büyük handover risklerinden biridir Örneğin bir developer'ın: personal server üzerinde çalışan cron script'i olabilir. Hiçbir dokümantasyonda yoktur. Vendor ayrılınca server kapanır. 3 gün sonra raporlar güncellenmez. Bu nedenle devralma audit'inde:

• cron,
• queue,
• workers,
• webhook,

scheduled function özellikle aranmalıdır.

12. Mobil uygulama varsa geçiş daha geniştir

Web projesinden farklı olarak ayrıca:

• App Store Connect,
• Apple Developer,
• signing,
• Play Console,
• Play App Signing,

push certificates incelenmelidir.

Apple uygulaması başka hesaba transfer edilebilir mi?

Evet, belirli kriterleri karşılayan uygulamalar App Store Connect hesapları arasında transfer edilebilir. Apple, uygulamanın transfer sırasında App Store'da kullanılabilir kalabildiğini; yorum ve puanlarının korunduğunu ve Bundle ID'sinin değişmeden kaldığını belirtiyor. (Apple Developer) Ancak kaynak kod transferi bunun parçası değildir. Apple açıkça, uygulamanın gerçek code set'i ve build asset'lerinin eski ve yeni taraf arasında ayrıca paylaşılması gerektiğini belirtiyor. (Apple Developer) Yani: App Store transfer ≠ Source code handover Apple tarafında signing yeniden kontrol edilmeli App transfer tamamlandıktan sonra yeni hesapta yeni provisioning profile'ların oluşturulması gerekir. Apple bunu transfer sonrası yapılması gerekenler arasında açıkça belirtiyor. (Apple Developer) Ayrıca:

• push notifications,
• keychain sharing,
• Game Center,

diğer capabilities

varsa özel transfer etkileri incelenmelidir. (Apple Developer)

Google Play uygulaması transfer edilebilir mi?

Evet. Google Play, uygulamaların farklı developer account'larına resmi transfer süreciyle taşınmasını destekliyor. Kullanıcılar, indirme istatistikleri, ratings/reviews ve store listing gibi birçok veri yeni hesaba aktarılabiliyor. (Google Yardım) Ancak bazı unsurlar taşınmıyor.

Google Play'de hangi şeyler ayrıca kontrol edilmeli?

Google'a göre örneğin:

• bulk export/earnings raporları,
• test grupları,

bazı integrated-service permissions/linkage ayarları otomatik transfer edilmeyebilir ve yeniden yapılandırılması gerekebilir. (Google Yardım) Bu yüzden mobil uygulama devrinde: Store transfer + Technical account audit birlikte yapılmalıdır.

Google Play hesabını şifre paylaşarak devretmek doğru mu?

Google, başka kişilerin erişmesi gerekiyorsa account owner's kişileri ayrı kullanıcı olarak eklemesini öneriyor ve ihtiyaç kalmadığında erişimlerin kaldırılmasını tavsiye ediyor. (Google Yardım) Yani: shared Gmail password yerine: individual user access daha doğru modeldir.

13. Business rules dokümantasyonu kaynak kod kadar önemli olabilir

Yeni ekip kodu okuyabilir.

Ama şunu bilmeyebilir:

Neden bu müşteri tipine %17 indirim uygulanıyor?

Kodda:

if customer.type === X

görür. Ancak business gerekçesi bilinmez. Bu yüzden yalnızca teknik değil, iş bilgisi de devredilmelidir. Özellikle şu kuralları belgeleyin

• fiyatlama,
• komisyon,
• onay,
• rol,
• hesaplama,
• durum geçişleri,
• otomasyon,

istisnalar. Bu dokümantasyon yeni ekibin yanlışlıkla “bug” sandığı business rule'u değiştirmesini önleyebilir.

14. Bilinen bug ve teknik borçları isteyin

Eski firmadan mümkünse:

Known Issues Technical Debt Pending Tasks Future Risks listesi alınmalıdır. Örneğin: “Bu entegrasyon eski API kullanıyor; sağlayıcı 3 ay sonra kapatacak.” bilgisi yeni ekip açısından çok değerlidir.

Handover toplantısı yapılmalı mı?

Mümkünse evet. İdeal teknik handover: Eski Teknik Ekip + Yeni Teknik Ekip + Müşteri ile yapılabilir. Konular:

• mimari,
• deployment,
• database,
• entegrasyonlar,
• kritik business rule,

bilinen sorunlar. 1–2 iyi teknik toplantı haftalarca tersine mühendislik yapılmasını önleyebilir.

Eski firma görüşmeye yanaşmıyorsa proje devralınamaz mı?

Hayır. Yine devralınabilir. Ancak yeni firma daha fazla:

• code reading,
• architecture discovery,

reverse engineering yapar. Bu da başlangıç maliyetini ve riski artırabilir.

15. İlk gün büyük refactor yapılmamalı

Yeni ekip bazen projeyi açıp:

“Bunu tamamen değiştirelim.” diyebilir. Bu her zaman doğru değildir. Önce sistemin:

• neden böyle tasarlandığı,
• gerçek production davranışı,

business constraint'leri anlaşılmalıdır. Daha sağlıklı: Understand ↓ Stabilize ↓ Measure ↓ Improve modelidir. “Kod kötü” demek rewrite gerekçesi değildir Her eski projede:

• eski pattern,
• technical debt,

tutarsız naming bulunabilir.

Soru:

Sistem sürdürülebilir mi?

olmalıdır. Eğer evetse kademeli refactor çoğu zaman tam rewrite'tan daha düşük riskli olabilir.

16. İlk yapılacak teknik audit neleri içermeli?

Kod

Framework/runtime sürümü Dependency durumu Build Test kapsamı Repository yapısı Güvenlik Authentication Authorization Secret handling Known vulnerable dependencies Public endpoints Database Schema Migration history Index Backup Altyapı Cloud Deploy DNS Storage Queue/Cron Operasyon Monitoring Logs Error tracking Backup/recovery. Audit'in amacı eski firmayı yargılamak değil Amaç: Mevcut durumu ölçmek. Yeni ekip raporu: Critical High Medium Low veya: Şimdi 3 ay içinde İyileştirme gibi sınıflandırabilir. Böylece geçiş sonrası roadmap çıkar.

17. Eski vendor erişimleri ne zaman kaldırılmalı?

En kritik sıralama:

Önce yeni erişim çalışıyor mu?

↓

Sonra eski erişimi kapat olmalıdır. Aksi halde: Old vendor removed ↓ New vendor access broken ↓ Production müdahalesi yapılamıyor durumu oluşabilir. Erişim kapatma checklist'i Devralma tamamlandıktan sonra: GitHub collaborator/team Cloud IAM user/role Vercel/team Database account SSH key VPN Password manager DNS access App Store Connect Play Console Monitoring Third-party dashboard gözden geçirilmelidir. AWS de erişim yaşam döngüsünde artık kullanılmayan kullanıcı, rol, permission ve credential'ların düzenli olarak kaldırılmasını güvenlik best practice'i olarak öneriyor. (AWS Dokümantasyonu)

18. Hangi secret'lar rotate edilmeli?

Örneğin: Cloud access keys Database passwords Deploy tokens Webhook secrets Private API keys SSH keys Service-account credentials değerlendirilmelidir. Ama OAuth/client ID gibi her identifier secret değildir. Önce credential envanteri çıkarılmalıdır.

19. Eski firmayla erişim bir gün daha tutulmalı mı?

Bazı geçişlerde kontrollü bir overlap period yararlı olabilir. Örneğin: Hafta 1 New team audit Hafta 2 Joint operation Hafta 3 New team primary Old team emergency support Sonra Old access removed Bu InoviqLab operasyon önerisidir. Sözleşme ve güvenlik durumuna göre süre değişebilir. Ancak sorunlu ayrılıklarda overlap mümkün olmayabilir Firma ile ilişki:

• hukuki ihtilaf,
• güvenlik problemi,

kötü niyet şüphesi nedeniyle sonlanıyorsa normal handover yerine incident-response benzeri daha hızlı erişim kapatma gerekebilir. Bu durumda öncelik: Business continuity + Access security olmalıdır.

20. Geçiş sırasında production değişikliklerini azaltın

Takeover haftasında aynı anda:

Yeni firma + Major framework upgrade + Database migration + Yeni ödeme sistemi başlatmak risklidir. Mümkünse kısa bir: Change Freeze veya düşük değişiklik dönemi kullanılabilir. Amaç sistemi dondurmak değil: değişim sırasında hata kaynağını azaltmak. İdeal Devralma Planı Aşama 1 — Envanter Code Accounts Data Infrastructure Integrations Aşama 2 — Erişim New team read access Aşama 3 — Backup Database Storage Configurations Aşama 4 — Audit Architecture Security Dependencies Infrastructure Aşama 5 — Reproduction Local Staging Build Aşama 6 — Deployment Controlled release Aşama 7 — Ownership Accounts/company control Aşama 8 — Rotation Credentials Aşama 9 — Revoke Old vendor access Aşama 10 — Roadmap Critical fixes ↓ Technical debt ↓ New development Yazılım Firması Değiştirme Kontrol Listesi Kaynak Kod Repository erişilebilir. Production code repository'de.

Commit history mevcut.

Default branch belli. Tags/releases incelendi. Yeni ekip projeyi clone edebiliyor. Local / Build Runtime sürümü belli. Package manager belli. Dependency kuruluyor. Local app çalışıyor. Tests çalışıyor. Production build alınabiliyor. Cloud Hosting sağlayıcı belli. Account owner belli. Şirket admin erişimine sahip. Vendor erişimleri listeli. Environment'lar belli. Database Engine/version belli. Production DB erişimi var. Backup mevcut. Restore yöntemi biliniyor. Migration sistemi belli. Dosyalar Storage sağlayıcı belli. Document/image backup var. Access policy biliniyor. Domain Registrar belli. Domain hesabına erişim var. DNS kayıtları export edildi. Renewal kontrol edildi. Entegrasyonlar Tüm external API'ler listelendi. Account ownership belli. Webhook'lar listelendi. API credential'ları envanterlendi. Faturalandırma sahipliği belli. Deployment CI/CD belli. Staging deploy yapılabiliyor. Production deploy prosedürü belli. Rollback yöntemi biliniyor. Security Eski vendor kullanıcıları listelendi. Deploy keys incelendi. API keys incelendi. Password/secret rotation planı var. Yeni erişim test edilmeden eski erişim kapatılmıyor. Dokümantasyon Architecture. Setup. Deployment. Integrations. Business rules. Known issues. Technical debt. Mobil Uygulama Devralma Ek Listesi Apple App Store Connect ownership belli. Apple Developer organization belli. App transfer gerekip gerekmediği belli. Source/build assets devredildi. Bundle ID kontrol edildi. Certificates/provisioning yeniden değerlendirildi. Push/capabilities kontrol edildi. Apple, uygun uygulamaların hesaplar arasında transfer edilmesine izin verirken kaynak kod ve build asset'lerinin taraflar arasında ayrıca devredilmesi gerektiğini özellikle belirtiyor. (Apple Developer) Google Play Developer account sahibi belli. Formal app-transfer gereksinimi değerlendirildi. Play App Signing kontrol edildi. Testing groups gözden geçirildi. Service linkages yeniden kontrol edildi. Raporlar gerekiyorsa transfer öncesi indirildi. Google Play app transferinde kullanıcı, store listing, ratings/reviews ve birçok uygulama verisi taşınabilirken test grupları ve bazı service-linkage ayarları gibi unsurların tekrar kurulması gerekebilir. (Google Yardım)

Yeni firma için ilk 30 gün nasıl planlanabilir?

Aşağıdaki yapı örnektir. İlk hafta Anla. Access Audit Run locally Architecture İkinci hafta Kontrolü doğrula. Staging Deployment Backup Monitoring Üçüncü hafta Riskleri azalt. Critical security Secrets Broken automation Dördüncü hafta Roadmap oluştur. Technical debt Performance Features Refactor Bu sıra her projeye birebir uygulanmak zorunda değildir. Ama: İlk gün yeni özellik geliştirmek yerine önce sistemi güvenli biçimde devralmak genellikle daha sağlıklıdır.

Yazılım firması değiştirirken en sık yapılan 8 hata

1. Eski firma erişimini çok erken kapatmak

Yeni ekip henüz sistemi deploy edemiyor olabilir.

2. Hiç erişim kapatmamak

Aylar sonra eski developer hâlâ production erişimine sahip olabilir.

3. Sadece kaynak kodu almak

Cloud, data ve integrations unutulur.

4. Backup almadan değişiklik yapmak

Geçiş riskini artırır.

5. İlk hafta framework değiştirmek

Hata kaynağını çoğaltır.

6. Business rule'ları belgelememek

Yeni ekip doğru davranışı bug sanabilir.

7. Personal account'ları kullanmaya devam etmek

Yeni vendor aynı vendor-lock-in modelini tekrar oluşturabilir.

8. Eski firmayı suçlama odaklı audit yapmak

Amaç geçmişi yargılamak değil:

gelecekte sistemi güvenli yönetmektir. “Eski firma kodu vermezse ne olur?” Burada teknik konudan hukuki konuya geçilir. Öncelikle sözleşme incelenmelidir:

• kaynak kod teslim maddesi,
• fikri haklar,
• repository sahipliği,

termination/handover hükümleri. makalede anlattığımız gibi, ücret ödenmiş olması tek başına bütün mali hakların müşteriye geçtiğini göstermeyebilir. Bu durumda hukukçu desteği gerekebilir.

Kod elimizde yoksa sistem kurtarılamaz mı?

Duruma göre. Backend source yoksa Çalışan server binary/container'dan tam kaynak kodu geri elde etmek mümkün olmayabilir. Frontend bundle varsa Production bundle source code ile aynı geliştirme kalitesinde değildir. Database varsa Business data kurtarılabilir. Bu nedenle kaynak kod ve repository erişiminin proje sonunda değil, mümkünse proje yaşamı boyunca şirket kontrolünde olması çok daha güvenlidir.

Yeni firma mevcut kodu kabul etmeyebilir mi?

Evet. Bazı firmalar yalnızca kendi geliştirdikleri projeleri yönetebilir. Bu onların ticari tercihidir. Ancak iyi bir technical takeover yapan firma önce: Audit yapıp: Devralabiliriz veya: Şu nedenle yeniden yapılandırma gerekir diye gerekçelendirmelidir.

“Bu kod kötü, yeniden yapalım” cümlesine nasıl yaklaşmalısınız?

Şunları sorun:

Hangi somut sorun?

Güvenlik mi?

Performans mı?

Bakım maliyeti mi?

Teknoloji EOL mu?

Yeni özellik eklemek neden mümkün değil?

Kademeli refactor neden yeterli değil?

Rewrite riski nedir?

Rewrite büyük bir iş kararıdır. Teknik tercih olarak verilmemelidir.

Firma değiştirme maliyeti neden oluşur?

Yeni firma bir süre:

kod yazmak yerine sistemi öğrenir. Buna:

• discovery,
• audit,
• setup,
• documentation,

access migration dahil olabilir. Bu ekstra süre kötü bir şey değildir. Sistemi tanımadan doğrudan geliştirmeye başlamak daha büyük risk olabilir. İyi dokümantasyon geçiş maliyetini düşürür Örneğin: Proje A README ✅ Architecture ✅ Deployment ✅ Tests ✅ CI/CD ✅ Proje B Docs ❌ Manual deploy Personal accounts Unknown cron İki proje aynı kod büyüklüğünde olsa bile takeover süresi çok farklı olabilir. Bu nedenle dokümantasyon: yalnızca geliştirici konforu değil, ticari risk azaltma aracıdır. Vendor değiştirilebilirliği sistem kalitesi metriği olabilir İyi özel yazılımın özelliklerinden biri: ilk geliştiricisi olmadan da anlaşılabilir ve işletilebilir olmasıdır. Bu, her yeni geliştiricinin sistemi bir günde anlayacağı anlamına gelmez. Ama: Kod + Docs + Accounts + Standard Deployment mevcutsa bilgi tek kişiye kilitlenmez.

InoviqLab değerlendirmesi

Bu bölüm InoviqLab'ın proje devralma yaklaşımıdır. Yazılım firması değiştirme sürecinde en büyük hata: “Bugünden itibaren eski ekip yok, yarından itibaren yeni ekip devam etsin.” diye düşünmektir. Gerçekte arada kontrollü bir: technical transition aşaması bulunmalıdır. Birinci prensip: Önce sistemi çalıştır, sonra geliştir Yeni ekibin ilk başarı kriteri: Yeni özellik ✅ olmamalıdır. Önce: Local çalışıyor ✅ Staging çalışıyor ✅ Deploy ediliyor ✅ Backup var ✅ Production anlaşılmış ✅ olmalıdır. Sonrasında geliştirme başlayabilir. İkinci prensip: Aynı anda hem vendor hem mimari değiştirmeyin Mümkünse: Vendor Change ile: Architecture Rewrite ayrı fazlarda yürütülmelidir. Önce sistem üzerinde operasyonel kontrol kurulması, ardından teknik modernizasyon kararı verilmesi riski azaltır. Üçüncü prensip: Şirket hesabı + vendor access modeline geçin Firma değiştiriyorsanız bu aynı zamanda eski sahiplik modelini düzeltmek için fırsattır. Örneğin: GitHub → Company Organization Cloud → Company Domain → Company Store → Company Old Vendor → remove New Vendor → scoped access Bu sayede bir sonraki firma değişikliği çok daha kolay olur. Dördüncü prensip: Devralma sonunda credential temizliği yapın Takeover bitip yeni sistem doğrulandıktan sonra: old credentials old SSH keys old tokens old collaborators temizlenmelidir. AWS'in IAM best practice'leri de artık kullanılmayan kullanıcıların, rollerin, permissions ve credentials'ın düzenli kaldırılmasını; mümkün olduğunda long-lived credential yerine temporary role credentials kullanılmasını öneriyor. (AWS Dokümantasyonu) Beşinci prensip: Handover'ı kişilere değil sisteme bağlayın Şu model kırılgandır: “Deployment'ı Ahmet biliyor.” Daha iyi: CI/CD + Docs + Role-based Access olmalıdır. Şirketler büyüdükçe kurumsal bilgi kişilerin hafızasından süreçlere aktarılmalıdır. Altıncı prensip: Firma değiştirebilmek, sık firma değiştirmek anlamına gelmez Amaç sürekli vendor değiştirmek değildir. Ama sistem: firma değiştirilemeyecek kadar kapalı olmamalıdır. En sağlıklı ticari ilişki: Mecburiyet yerine: Memnuniyet üzerine kurulmalıdır.

Sonuç

Yazılım firmasını değiştirdiğinizde sisteminizin çöpe gitmesi gerekmez. İyi tasarlanmış ve doğru sahiplik modeli kurulmuş bir projede: Source Code + Repository + Cloud + Database + Storage + Integrations + Documentation yeni teknik ekibe devredilebilir. GitHub repository transferlerini resmi olarak destekliyor ve commit geçmişiyle birlikte birçok repository varlığının korunmasına izin veriyor. (GitHub Docs) Vercel de proje transferinde deployment, configuration, domain ve birçok proje unsurunu yeni takıma taşıyabiliyor; ancak integrations ve bazı telemetry/storage öğeleri gibi istisnaların ayrıca yönetilmesi gerekiyor. (Vercel) Mobil tarafta da hem Apple hem Google resmi uygulama transfer mekanizmaları sunuyor; ancak mağaza kaydının transfer edilmesi, kaynak kodun ve bütün teknik entegrasyonların otomatik olarak devredildiği anlamına gelmiyor. (Apple Developer) Bu yüzden firma değişiminde ilk soru: “Yeni firma projeyi anlayabilir mi?” değil yalnızca. Asıl soru: “Şirket olarak sistemimizin çalışması için gereken bütün dijital varlıkları gerçekten kontrol ediyor muyuz?” Cevap evetse yazılım firması değişimi çoğu zaman sıfırdan başlama değil, yönetilebilir bir teknik devir süreci haline gelir.