Email migration post-mortem: the migration wasn’t the problem. The flashlight was

TL;DR: Our email migration from @sandstream.pl to @sanddev.com in Sandtime.io went flawlessly: it broke nothing and fixed things quietly broken. What it really did was expose long-standing problems: a disk-space fire, an unmigrated QA alias, OAuth sign-ins silently failing for two weeks, and our own anti-bot tool crashing our Sandtime.io desktop app.

What actually went wrong during our email migration?

Nothing. The email migration was boringly perfect. When Sandtime.io launched, Sanddev was still Sandstream Development, so everyone logged in with @sandstream.pl. Moving to @sanddev.com broke nothing, it even fixed logins that had misbehaved for months.

The punchline: 90% of CIOs have seen failed or disrupted data migrations, but the real damage is what a clean email migration drags into daylight. Ours found four skeletons.

Why did a Friday fire nearly upstage a Monday email migration?

Because disk space doesn’t read calendars. The email migration was set for Monday. On Friday (sic!), during a live on-stage Sandbot demo – Sandtime’s shiny new feature – staging ran out of space mid-build. We doubled staging on the spot. It hurts, so band-aid first, surgery later. Elegant? No. Alive? Yes.

How did one QA alias survive a company rename?

By hiding in plain sight. Everyone at Sanddev uses name.surname – except QA, logging in everywhere as qa-tester@sandstream.pl. The alias never got migrated, qa-tester@sanddev.com didn’t exist, and QA was locked out of Sandtime. It took embarrassingly long to spot: nobody audits the account that tests everything^^

Why were sign-ups dropping before the email migration even happened?

Because Google won’t let you type passwords inside apps – rightly so. Thanks to Zuza, we cracked the sliding sign-ups mystery: a change two weeks earlier made our app open Google/Yahoo/Microsoft logins inside the app, not a browser. Google blocks OAuth in embedded webviews because a host app could read your keystrokes. Two weeks of silent errors. Then Rafał pinged post-migration: “not working.” Final bingo – new Mac users couldn’t log in at all. 

How did our anti-bot protection start attacking our own app?

Cloudflare Turnstile evolved; our app didn’t. Turnstile guards our login (loaded only when you start typing – you’re welcome, page speed). But it’s a remote script that changes dynamically, and one update started crashing our un-updated app. Fixes aren’t instant: 90% of Apple submissions are reviewed within 24 hours, but store review still kills “just ship it.” Workaround: Turnstile off for desktop apps.

Risky? Mildly. Our attacks are classic credential stuffing – 19% of all authentication attempts, behind 88% of basic web app attacks, succeeding just 0.2–2% of the time – except we have no password login to stuff. Plot twist: with 51% of web traffic now automated and 37% outright malicious, our bot wall was so strong that good bots – AI crawlers – couldn’t see us either. AI can’t recommend what it can’t read.

What’s the real lesson from this email migration post-mortem?

An email migration is a flashlight, not a wrecking ball. Ours exposed stale apps (last store update: 2022!), ancient dependencies (hello, forced Node.js v20 downgrade), and login-analytics blind spots. AI-assisted debugging now surfaces such problems faster than users complain. New apps are coming. Planning your own move? See how to run migrations that don’t implode and how we built Sandtime.

FAQ