Migrating a Draftbit Classic app
If you built an app in Draftbit Classic, the original V1 builder, you don’t have to rebuild it. Migration creates an upgraded copy of the app in the new builder, where you can keep working on it with the AI app builder and the Code Editor.
Migration copies your app and leaves the original in Draftbit Classic, so the Classic version keeps working and you can migrate it again later. The only change made to the Classic app is turning on Expo Router, if it isn’t on already.
To bring in code from somewhere other than Draftbit Classic, such as a GitHub repository or a zip file, see Importing from GitHub instead.
Before you start
Section titled “Before you start”- Use the same account. The migration page lists the Classic workspaces and apps that belong to the account you’re signed in with.
- Have edit access. You need the Owner, Admin, or Editor role in the organization you migrate the app into. See Team and seats.
- Check your project count. Each migrated app is created as a new project. The Free plan includes up to 3 projects. If you’re at the limit, clicking an app opens an upgrade prompt instead of the migration dialog. Standard and up have no project limit.
- Turn on Expo Router. A Classic app must have Expo Router enabled before it can be migrated. You can enable it from the migration page, as described below.
Find your Classic apps
Section titled “Find your Classic apps”In the Dashboard sidebar, open Migrate and select V1 Apps. The Import V1 Apps page lists your Classic apps.
- V1 Workspace: choose which Classic workspace to show. Your personal workspace is selected first.
- Search apps…: filter the list by app name, description, or app ID.
Apps are sorted by when they were last updated and split into two groups:
- Ready to Migrate: apps that already have Expo Router enabled.
- Requires Action to Migrate: apps that need Expo Router turned on first. These cards are dimmed and show a warning icon.
Enable Expo Router
Section titled “Enable Expo Router”Click an app under Requires Action to Migrate. The Enable Expo Router to Migrate dialog opens. Click Enable Expo Router.
This changes the Expo Router setting on the Classic app itself. The update can take a few minutes. When it finishes, the app moves to Ready to Migrate.
If you need to turn it off again after migrating, open the three-dot menu on the app’s card under Ready to Migrate, select Disable Expo Router, and confirm. The app can’t be migrated again until you re-enable it.
Migrate the app
Section titled “Migrate the app”- Under Ready to Migrate, click the app.
- In the Migrate App dialog, use Migrate to organization to choose where the new app goes. It defaults to the organization you’re working in.
- Click Migrate App.
The builder opens the new app while the migration finishes in the background. It usually takes a few minutes, depending on the size of the app. You can leave and come back; its card on the Projects page shows Importing with a progress bar until it’s done.
If a migration fails, the partly created app is removed and your Classic app is unchanged. Try again, and contact support if it fails more than once.
Migrating an app again
Section titled “Migrating an app again”If an app has already been migrated, the Migrate App dialog says so and links to view the migrated app. To create another copy, click Migrate Again. Each migration creates a separate app; it doesn’t update the earlier copy.
What gets copied
Section titled “What gets copied”Migration copies:
- Your app’s code and image assets.
- The app name, description, and icon.
- Your iOS bundle ID and Android package name.
- The version name and version code of the latest published build for iOS, Android, and web. Production builds are used when there are any, otherwise development builds.
- Your App Store Connect API key and Google Play service account, if you’d set them up for publishing.
- Your GitHub export repository, branch, and access token, if the app was exported to GitHub.
- Your environment variables.
Environment variables are mapped onto the new app’s environments like this:
| In Draftbit Classic | In the new builder |
|---|---|
| Production | Production |
| Development | Development and Staging |
| Same value on every platform | One variable |
| Different values per platform | One variable per platform, named with an _ANDROID, _IOS, or _WEB suffix |
Name starts with EXPO_PUBLIC_ | Plain text |
| Any other name | Sensitive |
Legacy V1 REST API services
Section titled “Legacy V1 REST API services”REST API services you set up in Draftbit Classic come across as code files in the app’s apis folder. The builder reads those files and lets you view, edit, and test them as Legacy V1 services.
To find them, open Integrations and select the REST APIs tab. Legacy services appear under Configured with a Legacy v1 badge, their base URL, and their endpoint count. The app’s sandbox has to be running for them to load. If you see “Sandbox isn’t running yet”, open the app, then reload the page.
Click a legacy service to open it. The header shows the base URL and the file path, along with these actions:
- Edit file opens the service’s file in the Code Editor, which requires the Standard plan or higher.
- Remove service deletes the file, including all of its endpoints. This can’t be undone.
- Edit service details opens the service settings. It’s hidden while the file is read-only.
Service details
Section titled “Service details”| Setting | What it does |
|---|---|
| Base URL | The root URL every endpoint path is added to. |
| HTTP mode | The fetch mode: cors, no-cors, same-origin, or Not set. |
| Credentials | Whether cookies and other credentials are sent: include, omit, same-origin, or Not set. |
| Query arrays | How array values are written into the query string: brackets, comma, repeat, or Not set. |
| Service headers | Headers sent with every endpoint in the service. |
Click Save service to apply your changes. Saving rewrites the file in the standard V1 format.
Endpoints
Section titled “Endpoints”The left panel lists the service’s endpoints. Select one to edit it:
| Setting | What it does |
|---|---|
| Path | The endpoint path, added to the base URL. Insert {{name}} to create a path variable, for example /users/{{id}}. |
| Role | What the endpoint does: GET_ONE, GET_MANY, CREATE, UPDATE, DELETE, or Not set. |
| Cache key | The key used to cache the endpoint’s results. |
| Headers | Headers sent with this endpoint only. |
| Query params | Query string parameters, each with a value and a Required checkbox. |
| Path variables | The {{name}} variables found in the path. |
| Request body | A JSON template for the request body, using {{name}} for variables. Not available for GET endpoints. |
A header whose value comes from a Classic global variable shows a Constants badge and the variable’s name. You can’t edit that value in place; remove the header and add it again to change it.
Click Save to write your changes to the file. A dot on the button and in the endpoint list marks unsaved changes.
Generated symbols shows the names the file exports for the endpoint, so you can find them in your code: the Hook, the Fetch wrapper, and the Endpoint key.
Testing an endpoint
Section titled “Testing an endpoint”Fill in Test values for the endpoint’s variables, including any Constants used in headers, then click Test in the response panel. Optional query parameters can be left empty. The response panel shows the status, headers, and response body.
Tests run against the saved file, so save your edits first if you want them included.
Read-only legacy files
Section titled “Read-only legacy files”If a service’s file has been changed in ways the builder can’t safely rewrite, such as custom code added to it, the service opens as read-only. It shows a Read-only badge, a Read-only legacy file notice explaining what differs, and the fields can’t be edited. You can still test its endpoints, or change the file directly with Edit file.
To edit it with the form again, click Overwrite with standard format, then Yes, overwrite file. This regenerates the file and keeps as much of the service as it can, but any custom code or values the standard format doesn’t support are discarded. Check the file in the Code Editor first if you’ve made changes you want to keep.
Styles from Draftbit Classic
Section titled “Styles from Draftbit Classic”An imported app keeps the styles Draftbit Classic generated. Each component’s styles are code that combines your theme, shared styles from GlobalStyles.js, and values for each screen size. The app runs the same as before, but the Styles tab can’t edit these styles. When you select a component that uses them, the Styles tab lists them as read-only with a note that they come from Draftbit Classic.
To make them editable, select Migrate styles with AI below that note. It starts a new agent thread with a prompt to migrate your whole app to NativeWind classes, which the Styles tab can edit. Nothing changes until you review the prompt and send it. The agent then:
- Moves your theme’s colors, including dark mode colors, and its typography into the app’s NativeWind theme, keeping their names recognizable.
- Writes shared styles out as classes on each component that uses them, so you can edit them in the Styles tab.
- Rewrites each screen’s styles as classes, one screen at a time, and checks the preview after each one so your app keeps its look.
- Moves styles that change with screen size to the standard breakpoints the Styles tab uses: Classic’s Tablet, Laptop, Desktop, and BigScreen sizes become sm, lg, xl, and 2xl. These switch at slightly different widths (640, 1024, 1280, and 1536 pixels instead of 480, 992, 1440, and 1920), so a layout can change a little earlier or later than before. Parts of a screen that appear or hide at a certain screen size switch at the same new widths, so everything on a screen still changes together.
- Removes Classic’s style files once nothing uses them.
A large app can take more than one message. The agent tells you which screens are done and which are left, and continues when you ask.
After the migration, your theme’s colors and text styles live in the app’s NativeWind setup, so changes on the Themes page only reach screens that haven’t been migrated yet. Ask the agent to change colors and text styles on migrated screens.