DEV Community: Hüseyin Çınar

Migrating a live IoT platform off self-hosted Kubernetes - without a single forced app update

Hüseyin Çınar — Sun, 19 Jul 2026 02:25:28 +0000

In January 2024 I took over the backend of WeWALK, a smart cane platform for visually impaired people. The codebase dated back to 2020 and had passed through a few hands before mine - and underneath it was a live production system with real users depending on it.

27,000 registered users, to be exact - and I want to be honest about that number: it is not impressive. People migrate databases with millions of users and write nothing about it. What made this migration interesting was not how many users there were. It was three other things:

The users cannot be interrupted. For many of them the app is part of how they get around a city. "Please update to continue" is a minor annoyance in a food delivery app; in an accessibility product it can mean someone's cane stops talking to their phone while they are out somewhere. So one rule was fixed before any planning: nobody gets forced to update. Every client binary in the field keeps working.
The data never stops arriving. These are not users who open an app twice a day. Every active cane sends a 102-byte diagnostic snapshot roughly every ten seconds, flowing into a partitioned time-series table. Multiply by a fleet of devices and you have a write stream that never pauses - including during your migration. There is no maintenance window when the "users" are canes on the street.
The data was heterogeneous. MongoDB and PostgreSQL on the old cluster, Firestore entering the picture on the new one, plus IAP billing events, a rules-based entitlements engine, and an audit trail doing JSONB before/after diffs. This was not one big table to copy. It was several kinds of data with different consistency needs, all moving at once.

Oh, and one more thing: the old cluster was effectively a black box.

Starting from backups

The stack ran on a self-hosted Rancher/Kubernetes cluster. By the time the migration started, working access to that environment was no longer practical - the kind of thing that happens naturally over years of team and vendor transitions, and more common in the industry than anyone likes to admit. What we did have, reliably, was backups.

So the plan became: reconstruct what the system actually was from its backups, and bring that up on Google Cloud Run, Cloud SQL and Firestore instead of trying to revive the old machines.

If you have never rebuilt a system you cannot inspect, I recommend it as an educational experience and nothing else. You find out exactly which parts of the configuration were written down and which parts had never made it into documentation anywhere. Every service that came up was a small negotiation between what the backup said, what the code expected, and what production traffic proved.

Old endpoints, new cloud

Part of the platform lived on AWS, and the mobile apps talked to WebSocket endpoints there. Those addresses are baked into client binaries in the field. Moving to GCP the normal way means new endpoints, which means a mandatory update - the one thing we had ruled out.

So the old endpoints simply never died. I built a Lambda-to-Cloud-Run proxy that keeps the existing AWS WebSocket addresses alive and forwards everything to the new infrastructure. The oldest client build in the field talks to the same address it always did; it just has no idea the thing answering it moved. Nobody updated anything. Support tickets from the migration: none that I know of.

The most valuable tool was a diff

Later we moved nine services between regions, europe-west3 to europe-west1. The thing that saved us was not clever. Before cutover I diffed the configuration of every service between source and target - every environment variable, every setting, service by service.

That diff caught four missing environment variables. Four. Any one of them would have been a production incident discovered at the worst possible time. After years of running both Kubernetes clusters and serverless platforms, my honest conclusion is that migrations rarely fail in interesting ways. They fail because an env var didn't come along. Diff first. It is boring and it works.

Moving data that will not sit still

The data layer had its own migration, Firestore to PostgreSQL - executed while the telemetry stream kept writing. We did it as a dual-write: write to both stores, keep reading from the old one, and put the read cutover behind an environment flag. When the new store had proven itself under the live write load, we flipped reads. The old path stayed in place as an escape hatch, with graceful degradation if anything went sideways.

The time-series side needed its own care: continuous device snapshots do not tolerate a "stop the world, copy, restart" approach, which is exactly why the table is partitioned and why the cutover had to be a flag flip rather than a batch job.

That schema has since grown from 34 tables to about 95, across 174 migrations. The system that had to be rebuilt from its backups in early 2024 is now the boring, observable, redeployable kind of production system I like to run.

What stayed with me

