Before You Migrate: Reviewing Your App's Features
Before you move an app built in Lovable, Base44, or Claude Code onto Knack, list every feature that sends, stores, or processes data, and decide what to keep, move to Knack, rework, or remove.
What You'll Learn
Before you move an app you built in a frontend builder onto Knack, review every feature that sends, stores, or processes data. This article shows you how to get a full inventory from your frontend builder, sort each feature into keep, move to Knack, rework, or remove, and catch exposure issues you should fix right away.
Why Features Don't Move on Their Own
Frontend builders make it easy to add texting, notifications, AI summaries, file storage, and connections to outside services. Many of these run on the builder's own backend, not in your screens.
When Knack becomes your backend, your data, sign-in, and access rules move. Those features don't move with them. Each one needs a decision, and some may be sending information you didn't know about.
It's common to find features you forgot you built, or that connect to services you didn't realize were involved. That's why this review comes before the migration, not after.
Step 1: Get an Inventory from Your Frontend Builder
Ask your frontend builder to list everything that touches data. This prompt is read-only and asks for names and behavior, not record values, so no personal information ends up in the chat.
Audit only. Do not change any code, data, settings, secrets, or connections. Do not create anything in Knack.
Do not show any record values, personal information, API keys, or secret values. Report names, structure, and behavior only.
1. SCREENS AND FORMS: every screen or form that creates or edits data, which tables it reads and writes, which roles use it, and whether it handles health or personal information (yes / no / unsure)
2. BACKEND LOGIC: every backend function, edge function, database trigger, or scheduled job, what starts it, what it does step by step, and what data it touches
3. EMAILS, TEXTS, AND NOTIFICATIONS: every message the app sends, what triggers it, who receives it, which service sends it, and exactly which fields are included
4. AI FEATURES: every feature that uses AI, what it does, which AI service it calls, and exactly which data is sent to it
5. OUTSIDE SERVICES AND SECRETS: every external service the app connects to and what data is sent to each, plus every stored secret or API key by name only, and what it's used for
6. FILES AND EXPORTS: every place users upload files, every PDF, export, or download the app creates and which fields it includes, and whether any file link or storage is publicly accessible
7. LOGGING AND ANALYTICS: any analytics, error tracking, or logging tools, and whether they could capture health or personal information
8. ANYTHING YOU COULD NOT CONFIRM: list it plainly. Do not guess.
Finish with "Audit complete. No changes made."Step 2: Check the Inventory
Frontend builders can describe an app confidently and still miss what's running. Before you rely on the list, check it against what you know.
- Spot-check two or three features you know well, like an email you receive or an AI summary you use
- Ask about anything you remember building that isn't on the list
- Put every "unsure" on a discussion list, not the migration list
If something is missing or unclear, ask your frontend builder to take a second look.
Audit only. Make no changes.
1. For every item you marked "unsure," explain in plain language what it does and what data it touches.
2. Check again for anything you may have missed: emails, texts, scheduled jobs, AI features, file storage, outside services, and logging.
3. I remember the app doing [describe the feature]. Where is it, and what data does it use?
Do not show any record values, personal information, API keys, or secret values.Step 3: Decide What Happens to Each Feature
Sort every feature into one of four decisions.
| Decision | When it fits | Example |
|---|---|---|
| Move to Knack | Knack already does this job | Required fields, notification emails, audit logs |
| Rework | It's needed, but it sends or stores data it shouldn't | An AI summary that sends full patient notes |
| Keep | It doesn't touch sensitive data | Staff training videos, links to a meeting tool |
| Remove | Nobody uses it, or Knack makes it unnecessary | A custom login page, a duplicate activity log |
Your frontend builder can suggest a starting point. You make the final call.
Read-only. Make no changes.
Using the audit you just completed, suggest a decision for each feature: keep, move to Knack, rework, or remove. Knack will be the backend for data, sign-in, and access rules.
For each feature, give me:
- The decision you suggest
- One plain-language sentence explaining why
- The data it touches, and whether that includes health or personal information
Present it as a table. Mark anything you're unsure about.Record each decision in a simple list: the feature, the data it touches, the decision, and who will do the work. That list becomes your migration checklist.
Features Knack Can Take Over
Many features your frontend builder built have a Knack equivalent that runs every time a record is saved, including saves from your custom frontend.
| What your app does today | Knack equivalent |
|---|---|
| Required fields and value checks | Validation rules |
| Setting a value based on other values | Conditional rules |
| Emails or updates when a record changes | Knack Flows |
| Reminders and jobs on a schedule | Scheduled tasks |
| Tracking who created or changed a record | System fields and record history |
Knack Flows are set up in your Knack account. Your frontend builder can't create them for you, so add them to your plan. See Where Your App's Logic Belongs: Knack or Your Custom Frontend for how each one works with a custom frontend.
Your own activity log may not be neededIf your app keeps its own log of who changed what, Knack's record history may cover it, including changes made from your custom frontend. See Security Basics for a Custom Frontend.
Features That Send Data Somewhere Else
Emails, texts, AI features, and outside services all send data out of your app. For each one, look at exactly which fields it sends.
- If it doesn't need sensitive information, leave that information out. "A new visit was added. Sign in to view it." works as well as a message full of details.
- If it does need sensitive information, review your compliance requirements before you move it. Confirm the service is allowed to receive that data.
- Stored secrets and API keys for outside services are a normal part of how these features work. Keep track of each one and what it's used for.
Rework a feature to send less
Use this prompt for any email, text, notification, or AI feature you're keeping but want to send less.
For the [feature name] feature, change what it sends so it includes only what it needs to work.
Remove these fields from what it sends: [list fields]. For a notification, send a short message that tells the person to sign in to see the details.
Before changing anything, show me exactly what it sends today and what it will send after the change. Wait for my approval.Remove a feature you don't need
Remove the [feature name] feature completely, including its screens, backend functions, scheduled jobs, and any stored secrets it uses.
Before removing anything, list every file, function, and secret you plan to remove or change, and anything else in the app that depends on it. Wait for my approval.Open your app after the change and confirm everything else still works.
Building a HIPAA app?Any feature that would send health information to an outside service, AI tool, or message provider needs a compliance review first. See HIPAA Compliance Overview.
Fix Exposure Issues Now
Some findings can't wait for the migration. If the inventory turns up either of these, fix them right away.
- Public file links or storage. Anyone with the link can open the file.
- Logging or analytics that capture personal information. Turn it off or remove the personal information.
Fix these issues found in the audit:
1. Make every public file link and storage location private, so only signed-in users with access can open files.
2. Stop logging and analytics tools from capturing health or personal information.
Before changing anything, list what you'll change and how it affects users. Wait for my approval. After the change, tell me how I can confirm a file link no longer opens when I'm signed out.Then test it yourself. Copy a file link, sign out, and open it in a private browser window. It shouldn't load.
Pause New Features During the Migration
Once you start the migration, stop adding new features to the old app. Your team can keep using it day to day. A feature added mid-migration is one more thing to review, and it's easy to miss.
Common Mistakes
- Trusting the inventory without checking it. Spot-check features you know, and ask about anything missing.
- Moving every feature as is. Some are better handled by Knack, and some aren't needed at all.
- Sending full records in notifications. Send only what the message needs.
- Leaving "unsure" items for later. Decide on each one before you move data.
- Building new features during the move. Pause until the migration is done.
Next Steps
- Where Your App's Logic Belongs: Knack or Your Custom Frontend: Decide where each rule and automation should live.
- Migrating an Existing Base44 App to Knack: Move a Base44 app onto Knack, step by step.
- Connecting Knack to an Existing Lovable App: Move a Lovable app onto Knack, step by step.
Updated 3 days ago