Back to BlogEngineering

Building Datrift: Seamless Google Account Migration

TechZunction Team15 March 202610 min read

Switching Google accounts sounds simple until you realise how much of your life is scattered across Drive, Gmail, Photos, Calendar, Contacts, YouTube, and Tasks. There is no official way to move everything from one account to another — Google Takeout lets you export a ZIP archive, but importing that archive into a different account is a manual, service-by-service ordeal. We built Datrift to solve this problem once and for all: connect your source and destination accounts, pick the services you want to migrate, and hit go.

The core of Datrift is an Express backend powered by BullMQ running on Redis. When a user kicks off a migration, we create a parent job and fan out child jobs — one per service. Each child runs its own dedicated handler (drive.handler.ts, gmail.handler.ts, photos.handler.ts, and so on) that knows how to read from the source account's API and write to the destination. This fan-out model lets us migrate services in parallel, and BullMQ's built-in retry, backoff, and dead-letter queue mechanics handle the inevitable transient failures from Google's rate-limited APIs.

OAuth was the trickiest part of the system. Each user connects two Google accounts, which means we manage two independent access/refresh token pairs per session. Tokens expire every hour, and Google's per-user rate limits are surprisingly tight — 10 queries per second for most services, 250 quota units per second for Drive. We built an error-classification layer that categorises failures into auth errors, rate-limit errors, quota errors, network errors, and data errors. Rate-limit and quota errors trigger exponential backoff with jitter; auth errors trigger a silent token refresh. The classifier surfaces a human-readable explanation to the user, so they know exactly what happened and why.

On the frontend, we use Next.js 15 with Zustand for state management and Supabase Realtime for live progress updates. As each file, email, or photo transfers, the backend writes a structured log to the migration_logs table in Supabase. The frontend subscribes to that table's Realtime channel and renders an activity feed in real-time — complete with per-item status icons, byte counts, and error details. The result feels like watching a deployment log: you can see every item as it moves, and if something fails, you know exactly which file and why.

Security was non-negotiable. All OAuth tokens are encrypted at rest with AES-256 before being stored in Supabase. We never touch user data beyond what is necessary for the transfer — files stream directly from source to destination via Google's APIs without being stored on our servers. The credit-based billing model charges per GB transferred, with unused credits automatically refunded. After months of iteration, Datrift now handles end-to-end migration across 7 Google services with a 99.9% success rate, and the architecture is designed to extend to Microsoft 365, Yahoo, iCloud, and Dropbox as we expand multi-provider support.

Stay in the loop

Get our latest articles on engineering, design, and building digital products — delivered straight to your inbox.