Migrating to Insites

This page is for anyone moving an existing website or web application to Insites. There are two ways to move. If your site runs on a platform the Insites Migration Tool reads, the tool moves it for you and checks every part. If your site is a custom application, for example one that runs on serverless functions, you rebuild it on Insites with the steps below. An AI assistant connected through CloudShell can do most of that work.

For a list of what Insites does out of the box, and what you build from parts, see What Insites Can Do.

What You Need Before You Start

• An Insites account. Sign up at console.insites.io.
• An Insites instance, with the Developer role or above on it so you can deploy.
• A copy of your source. For a custom application, this is its code, its data exported as JSON or CSV, its email templates, and any user-facing text.
• A list of what the old site does. Every page and its address, every endpoint, every email it sends, every scheduled job, and every outside service it calls.
• An AI assistant that supports remote MCP servers, if you want AI to do the build. See Getting Set Up with AI.
• Access to your domain's DNS, for the last step.
• For the Migration Tool: an invitation to the tool, and the key it asks for on your source platform (see the table below).

Option 1: The Insites Migration Tool

The Insites Migration Tool is at migrate.insites.io. It reads your source, shows you a plan, loads the plan into an Insites instance, and then checks that nothing was lost. It only reads the source. It never writes back to it. Its own documentation is at migrate.insites.io/docs.

Note: Sign-in to the tool is by an emailed link. Only invited people can get one, so ask Insites for an invitation first. To build the same kind of sign-in for your own site, see Passwordless Sign-In.

Sources You Can Move From Today

A custom application is not on this list. Use Option 2.

How a Move Works

1. Connect. Give the tool the key for your source and the GraphQL admin key for your Insites instance. Keys are kept encrypted and destroyed when the move finishes.
2. Plan. The tool lists everything the source holds, with counts, and shows a plan. A part that does not move says why. A plan with a problem, called a blocker, offers the fix that removes it.
3. Load. You start the load by typing the plan's code. You can run a dry run first. A dry run reads your instance and says what a load would write, without writing anything.
4. Verify. Every run ends with checks. Each check has a control that proves it can fail.
5. Cut over. Rehearse the move while the old site stays live. Then freeze the old site, run a final sync that copies only what changed, move the domain, and let the tool watch the new site for 48 hours.

What the Checks Prove

The tool can also roll back a load, and it keeps a PDF report of every decision and every check.

Option 2: Rebuild a Custom Application, Step by Step

Follow these steps in order. The example is an application that runs on serverless functions, with its own sign-in, data, emails and JSON endpoints. Each step links to the page that shows how.

Step 1: Take an Inventory

Write down everything the old application does. For each item, note where it will live on Insites.

Step 2: Create an Instance

In console.insites.io, go to Instances and select CREATE INSTANCE. Choose the Staging environment for the build. See Creating an Instance.

Step 3: Connect an AI Assistant

Add CloudShell to your AI assistant as a remote MCP server, and sign in with your Insites account. In Claude Code:

claude mcp add --transport http insites-cloudshell https://cloudshell.insites.io/mcp

Then give your AI the Insites Logic Engine, the public rules for building on Insites, at github.com/insites-io/insites-logic-engine. Ask it to list your instances and select the new one. See About CloudShell and Insites Logic Engine.

Keep your site code in app/. Put code you want to reuse across projects in modules/<name>/. See Codebase Introduction.

Step 4: Model Your Data

Create one file in app/schema/ for each table. The file name and the name inside it must match.

name: member
properties:
  - name: email
    type: string
  - name: language
    type: string
  - name: joined_at
    type: datetime

See Database Fields and Tables.

Step 5: Rebuild the Pages

Each page is one file in app/views/pages/. Its slug sets the address. Each page answers one HTTP method. A JSON endpoint is a page with format: json, and it answers at a clean address with no .json on the end:

---
slug: api/auth/request-code
method: post
format: json
---
{% comment %}public endpoint: anyone may ask for a sign-in code{% endcomment %}

An endpoint that both reads and writes is two pages: one with method: get and one with method: post. Put the shared logic in a partial that both pages render. See Pages.

Code that ran on the server of the old platform is rebuilt in Liquid and GraphQL. It is not converted.

Step 6: Rebuild Sign-In

Insites signs a person in with the sign_in tag, so sign-in does not need a password. An emailed link or a 6-digit code is built from your users, a table, a registered email and the sign_in tag. The page that a link opens must never sign the person in by itself, because email scanners open links first. See Passwordless Sign-In. To limit who can sign in, see Email Allow-List. To slow down repeated failures, see Rate Limiting by IP.

If the old admin area used one shared password, replace it with an admin role. See Admin Role Instead of a Shared Password.

Step 7: Move Your Translations

User-facing text does not have to be written in English in the code. Put each language in its own file in app/translations/, and show text with the t filter. The page uses the language you set, for example from the language parameter. See Multi-Language Sites.

Step 8: Rebuild the Emails

Each email becomes an email notification template in app/emails/, sent by its name. Pass the values it needs as one Liquid variable. An email written inline, with no registered template, sends nothing. To send an email in the person's language, keep one template per language, such as welcome_en and welcome_es, and choose the template by the language the person picked. See Passwordless Sign-In and Multi-Language Sites.

Note: A staging instance does not send email to real people. Each email goes only to the test email recipients you set in the instance settings, with the intended recipient shown in the subject line. Until you set test recipients, you receive nothing. See Staging vs. Production and Creating an Email Notification.

Step 9: Load Your Data

Export your data from the old system and load it into your tables. The Insites CLI imports a JSON file, or a zip file with --zip:

insites-cli data import staging --path data.json

A CSV file must be converted first. See Importing JSON or CSV Data.

Step 10: Deploy

Choose one way to deploy:

• CloudShell. Your AI deploys each file and reads the logs to check its work. See CloudShell Tools.
• The Insites GitHub App. Every push to the branch your instance watches deploys automatically. See Insites GitHub App.
• The Insites CLI. Run insites-cli deploy staging. See Insites CLI Tool Commands and Options.

Note: A full insites-cli deploy removes files from the instance that are missing from your local build. To keep them, use insites-cli deploy staging --partial-deploy.

Test everything on staging. Then create a production instance and deploy the same code to it.

Step 11: Move the Domain

1. Load the latest data into production.
2. In Insites Console, open the production instance, go to the Domains tab and select Connect domain. The wizard walks you through the DNS records to add. See Instance Domains.
3. Change your DNS records to point at Insites.
4. Check every page and endpoint on the new domain, then switch off the old application.

Custom domains work on production instances only.

What Is Not Imported

• Server code from another platform. Functions, workers and API handlers are rebuilt in Liquid and GraphQL. Nothing converts them.
• Passwords from another platform, unless the Migration Tool moves them from another Insites instance. Siteglide and Squarespace do not give out passwords, so people set a new one or sign in with an emailed link. See Passwordless Sign-In.
• Form emails from Webflow, Siteglide and Squarespace. Set them up on Insites after the move.
• Outside integrations and their keys. Set them up again, and add each key as a constant.
• Translations when moving between Insites instances. The tool tells you if the site uses them. Deploy them with the Insites CLI.
• Your DNS. You change the records yourself.

Each connector has more detail on what does not move yet. See its page on migrate.insites.io/docs/connectors.