Migrating an Existing Base44 App to Knack

What You'll Learn

This article walks you through migrating an existing Base44 app to Knack, so Knack holds your data, your users, and your access rules while Base44 keeps building your screens. It covers the order to do things in so your data is never exposed, and how to prove the migration worked.

Before You Start: Why Order Matters

Migrating creates a second copy of your data. Until the old copy is locked down and deleted, your app is only as secure as its weakest backend.

The safe order is to secure Knack first, test the switch before your users see it, and remove the old backend last.

The Migration Sequence

Follow these phases in order. Each one depends on the one before it.

Phase 1: Capture a Baseline

Before you change anything, record what your app shows today. You'll compare against this after the move.

Capture the record count for each table, the numbers on any dashboard, and every field value for one reference record. Then export each Base44 table as a CSV from the Base44 Data view.

Phase 2: Connect Base44 and Build Your Knack Tables

Connect the Knack MCP Server in Base44 first. See Connecting Base44 to Knack: Complete Setup Guide for the connection steps.

Then ask Base44 to create a new Knack app with tables that match your Base44 tables. Be specific about field types in your prompt.

Tell your builder which dates are calendar dates

Expiration dates, due dates, and birthdays are calendar dates, not moments in time. Ask your builder to create them as date-only fields with no default date.

If date fields are created with a time, dates can display one day early for anyone west of your Knack app's timezone. The stored value is correct, but it looks wrong. The fix is to set the field to ignore time.

Keep the old IDs for matching connections

Base44 stores relationships as its own record IDs. Those IDs mean nothing to Knack.

Add a Base44 ID text field to each Knack table and fill it during the move. Knack can then match connections on that field, so every record links to the right parent.

Create connections after the tables

Knack creates connection fields in a separate step after the tables exist. Move parent tables first, then child tables. For example, move facilities, then providers, then credentials.

Phase 2 Continued: Move Your Data

You have two ways to move records.

If Base44 moves the records, some writes may report an error even though the record saved. A good builder checks before retrying. Ask yours to confirm it won't create duplicates.

Verify every record

Export each Knack table and compare it to your Base44 export, matched on the Base44 ID field. Check the count, every field, every connection, and every date.

Phase 3: Lock Down Knack

Set up your user roles and data access rules before your app points at Knack. Your AI builder can configure data access control through the MCP, including turning enforcement on.

After it reports done, open the Knack Builder and confirm three things. Enforcement is on. Each role has the access you intended. The Public (Not Logged-In) role has No Access in both the Owned by User and All Other Records columns.

Keep user registration off unless your app needs open sign-up.

Phase 4: Register the Sign-In Client

Knack sign-in for a Base44 app needs an OAuth client with three redirect URLs, one for each address your app runs on.

The sandbox URL uses your Base44 App ID, not your Knack application ID. You'll find it in Base44 under Dashboard, then API, then Authentication.

Phase 5: Switch Sign-In and Data to Knack

Ask Base44 to replace its login with Knack sign-in first, then switch data in a separate step. Testing them one at a time tells you which part broke if something fails.

When you ask for the data switch, include these requirements in your prompt:

• Use the signed-in user's Knack session for every request
• Send the knack-client-timezone header with every request
• Treat date-only fields as calendar dates with no timezone conversion
• Load all records and handle pagination
• Refresh the session so it doesn't expire mid-use
• Show a visible error if a request fails, and never fall back to Base44 data

Lock the Base44 tables during the switch

Set each Base44 table's permissions to admin only. Your app keeps working for you as the builder, and nobody else can reach the old data.

Phase 6: Test Against Your Baseline

Sign in to your published app in an incognito window, so no old Base44 session interferes. Then check each of these:

• Dashboard numbers match your baseline exactly
• Your reference record matches field for field
• Dates match, including records moved in different batches
• Printed or exported reports match
• Adding a record in your app creates it in Knack
• Editing a record in your app updates it in Knack
• Deleting a record in your app removes it from Knack
• Signed out, every page sends you to sign-in

Records created from your app are owned by the signed-in user. Records you migrated are owned by App Builder. See Who Owns a Record if your access rules depend on ownership.

Phases 7 and 8: Cutover and Clean Up

Ask Base44 to remove its own sign-in pages, including registration, and every remaining reference to the Base44 tables. Publish, then test again in an incognito window.

Delete the Base44 tables last, by hand, from the Base44 Data view. Run Base44's security scan one final time.

Troubleshooting

Next Steps

• Connecting Base44 to Knack: Complete Setup Guide covers the MCP connection and building a new app from scratch.
• Checking That Your Access Rules Actually Work shows how to prove your data access rules are enforced.
• Knack MCP Server vs. Runtime Data API explains why the MCP builds your app while the Runtime Data API runs it.