The "no forced updates" constraint felt like a burden and turned out to be a filter. It eliminated every lazy option early, and what survived was genuinely better architecture. And the two least glamorous artifacts of the whole project - a pile of backups and a configuration diff - did more for those users than anything clever I wrote.

If you are inheriting an undocumented production system: test whether you can rebuild from your backups before you need to, and diff your configuration before every cutover. That is the whole post, really.

HTTP finally has a QUERY method. I spent an hour finding out what works today

Hüseyin Çınar — Sun, 19 Jul 2026 02:22:41 +0000

I have built more search endpoints than I can count. Candidate search in a recruitment platform, dealer listing filters with saved searches in a vehicle marketplace, telemetry queries in an IoT dashboard. And every single time, the same uncomfortable choice comes up at design time, and every time there are exactly three bad options.

Option one: GET with a query string. Works great until the filter object grows. A saved search with fifteen filters, sort orders and pagination does not belong in a URL. You hit length limits, you fight encoding, and the whole thing ends up in access logs.

Option two: GET with a body. Elasticsearch made this famous, and it has been making people miserable ever since. The old HTTP specs never said what a GET body means, so clients, proxies and load balancers each picked their own behavior - some drop it, some forward it, some reject the request outright. You cannot build on semantics nobody agreed on.

Option three: POST /search. This is what I have done for years, like almost everyone. It works. It is also a small lie. A search is safe and repeatable - it changes nothing on the server - but POST tells every intermediary the opposite. No shared caching. No automatic retry on a dropped connection, because a proxy has to assume a POST might have side effects. You give up real, useful HTTP behavior just to be allowed to send a body.

Last month this stopped being a "pick your poison" situation. RFC 10008, published June 2026 after fourteen draft revisions, defines the QUERY method: a request with a body, like POST, but explicitly safe and idempotent, like GET - and with cacheable responses. It is precisely the missing verb for "here is a complex description of what I want; this changes nothing".

QUERY /vehicles HTTP/1.1
Content-Type: application/json

{ "filters": { "fuel": "ev", "battery_health_min": 85 },
  "sort": "price_asc", "page": 3 }

What actually works today

Reading about a new RFC is one thing. I wanted to know what happens when you actually send a QUERY request in 2026, so I spent an hour finding out. Everything below is a real result from my machine, not from documentation.

Node.js 24: works out of the box. http.METHODS includes QUERY as a first-class method, and a plain http.createServer receives it like any other request:

// server logs: { method: 'QUERY', receivedBody: '{"filter":{"status":"active"}}' }
const server = http.createServer((req, res) => { /* req.method === 'QUERY' */ });

fetch: works. Node's built-in fetch (undici) sends method: 'QUERY' with a body without complaint. The fetch spec only forbids CONNECT, TRACE and TRACK, so QUERY passes - though I have only verified server-side fetch, not every browser, so treat browser support as "test before you rely on it".

curl: works, since a custom method is just curl -X QUERY --data ....

Cloudflare: passes it through. I sent a QUERY request to this very site, which runs on a Cloudflare Worker serving static assets. The response was a clean 405 Method Not Allowed - meaning the edge did not choke on the method; it delivered it to the handler, and the handler correctly said "static files don't do that". For a brand-new verb, the method traveling untouched through a major CDN is the important part.

ASP.NET Core: there is no MapQuery() helper yet, but routing has always supported custom methods, so endpoints.MapMethods("/search", ["QUERY"], handler) routes it today.

Would I use it in production?

On a public API, not yet. The RFC is a month old; API gateways, WAF rules, OpenAPI tooling and client SDK generators all need time, and a search endpoint that some corporate proxy silently mangles is worse than an honest POST.

But on internal APIs - service-to-service, admin panels, anything where I control both ends - I intend to start now. The retry semantics alone are worth it: an idempotent search can be safely retried by infrastructure when a connection drops, which is exactly the kind of resilience you otherwise have to build by hand. My plan is to introduce it on an internal admin search endpoint first and let it earn its way outward.

Twenty-five years of POST /search was a workaround. It is nice to finally have the real verb.