Cutover without stopping work: 12 OTA updates for 5M users and what an old platform costs

An app with 5 million users a year was rewritten in three months, everyone was switched over in one night, and then the team spent three days fixing it in production with over-the-air updates. The same week, Camunda and Twilio argued about when an old platform needs replacing entirely and when a layer on top is enough. For a business owner, both stories are about one question: how to move to a new system without stopping car handovers or incoming requests.

TeamReach's cutover night

On October 14, the Expo blog published an account by Gene Cornfield, president of TeamReach. It's an app for sports team schedules and chats, with about 5 million users a year. In March 2026 new owners bought it and got two separate native apps, and underneath them PHP on MariaDB with no migrations and a single table of 100 billion rows. Every fix went through app store review, and by the author's account that is what pushed them to look for another way.

A team of four rewrote the app on Expo in about three months and moved the database to Postgres along the way. Everyone was switched over on the night of June 28, and error reports started coming in within minutes. Three OTA updates went out in the first four hours, then three days at a “noon and midnight” pace. Twelve updates in all, and everything that broke the app, by the author's account, was fixed within a day. Those three days cost about $4,000.

An OTA update changes only the top layer, JavaScript and styles; anything that touches native code still goes through store review. And publishing isn't delivery: the app picks up the update on launch, so at TeamReach a fix reached everyone over about a day, as people opened the app.

The cost of living on an old platform

Camunda, October 22, wrote about the cost of living on Pega. It's a vendor piece inviting you to move to them, but the argument is honest: the license is rarely the most expensive part. The specialists who know the platform cost more, and so do the services needed for every simple change. By year three or four, every integration adds a reason not to leave. Two fears block the move: paying for two platforms at once, and having no migration owner with a clear deadline.

CustomerThink, October 13, published a Smart Communications press release about migrating customer communications: the system parses old documents and turns them into new templates, and people check every conversion. The release cites IDC data: 57% of organizations keep customer communications on outdated systems.

The Twilio blog, October 16, collected five examples of executives who upgraded customer service without changing their stack. Sweetwater kept its CRM and built voice and SMS into it: 50,000 messages and 40,000 calls a day, and new contact center configurations deploy in under two days. The author's point: if the new layer fails, the systems beneath it keep running, while a replacement project hits a wall in month nine, when the budget is already spent.

Why this matters to a business

Take a rental company where bookings have lived in a spreadsheet for three years and the new app is already written. The season is in full swing, and closing handovers for a week is out of the question. Switch everyone over on Monday, and on Wednesday a manager won't find the booking that was entered into the old spreadsheet on Friday. So plan the move as a period when both systems live side by side, with a rule about where the truth now lives and a way back.

How I have moved companies to new systems

At a PDR company in the US, where I've been the technical partner since 2021, the move took several years, step by step, and each step rested on what already worked. In 2021 the data lived in Google Sheets and AppSheet apps. In 2023 I proposed moving to a SQL database for speed and a single data format. The idea was approved, and after the move to MariaDB we connected new services one after another, while I kept refining the GoHighLevel integration all year. Today GoHighLevel has gone from the main CRM to a supporting one, and AppSheet is being replaced by a React Native super app that we're building together with the company's developers: it's in TestFlight, and the office and the sales team already use it. We switched on each new part next to the working one and turned the old one off afterward.

At the “Coffee Together” service in October 2026 the move was smaller, and the rule was the same. Some employees were still ordering through a Google Sheet, so I built an import with a preview: every row is checked, an error blocks the transfer, and no similar product gets substituted. The import log ties each order to the number of its source row, so loading the file again doesn't create duplicates, and a changed row shows up as a conflict.

What I would do

Name the owner of the move and a date. For TeamReach it was June 28; without a date, a migration sits in the plans for years, as Camunda writes.

Separate the layers. Screens can be updated over the air, the database only with migrations and a backup, and the logic lives on its own server. Keep the old system switched on for reading for at least a few weeks.

Prepare people for the first day. At TeamReach a support employee sat in the tickets for 36 hours and grouped complaints for the engineers. Assign that person in advance.

If replacing the whole platform is scary, start with a layer on top. At the rental in South Africa, everything grew out of connecting AmoCRM to a spreadsheet.

On the signs that it's time to leave spreadsheets: when a business needs a system instead of spreadsheets. By area: the business as a single system and process automation from request to next action. Cases: technical partner of a PDR company in the US and the “Coffee Together” service. On the same topic: the annual app upgrade cycle and API versions and shutdown dates; earlier I wrote about what to preserve when changing platforms and how to check data during a CRM migration. If you have a move ahead, tell me what works now and what can't be stopped: Discuss your task.