All essays
Migration field notesJan 9, 202612 min read

The anatomy of a Base44 migration: the Audienceswop playbook

Twelve critical issues caught before launch. AWS in the client's name. The actual sequence — pre-migration audit, conversation-state dual write, function-per-tool rebuild, parallel-run window, hard cutover — told in the order it happened.

Hamza Yasin
Hamza Yasin
Co-founder · Infrastructure & AI
Migration field notes

Audienceswop's prototype was already running on Base44. Eight active creators, one paid customer, conversation history they couldn't lose. We had four weeks to migrate without taking the product down.

This is the actual sequence, in the order it happened. The dates are calendar days from contract signing.

Step 1 — Pre-migration audit (days 1-5)

Read every Base44 workflow. Map every external integration. Pull a sample of conversation state. Identify the twelve things we'd have to rebuild differently because Base44 abstracted them in ways AWS doesn't.

  • 14 workflows mapped, 3 collapsed into one
  • 6 external integrations catalogued — 4 OAuth, 2 webhook-based
  • Conversation state schema documented and dual-write target designed

Step 2 — Parallel infra build (days 6-19)

AWS account in the client's name from day one. Aurora Postgres, Lambda, EventBridge, SQS, SES, S3. Terraform from the start — no console clicks beyond the root account setup. The whole thing was reproducible from a single repo before any data moved.

Step 3 — Conversation-state dual-write (days 20-23)

Before flipping any traffic, we mirrored every new conversation turn into both Base44 and our Aurora. This let us verify the new system's reads matched Base44's reads for a full week before any switching.

Step 4 — Function-per-tool rebuild (days 20-26)

Base44's tool-call abstraction got rebuilt as one Lambda per tool. Twelve Lambdas, each with its own deploy, its own logs, its own permissions. The blast radius from any one tool's failure dropped to that tool — instead of the whole agent runtime going down.

Step 5 — Parallel-run window (days 24-26)

Both systems live. Reads served from Aurora; writes mirrored to both. Cron job comparing rows hourly. Zero drift after 72 hours.

Step 6 — Hard cutover (day 27, Sunday 02:00 EST)

DNS flip. Base44 writes stopped. Aurora writes continued. Eight active conversations survived the cut; one user noticed, sent a thumbs-up emoji about the slight UI change.

The cutover took 47 minutes. Most of that was watching dashboards waiting for something to go wrong.

What we'd do differently

The dual-write window should have been seven days, not three. We caught the one drift case on day six — a Base44 workflow we'd missed that wrote to a column we hadn't mirrored. Caught in time, but it was close.

Tip

If you're migrating off a no-code platform with stateful workflows, dual-write everything for at least a full business week. Drift always shows up on a Monday.

Hamza Yasin
Written by
Hamza Yasin

Co-founder. AI + DevOps craft. Reads logs at 2am so the clients don't have to.

LinkedIn

Got a project we should write about next?

Start with a $499 audit. Five business days, fixed price, real plan.