Bring an AI-assisted code project into Wappler
Assess an existing code project, choose what to reuse and verify one working feature before expanding the migration.
Assess an existing code project, choose what to reuse and verify one working feature before expanding the migration.
Also called: existing code, AI-assisted project, migration, Cursor, GitHub Copilot, Aider, Continue, Augment, Windsurf, Zed, Trae, Antigravity, Bolt.new, Lovable, Replit, Supermaven.
Before you begin
Section titled “Before you begin”- Access to the source project, its setup instructions and a development environment for testing.
Start with the project, not the editor name
Section titled “Start with the project, not the editor name”An app’s framework, runtime, data and build process determine the work needed to use it in Wappler. The AI tool that wrote a file does not determine whether Wappler can visually edit it. Obtain the source project or repository through your tool’s supported export workflow, keep a recoverable copy, and run its existing setup before changing it.
Identify what carries over
Section titled “Identify what carries over”Read the project’s README, package/build configuration and deployment settings. Separate reusable assets and data from framework-specific behavior.
| Existing project part | What to assess |
|---|---|
| Existing Wappler project | Open its project configuration and inspect its current targets and included extensions. Keep the same page/action conventions unless you intentionally change them. |
| HTML, CSS and images | These can be inspected as files. Check the framework and the selected element’s supported inspector controls before expecting a particular visual editing workflow. |
| JSX, Vue components or another application framework | Opening source files does not convert the framework’s component state or templates into App Connect bindings. Decide whether to keep its build workflow, integrate an API boundary or rebuild a particular screen with supported Wappler components. |
| Server code and API endpoints | Record each endpoint’s method, inputs, authentication and response shape. Existing server code does not automatically become a sequence of Server Connect steps. |
| Database and uploaded files | Identify schema, ownership rules, data-export needs and storage locations. Copying source files does not copy a hosted database or an upload bucket. |
| Environment and build settings | Record required variable names, runtime/dependency versions and build commands. Configure credentials in the appropriate project environment; they are not source-code examples to paste into AI prompts. |
Choose the appropriate project setup
Section titled “Choose the appropriate project setup”Use Project Manager to open the existing project or create a project from its Git repository. Select a development environment and server model compatible with the intended app. Changing Server Model is a configuration decision, not an automatic conversion of arbitrary server code. If you are new to Wappler, finish the small beginner course first so you can recognize its page and action structure.
Move one feature across a clear boundary
Section titled “Move one feature across a clear boundary”Choose a read-only screen first, such as a product list. Keep its endpoint contract fixed while you build the page. Use an API Data Source for a browser-accessible JSON endpoint, or a Server Connect component for a Wappler action. Use a server-side API Connector when an upstream service requires a private credential. Verify the response before binding the UI.
Example: reuse a products endpoint
Section titled “Example: reuse a products endpoint”Suppose a development endpoint GET /api/products returns {“products”:[{“id”:1,“name”:“Notebook”}]}. On an App Connect page, add API Data Source named apiProducts and set its URL to /api/products. Turn No Auto Load off so the request runs when the page loads. Declare that response shape in Define API Schema for the picker. Repeat apiProducts.data.products and bind name inside the repeat. Confirm Notebook appears, then test an empty collection and an error response. No database conversion is required for this page example because the endpoint remains the data boundary.
Give AI a bounded change to make
Section titled “Give AI a bounded change to make”Describe the page/component, the existing data contract, the intended edit and the expected result. For example: “On public/learn.html, show apiProducts.data.products in a table with the current record’s name. Keep the endpoint and authentication unchanged. Show loading, empty and error states.” Review the proposed changes in the relevant editor and source files; a plausible explanation is not evidence that the feature works.
Verify before moving the next feature
Section titled “Verify before moving the next feature”Inspect the changed files, run the project’s applicable checks and test the page against the endpoint. Check data shape, scope, navigation, responsive layout and failure states. For writes, also verify server validation, authorization and the stored result. When using more than one editor, save and review changes deliberately so one editor’s stale buffer does not overwrite the other’s work.
Continue with the needed workflow
Section titled “Continue with the needed workflow”Choose the next guide according to the work you identified, rather than a tool ranking.
Check your result
Section titled “Check your result”You can identify reusable files and data, choose an integration boundary and verify one page without assuming automatic framework conversion.