İşi durdurmadan geçiş: 5 milyon kullanıcıya 12 OTA güncellemesi ve eski platformun bedeli

Yılda 5 milyon kullanıcısı olan bir uygulama üç ayda yeniden yazıldı, herkes bir gecede yeni sürüme geçirildi, ardından üç gün boyunca canlı ortamda havadan güncellemelerle onarıldı. Aynı hafta Camunda ve Twilio eski platformun ne zaman tamamen değiştirilmesi gerektiğini, ne zaman üstüne bir katman eklemenin yeteceğini tartışıyordu. İşletme sahibi için iki hikâye de aynı soruyla ilgili: araç teslimini ya da talep kabulünü durdurmadan yeni sisteme nasıl geçilir.

TeamReach'in geçiş gecesi

Expo blogunda 14 Ekim'de TeamReach'in başkanı Gene Cornfield'ın anlatımı yayımlandı. Bu, spor takımları için program ve sohbet uygulaması, yılda yaklaşık 5 milyon kullanıcı. Mart 2026'da yeni sahipler satın aldı ve ellerine iki ayrı native uygulama geçti; altında migrasyonsuz MariaDB üzerinde PHP ve 100 milyar satırlık tek bir tablo vardı. Her düzeltme uygulama mağazalarının incelemesinden geçiyordu ve yazara göre bu, başka bir yol aramaya zorladı.

Dört kişilik ekip uygulamayı yaklaşık üç ayda Expo üzerinde yeniden yazdı ve veritabanını da Postgres'e taşıdı. Herkesi 28 Haziran gecesi geçirdiler, hata bildirimleri dakikalar içinde gelmeye başladı. İlk dört saatte üç OTA güncellemesi çıktı, sonra üç gün “öğlen ve gece yarısı” ritminde devam etti. Toplam on iki güncelleme; yazara göre işi bozan her şey bir gün içinde düzeltildi. Bu üç gün yaklaşık 4.000 dolara mal oldu.

OTA güncellemesi yalnızca üst katmanı, JavaScript'i ve stilleri değiştiriyor; native koda dokunan her şey yine mağaza incelemesinden geçiyor. Yayımlamak teslim etmek anlamına da gelmiyor: uygulama güncellemeyi açılışta alıyor, bu yüzden TeamReach'te düzeltme herkese yaklaşık bir günde, insanlar uygulamayı açtıkça ulaştı.

Eski platformda yaşamanın bedeli

Camunda 22 Ekim'de Pega üzerinde yaşamanın maliyetini yazdı. Bu, kendisine geçmeye çağıran bir tedarikçinin yazısı, ama argüman dürüst: lisans nadiren en pahalı kalem oluyor. Platformu bilen uzmanlar ve her basit değişiklik için alınan hizmetler daha pahalıya geliyor. Üçüncü-dördüncü yıla gelindiğinde her entegrasyon ayrılmamak için bir neden daha ekliyor. Geçişi iki korku engelliyor: aynı anda iki platforma ödeme yapmak ve net tarihli bir geçiş sahibinin olmaması.

CustomerThink 13 Ekim'de Smart Communications'ın müşteri iletişimi geçişiyle ilgili basın bültenini yayımladı: sistem eski belgeleri ayrıştırıp yeni şablonlara dönüştürüyor, her dönüşümü insanlar kontrol ediyor. Bültende IDC verisi aktarılıyor: kuruluşların %57'si müşteri iletişimini eski sistemlerde tutuyor.

Twilio blogunda 16 Ekim'de yığını değiştirmeden müşteri hizmetini yenileyen beş yöneticinin örneği toplandı. Sweetwater kendi CRM'ini korudu ve içine ses ile SMS'i yerleştirdi: günde 50.000 mesaj ve 40.000 arama, yeni çağrı merkezi yapılandırmaları ise iki günden kısa sürede devreye alınıyor. Yazarın düşüncesi: yeni katman çalışmazsa altındaki sistemler çalışmaya devam eder; değiştirme projesi ise bütçe harcandıktan sonra dokuzuncu ayda duvara toslar.

