Migration workflow

Add Nift to the website you already have.

One of Nift's easiest adoption paths is not a rewrite at all. Keep the site's HTML, CSS, JavaScript, assets and runtime architecture; use Nift to extract the repetition and add a fast tracked build layer around it.

Keep your HTML. Keep your tools. Stop repeating yourself.

If an existing site already works, Nift does not need you to translate it into a different component model before it can help.

The kind of site this helps immediately

index.html
about.html
services.html
work.html
contact.html

Every page repeats:
  <!doctype html>
  <head>...</head>
  header / navigation
  footer
  CSS / JS references

That repetition is already telling you where the first template and partial boundaries are.

Before

<!-- about.html -->
<!doctype html>
<html>
  <head>
    <title>About</title>
    <link rel="stylesheet" href="assets/css/site.css">
  </head>
  <body>
    <header>
      <a href="index.html">Home</a>
      <a href="about.html">About</a>
      <a href="contact.html">Contact</a>
    </header>

    <main>
      <h1>About us</h1>
      <p>Page-specific content...</p>
    </main>

    <footer>...repeated footer...</footer>
    <script src="assets/js/app.js"></script>
  </body>
</html>

After: the page-specific content stays almost untouched

<!-- content/about.html -->
<h1>About us</h1>
<p>Page-specific content...</p>

The repeated shell becomes the template

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>$[title]</title>
    <link
      rel="stylesheet"
      href="@pathto('public/assets/css/site.css')">
  </head>
  <body>
    @input('templates/partials/header.html')

    <main>
      @content
    </main>

    @input('templates/partials/footer.html')

    <script
      src="@pathto('public/assets/js/app.js')"></script>
  </body>
</html>

The repeated navigation becomes a partial

<header>
  <a href="@pathto('/')">Home</a>
  <a href="@pathto('about')">About</a>
  <a href="@pathto('contact')">Contact</a>
</header>

The result is not a new frontend architecture. It is the same frontend with the duplicated structure factored out.

A practical migration sequence

Make a comparison copy

Keep the current site available so you can compare generated output and appearance during the migration.

Initialise Nift

Run nift init .html and configure public/ as your web-facing output convention.

Keep existing assets

Copy or preserve the site's CSS, JS, fonts, images and other assets. They do not need to be rewritten.

Choose one representative page

Pick a page containing the normal header, footer and layout rather than migrating every page at once.

Extract the template shell

Move shared document structure into the template and replace the unique page region with @content.

Extract obvious partials

Header, navigation, footer and repeated page furniture can move behind @input.

Track the remaining pages

Move each page's unique markup into its content file and add the tracked names Nift should manage.

Replace fragile local paths

Use @pathto where shared partials link to tracked pages or concrete local assets.

Build and compare

Run nift build-all, compare the generated site to the original and correct any deliberate path/layout differences.

Then stop thinking about migration

Once the output matches, develop normally. New pages can use the shared template from the start.

You can migrate gradually

Nift does not require every file in the repository to become tracked on day one. A practical project can move the repetitive HTML pages first while leaving unrelated assets, application code and tooling untouched.

Existing TypeScript/Vite project

before:
  src/
  assets/
  vite.config.ts
  several hand-maintained HTML entry pages

after:
  content/
  templates/
  src/                 ← still TypeScript/Vite
  vite.config.ts       ← still Vite
  public/
  .nift/

Nift can own document composition while Vite continues owning the frontend asset pipeline.

Existing backend application

application/
  content/             ← page-specific frontend HTML
  templates/           ← shared frontend shell
  public/              ← generated frontend/assets
  server/              ← Go / Node / Python / etc.
  .nift/

The backend does not become a Nift backend. It simply serves or deploys the files Nift generates.

AI-assisted migration

This is also a strong coding-assistant task because the transformation is mostly structural refactoring rather than framework translation. Give an assistant the current site plus the Nift context and ask it to identify repeated document structure while preserving output.

Read ai-context.txt and inspect this existing website.

Convert the repeated document structure into Nift templates and
partials while preserving the existing HTML/CSS/JS architecture
and visual output. Keep page-specific markup in content files.
Use @pathto for project-owned page and asset references.

The migration succeeds when the site becomes easier to maintain—not when it looks more like a framework.

Nift should remove duplication, improve path/dependency awareness and speed up the edit/build loop while leaving the architecture you deliberately chose intact.

RelatedProject-aware paths →