The No-Code to Custom Code Migration Checklist: 28 Items We Run on Every Cutover

The founder hits send on the Bubble export, watches the CSV land in their Downloads folder, and assumes the hard part is done. Three weeks later, live traffic is hitting a new Next.js app, the database looks correct, and yet paying customers cannot log in, Stripe is double-charging two percent of subscribers, organic traffic is down forty percent, and the file attachments on every support ticket point to a domain that no longer exists. This is not a rare outcome. It is the default outcome when teams treat a no-code migration as a port rather than as a rebuild with data continuity.

We have moved roughly forty products off Bubble, Webflow CMS, Softr, Glide, Adalo and Retool at WitsCode. The pattern that separates a clean cutover from a two-month firefight is not technical talent. It is a checklist, run in order, with no skipped items. The list below is the one we use internally. It is twenty-eight items grouped into eight phases, and every item on it exists because we have watched a migration fail without it.

This article is not a pitch for custom code over no-code. No-code platforms are a rational choice for the first 10,000 dollars of monthly revenue. The question is what happens when you outgrow them, and the answer is that the migration has to be engineered, not improvised.

Phase One: Data Export and the ID Remapping Trap

The first phase is export, and the first trap is the one almost every team falls into. You run the platform's native export, get a set of CSVs or a JSON dump, import it into your new Postgres instance, and the row counts match. The export looks clean. It is not clean.

The trap is that no-code platforms use internal unique identifiers that do not survive the export in a usable form. Bubble generates a unique_id string per record and references it across tables. Airtable uses record IDs like recAbc123. Webflow CMS uses item IDs tied to collection IDs. When you import these into a relational schema with fresh sequential primary keys, every foreign key relationship silently breaks. Your users table and your orders table now have no way to reference each other unless you explicitly preserve the old IDs in a dedicated column.

Item one on our checklist is a full schema audit of the source platform, including every relation field, lookup, and rollup. Item two is an ID remapping plan: we keep every original platform ID as a legacy_id column on every table, indexed, and we build the new foreign keys by joining on those legacy IDs during import rather than generating them fresh. Item three is nested relation flattening. Platforms like Bubble let you embed arrays of related records directly in a parent record. Postgres does not. We decide per-field whether the nested data becomes a proper join table or a jsonb column, and that decision is documented before a single row is written.

Item four is the file attachment audit, and it is the quiet killer. Bubble, Softr and Airtable all host uploaded files on their own CDN. The export gives you URLs, not the files themselves. If you cut over your app and leave those URLs pointing at the old platform, you have thirty to ninety days before the old account is cancelled or the URLs stop resolving. We write a script that walks every attachment URL, downloads the file, re-uploads it to S3 or R2 under a stable path, and rewrites the URL column in the new database. This job usually takes longer than the rest of the data migration combined on any app with user-generated uploads.

Phase Two: Re-architect Before You Rebuild

The temptation after export is to open the new codebase and start porting pages one for one. This is the second most common failure. A no-code schema is shaped by what the no-code editor made easy, not by what the domain actually requires. Porting it verbatim locks in five years of accidental complexity.

Item five is a domain model review. We take every table, every workflow, and every page and ask whether it still belongs. In a recent Bubble migration we collapsed fourteen tables into six. Three tables existed only because the founder had not realised Bubble let you filter on a related field. Item six is workflow consolidation. No-code apps tend to accumulate workflows that fire on every page load because adding one was cheaper than debugging why state was stale. In a proper backend, those become either database triggers, a single cached query, or they are deleted outright.

Item seven is a background job inventory. No-code platforms hide scheduled tasks inside the editor. Before you cut over you need a written list of every recurring job, its frequency, what it reads, what it writes, and what downstream system expects its output. We have seen migrations go live without the nightly invoice-generation job because nobody thought to look for it. Item eight is the choice of stack, and we make it after the domain model is settled, not before. The stack serves the model, and for most post-no-code rebuilds that means Next.js or Remix on the front end, a Postgres database behind a typed ORM, and a queue worker for anything the old platform ran as a background workflow.

Phase Three: Rebuild with a Parallel-Run Window in Mind