İşletmeye ne faydası var

Rezervasyonların üç yıldır tabloda yaşadığı ve yeni uygulamanın çoktan yazıldığı bir araç kiralama şirketini ele alalım. Sezon ortası, teslimi bir hafta kapatmak mümkün değil. Herkesi pazartesi geçirirseniz çarşamba günü bir çalışan, cuma günü eski tabloya girilen rezervasyonu bulamaz. Sonuç: geçişi iki sistemin yan yana yaşadığı bir dönem olarak planlamak gerekiyor; doğru kaynağın artık hangisi olduğuna dair bir kuralla ve geri dönüş yoluyla.

Şirketleri yeni sistemlere nasıl geçirdim

ABD'de 2021'den beri teknik ortağı olduğum PDR şirketinde geçiş birkaç yıl sürdü, adım adım, ve her adım zaten çalışan bir şeye dayanıyordu. 2021'de veriler Google E-Tablolar'da ve AppSheet uygulamalarında yaşıyordu. 2023'te hız ve tek bir veri formatı için SQL veritabanına geçmeyi önerdim. Fikir kabul gördü; MariaDB'ye geçtikten sonra yeni servisleri birer birer bağladık, GoHighLevel entegrasyonunu ise bütün yıl geliştirdim. Şimdi GoHighLevel ana CRM olmaktan çıkıp yardımcı sisteme dönüştü; AppSheet'in yerini şirketin geliştiricileriyle birlikte yaptığımız React Native süper uygulama alıyor: TestFlight'ta, ofis ve satışçılar zaten kullanıyor. Her yeni parçayı çalışanın yanında açtık, eskisini sonra kapattık.

Şirket içi bir servis olan “Birlikte Kahve”de Ekim 2026'daki geçiş daha küçüktü, ama kural aynıydı. Çalışanların bir kısmı hâlâ Google E-Tablosu üzerinden sipariş veriyordu, bu yüzden ön izlemeli bir içe aktarma yaptım: her satır kontrol ediliyor, hata aktarımı engelliyor, benzer ürün yerine konulmuyor. İçe aktarma günlüğü siparişi kaynak satırın numarasına bağlıyor; böylece tekrar yükleme kopya oluşturmuyor, değiştirilmiş satırı ise servis çakışma olarak gösteriyor.

Ben ne yapardım

Geçişin sahibini ve tarihini belirleyin. TeamReach'te bu 28 Haziran'dı; tarih olmadan geçiş, Camunda'nın yazdığı gibi yıllarca planlarda kalıyor.

Katmanları ayırın. Ekranlar havadan güncellenebilir, veritabanı ise yalnızca migrasyonlarla ve yedekle; mantık kendi sunucusunda yaşar. Eski sistemi en azından birkaç hafta salt okunur olarak açık bırakın.

İnsanları ilk güne hazırlayın. TeamReach'te bir destek çalışanı 36 saat boyunca destek taleplerinin başında oturdu ve şikâyetleri mühendisler için grupladı. Böyle birini önceden atayın.

Platformu tamamen değiştirmek korkutucuysa üstteki katmandan başlayın. Güney Afrika'daki araç kiralamada her şey AmoCRM ile tablo bağlantısından büyüdü.

Tablolardan ayrılma zamanının geldiğini gösteren işaretler hakkında: işletmenin ne zaman tablo yerine sisteme ihtiyacı var. Alanlara göre: tek bir sistem olarak işletme ve talepten sonraki adıma kadar süreç otomasyonu. Projeler: ABD'deki PDR şirketinin teknik ortağı ve “Birlikte Kahve”. Aynı konuda: uygulamanın yıllık güncelleme döngüsü ve API sürümleri ve kapatma tarihleri; daha önce platform değiştirirken neyin korunacağını ve CRM geçişinde verinin nasıl kontrol edileceğini yazmıştım. Önünüzde bir geçiş varsa şu an neyin çalıştığını ve neyin durdurulamayacağını anlatın: Görevi konuşalım.