Move a static Netlify site to Hostbrid Projects

Before leaving Netlify, find out which parts of your website depend on Netlify. A site that builds static files can be straightforward to move; forms, functions, redirects and previews for changes may need replacements. Changing hosts does not automatically migrate those features or their data.

Hostbrid Projects may fit if your repository builds web files that you want to publish from Git. Check the workflow and plan on Projects and pricing. This guide does not call one provider best for everyone; it helps you check whether your specific app can move without losing behavior.

1. Inventory your setup before disconnecting Netlify

Review the repository, site configuration and Netlify dashboard. Look for:

• netlify.toml, package.json scripts, build command, Node version and publish directory.
• netlify/functions/, Edge Functions, plugins, environment variables and API calls.
• Forms with data-netlify="true" or netlify, and the service that receives and stores submissions.
• Redirect and header rules, SPA routes, absolute links and URLs used by search engines.
• Domains, DNS, certificates, OAuth integrations, webhooks, databases and file services.
• Deploy Previews: Netlify can create previews for proposed changes; do not assume the destination offers the same workflow.

Netlify documents its managed forms, functions and Deploy Previews. Note which features you actually use. A netlify.toml file may contain essential configuration even when the site looks static.

If you do not know what happens after a form is submitted, first follow this guide to check a form, backend and delivery.

2. Test the build from the repository

Do not migrate from a screenshot or development folder. Use a clean working copy to reproduce the build:

git clone REPOSITORY_URL migration-test
cd migration-test
npm ci
npm run build

These commands are an example for a Node project with package-lock.json. If the project uses pnpm, Yarn, another Node version or a different command, follow the versions and scripts declared by the project. Check the configuration and verify where the output actually goes; names such as dist, build and out are not interchangeable.

Open the result locally with the framework’s preview server or a static server. Check the home page, a deep URL, direct refresh, CSS, JavaScript, images and console errors. If the app needs server functions, a successful build does not prove those functions will exist on static hosting.

3. Publish a test copy from Git

Connect the repository in Projects, choose the right branch and configure the install/build commands and output directory. Check the build log and visit the Projects test address before connecting the final domain. Review the current plan terms: the free subdomain, custom domain and persistent services may have different conditions.

Test the same pages and actions you recorded in your inventory. For an SPA route, enter it directly in the browser and refresh; navigation that only works from the home page is not enough. Also check robots.txt, canonicals, internal links, language, HTTP status and that downloaded files contain no credentials.

Projects publishes from Git and supports configurable build commands and output directories according to its product page. Do not assume this replaces Netlify Forms, its previews, Edge Functions, server functions, plugins or custom headers. If you need a persistent backend, check the service workflow, resources and price before ordering it.

4. Replace dependencies before changing DNS

If the site uses forms, configure the new endpoint first and test both successful and failed submissions. Verify that the message reaches the intended destination; a browser’s “sent” screen does not prove delivery.

For each Function, identify its method, route, variables, permissions, storage and response format. Decide whether it should remain an external service, run as a compatible backend or be managed on a VPS. Never commit secrets to Git or put them in variables that become part of browser JavaScript.

Recreate redirect and header rules using a feature the destination documents, then test each rule. Also check sign-in, payments, email, webhooks, CORS limits and routes called by the app. If you cannot replace a dependency, keep the current site available while you resolve it.

5. Change the domain with a rollback ready

Keep the same public routes where possible. If you only change hosts while keeping the domain and URLs, test the new site first and then update the required DNS records. Record the old values and keep Netlify available until you have checked HTTPS, important URLs, forms, access, analytics and email.

If you also change the domain or routes, prepare a one-to-one URL map and direct permanent redirects. Update canonicals and internal links on the new site; do not redirect every page to the home page. Google recommends testing the new site, mapping old URLs and enabling redirects for a URL or domain move. A technical migration does not guarantee rankings will be preserved or that Google will crawl pages immediately.

Do not delete the old deployment as soon as DNS changes. First check routes with and without www, the certificate, redirects, assets, indexable pages and business functions. For general architecture guidance, see where to host an AI-built website; for a React/Vite app, also check builds, routes and Git deployment.

When it makes sense to stay on Netlify

It may be better to keep the site where it is if it depends on Forms, Functions, Edge, plugins or previews that your workflow needs and you have not validated replacements. Moving may also not be worthwhile if cost, domain control or team requirements do not improve at the destination. Compare Netlify’s current features and prices with Projects plans and limits using your actual account usage.