Rebuild is the phase founders think the whole project is about. It is actually the phase where the checklist most matters, because decisions made here determine whether cutover is a fifteen-minute DNS flip or a three-week panic.

Item nine is building the new app behind feature flags from day one. Every new route, every new form, every new API endpoint has to be switchable per user. This is what makes the parallel-run window possible later. Item ten is writing a two-way sync, not a one-way import. During the parallel-run window, which is usually seven to fourteen days, both the old no-code app and the new app will have live users. Any record created or updated on either side must appear on the other. We use a change-data-capture pattern: a scheduled job every five minutes reads recently-modified records from the no-code platform's API and upserts them into the new database, and a reverse job pushes new-app changes back.

Item eleven is a reconciliation report. Every hour during parallel-run, a job compares row counts and checksums across both systems and emails the team if they diverge. Item twelve is the rollback plan, written down, rehearsed once. If anything goes wrong post-cutover, you need to know how to send traffic back to the old platform in under five minutes. That means DNS TTLs dropped to sixty seconds before cutover, both environments kept live for at least a week after, and a documented sequence for flipping back.

Phase Four: The Auth Cutover and the Magic Link Reset

Auth is the phase where most migrations visibly break, and it breaks because no-code platforms do not export usable password hashes. Bubble, Softr and Glide all hash passwords with their own salt and algorithm. Even when the export includes the hash string, you cannot validate a user's password against it in your new system without reimplementing their hashing function, which most platforms will not document.

Item thirteen is accepting that password migration is not possible and planning around it. Item fourteen is the forced password reset via magic link. On cutover day, every active user in the database gets a one-time email: "we have upgraded our platform, click here to set your new password." The link carries a short-lived signed token that, when clicked, creates a session and drops them into a password-set form. Item fifteen is the grace period. For the first fourteen days after cutover, any login attempt on an un-reset account also triggers a magic link instead of a password-failed error. This single decision prevents roughly half of all post-cutover support tickets.

Item sixteen is session continuity for users who were logged in at the moment of cutover. We invalidate all old sessions deliberately and route every user through the magic-link flow once, because trying to preserve live sessions across two different auth systems is how you end up with users logged in as other users. Item seventeen is two-factor re-enrolment. If the old platform had TOTP or SMS 2FA, those secrets almost never export. We surface a prominent re-enrolment prompt in the new app for any user who had 2FA on the old platform, and we do not trust the old flag silently.

Phase Five: Integration Re-wiring Without Double-Firing

Every no-code app at any real scale is wired into a web of external services. Stripe for billing, Postmark or Resend for email, Segment or PostHog for analytics, Slack and Notion for internal ops, Zapier or Make for the glue. On cutover day every single one of those integrations has to switch endpoints cleanly, without firing twice and without going silent.

Item eighteen is the integration inventory. We open the old platform's connections list, every Zap, every webhook, every API plugin, and we write down the trigger, the destination, and the payload shape. Item nineteen is Stripe, which gets its own subsection because it is where double-charging lives. The old Bubble or Webflow app almost certainly owns the Stripe customer IDs and subscription IDs. You do not create new ones. You take over the existing Stripe account by moving API keys and webhook endpoints to the new app, and you update the webhook signing secret in one coordinated step. If you fire up the new app while the old webhooks are still live, Stripe will deliver every invoice.paid event to both, and your email system will thank the customer twice while your database marks the invoice paid twice.

Item twenty is the webhook pause-and-replay. During the cutover window, we disable outbound webhooks on the old platform, hold the queue for thirty minutes, point the endpoints at the new app, and then replay the held events. Stripe, Shopify, and most modern platforms support this natively. Item twenty-one is the email sender reputation carry-over. If your transactional email comes from a sending domain authenticated via SPF and DKIM, those DNS records need to resolve correctly from the new sending infrastructure on cutover day. We set up the new DKIM keys a week ahead and verify them before switching traffic.

Phase Six: User Re-onboarding Without Losing the Room

The users do not care that you migrated. They care that things still work. Item twenty-two is the pre-cutover announcement, sent seven days out, written in the voice of the product, explaining that a short maintenance window is coming and what will change for them. The only change users should have to action is the password reset. If you are asking them to re-enter billing details, re-connect integrations, or re-upload files, you have a migration problem, not a communication problem.

Item twenty-three is the in-app re-onboarding modal. On first login to the new app, every returning user sees a short, dismissible walkthrough of anything that has visibly changed: new navigation, moved settings, renamed features. We keep this under four screens. Item twenty-four is the support readiness pack. Before cutover we write a one-page internal FAQ for the founder and any support staff covering the twelve questions we know will come in: where did feature X go, why did I get a password email, my file link is broken, my integration stopped. These tickets arrive in the first forty-eight hours whether you prepare for them or not.

Phase Seven: SEO Preservation and the 301 Map

For any product with meaningful organic traffic, SEO preservation is the most reversible of the post-cutover disasters and therefore the one founders tolerate worst. It is also the most preventable.

Item twenty-five is the full URL inventory. We crawl the old site with Screaming Frog before cutover, export every indexed URL, and cross-check against Google Search Console's coverage report and Ahrefs or Semrush's top-pages export. This is the ground truth for what Google thinks your site is. Item twenty-six is the 301 map. Every old URL gets a target new URL in a spreadsheet, and every 301 is implemented at the edge, not inside the application, so redirects resolve in a single hop without a render cycle. Webflow to Next.js migrations are particularly exposed because Webflow's URL structure for CMS collections (/blog/post-slug) often changes under the hood when rebuilt, and a missed redirect on a category page can lose a cluster of rankings in a week.

Item twenty-seven is the technical SEO parity check. Title tags, meta descriptions, canonical tags, structured data, sitemap.xml, and robots.txt all need to match or improve on the old site on launch day. We run a pre-launch audit that diffs every public URL's <head> across old and new. If the old site had JSON-LD for articles or products, the new site ships with it from the first deploy, not from a follow-up ticket. We also submit the new sitemap to Search Console the hour cutover completes, and we watch the coverage report daily for the next two weeks for any spike in 404s or soft-404s, which is the earliest signal that a redirect is missing.

Phase Eight: Cutover and the Parallel-Run Window

Cutover itself is the shortest phase if the preceding twenty-seven items are done. Item twenty-eight is the cutover runbook, a single document that lists every action in order with timestamps and owners. The runbook we use has roughly forty lines covering: drop DNS TTL to sixty seconds, run final data sync, pause old-platform writes, run reconciliation report, flip DNS, invalidate CDN, point Stripe webhooks, send magic-link reset batch, enable new-app write paths, re-enable monitoring alerts, confirm. A typical runbook executes in under forty-five minutes of actual downtime, though the full parallel-run window we keep open behind it runs seven to fourteen days.

During parallel-run the old platform stays live but read-only for logged-in users as a fallback. Every support ticket that arrives gets tagged with a migration label so we can see clustering in one view. At day seven we review the ticket queue, the reconciliation reports, and the Search Console coverage. If all three are clean, we tear down the old environment at day fourteen. If any one is not clean, we extend the window and fix before we tear down. We have never regretted extending. We have regretted tearing down early.

Every item on this list exists because a migration failed without it. The ID remap failed for a SaaS we inherited from another agency and lost every historical comment thread. The magic-link reset was the difference between a Softr migration where support tickets spiked for three days and one where they never spiked at all. The 301 map was what kept a Webflow-to-Next.js cutover from losing its top-of-funnel organic traffic during the quarter the founder was raising a seed round. The parallel-run window was what let us roll back a Bubble migration at day four when we discovered the original platform had been silently de-duplicating email addresses on write, and reversing that behaviour broke a downstream CRM sync we had not inventoried.

A no-code to custom code migration is a rebuild, a data project, an auth project, a DevOps project, an SEO project, and a customer communications project running simultaneously on the same three-week timeline. Any one of them going sideways takes the other five with it. The checklist is what keeps them in lane.

If you are approaching the ceiling of Bubble, Webflow, Softr, Glide, Adalo or Retool and your next move is custom code, this is the list you should run against whatever plan you have today. If you want a team that has run it forty times and has the tooling already written, that is the WitsCode migration engagement. We will scope your specific platform, your specific data shape, and your specific integration surface in a single week and give you a fixed cutover date. Tell us which platform you are leaving and we will send back the exact version of this checklist for your stack.