Every web developer has a migration horror story. The client wants to move from WordPress to something modern. The estimate says three weeks. Six weeks later, the team is still manually copying blog posts, fixing broken image paths, recreating layouts pixel by pixel, and discovering pages that the old CMS generated dynamically but nobody documented. The SEO rankings tank because redirects were missed. The launch gets pushed twice. The client is frustrated. The team is demoralized. And the worst part is that everyone knew this would happen, because it happens every time.

Website migrations are universally dreaded because they are a perfect storm of tedious, risky, and underestimated work. The content extraction is boring but must be perfect. The template recreation is creative but constrained. The SEO preservation is invisible until it breaks. The CMS integration is fiddly and specific to the target platform. And all of it has to be done under time pressure, because the client is paying for every day the old site runs in parallel with the new one.

At CONFLICT, we have done enough of these migrations over thirteen years to know the pattern intimately. We also know that most of the work is mechanical – it is the same steps, in the same order, with the same failure modes, every single time. The creative work – the design, the information architecture, the content strategy – is a small fraction of the total effort. The rest is extraction, transformation, and configuration. Work that machines should do.

So we built a machine to do it. Hugoifier is an open-source Python tool that transforms existing websites into production-ready Hugo static sites with integrated Decap CMS. It is not a prototype. It is not an 80% solution that needs manual cleanup. It generates a deployable Hugo site with a working CMS, OAuth authentication, and Cloudflare Pages Functions – ready for production.

Why Hugo

Hugo is the fastest static site generator available, and its adoption has grown steadily since its initial release. For client sites that do not need server-side rendering, real-time database queries, or session management – which describes the majority of marketing sites, blogs, documentation sites, and portfolio sites – a static site generator is the right architecture. Faster page loads, lower hosting costs, better security posture, simpler deployment.

Hugo specifically has advantages that matter for production sites: build speed measured in milliseconds per page, a mature templating language, excellent image processing, built-in support for taxonomies and content types, and a deployment model that works with every major hosting platform.

The challenge with Hugo is the same challenge with every static site generator: getting content into it. Hugo expects content in Markdown files with YAML frontmatter, organized in a specific directory structure, with templates that match the content types. Migrating an existing site to Hugo means converting every page to this format, recreating the templates, configuring the content types, and setting up a CMS so that non-technical users can edit the site without touching a code editor.

Hugoifier automates all of that.

Three Input Types, One Output

Hugoifier accepts three types of input, covering the most common migration scenarios:

Hugo Themes

The simplest case. You have a Hugo theme from a marketplace or a GitHub repository, and you want to turn it into a production site with a CMS. Hugoifier takes the theme, patches any deprecated Hugo API calls (Hugo’s template functions evolve across versions, and many community themes fall behind), integrates Decap CMS with full content type configuration, and generates a deployment-ready site.

This sounds trivial, but in practice, taking a Hugo theme from “works with hugo serve” to “production-ready with CMS and deployment pipeline” typically takes a day of work. Configuring Decap CMS alone – mapping content types, defining fields, setting up media folders, configuring the editorial workflow – takes hours. Hugoifier does it in minutes.

Next.js Applications

This is the migration path that would be absurd to do manually. A Next.js application is a React application with server-side rendering, API routes, dynamic imports, and client-side JavaScript. It does not have Markdown files or a clean content structure. The content is embedded in React components, fetched from APIs, and rendered dynamically.

Hugoifier handles this by starting the Next.js development server, capturing the server-rendered HTML output of every route, and extracting the content from the rendered pages. The extraction is structural – it analyzes the DOM, identifies the content regions, extracts the text and media, and converts everything to Hugo-compatible Markdown with frontmatter.

The key insight is that server-rendered HTML is the source of truth for what the site actually displays. By capturing the rendered output rather than trying to parse React components, Hugoifier avoids the impossible problem of understanding arbitrary JavaScript code. It does not matter how the content is fetched, transformed, or composed within the Next.js application. What matters is the HTML that the server produces.

Raw HTML Sites

For sites that are not built with a framework – static HTML, legacy CMS exports, sites built with page builders, or sites where the source code is not available – Hugoifier performs direct HTML extraction. It takes the HTML files (or crawls the live site), extracts the content structure, converts it to Markdown, and generates Hugo templates that reproduce the layout.

This is the most common migration scenario for older sites, and it is where Hugoifier’s direct extraction approach pays the biggest dividends. The alternative – manually copying text from a browser, reformatting it as Markdown, recreating the layout in Hugo templates, and cross-referencing every internal link – is exactly the soul-crushing work that makes migrations take three times longer than estimated.

AI as a Fallback, Not a Crutch

There is a temptation, when building a tool in 2026, to make everything AI-powered. Use an LLM to extract the content. Use an LLM to generate the templates. Use an LLM to write the CMS configuration. The demo is impressive. The reliability is terrible.

Hugoifier takes the opposite approach. The core engine is deterministic. Content extraction is done through direct HTML parsing – BeautifulSoup, CSS selectors, structural analysis. Template generation is done through pattern matching and template composition. CMS configuration is done through content type inference from the extracted structure.

This approach is not as flashy, but it is significantly more reliable. Direct HTML extraction has a property that LLM-based extraction does not: zero content loss. If a paragraph exists in the HTML, it will appear in the Markdown output. An LLM might summarize it, rephrase it, skip it, or hallucinate additional content. Direct extraction cannot do any of those things. The content is either extracted correctly or an error is thrown. There is no silent data corruption.

AI is used as a fallback mechanism for situations where deterministic extraction is insufficient:

• Content generation from prompts. When a site needs new content – placeholder pages, blog posts, landing page copy – Hugoifier can generate it from natural language prompts. This is new content, not extracted content, so the hallucination risk is appropriate: the content will be reviewed and edited regardless.
• SEO metadata enhancement. Generating meta descriptions, Open Graph tags, and structured data from existing page content. The source content is provided to the model, and the model generates optimized metadata. This is a summarization task where the model has the source material in context, which is the use case where LLMs are most reliable.
• Automatic image alt text generation. Accessibility compliance requires alt text on images. Many existing sites lack it entirely. Hugoifier uses vision models to generate descriptive alt text for images that do not have it. This is a genuine value-add that would be prohibitively expensive to do manually for sites with hundreds of images.
• Default layout templates. When the extracted site structure does not map cleanly to Hugo’s template hierarchy, AI can generate reasonable default templates. These templates are starting points that will be customized, not final output.

All four of these features were added in v0.3.0, released on March 18, 2026. They are explicitly positioned as post-conversion enhancements. The core extraction and conversion pipeline does not depend on AI, does not require API keys, and does not send any content to external services. AI features are opt-in and additive.

This reflects a broader philosophy that we apply to all of our tooling at CONFLICT: use AI where it adds value that cannot be achieved through deterministic means. Do not use it as a substitute for reliable engineering. A tool that works correctly 95% of the time and requires manual intervention 5% of the time is more expensive than a tool that works correctly 100% of the time – because the 5% failure rate means a human has to verify every output, which negates the automation benefit.

Decap CMS Integration

A Hugo site without a CMS is a developer tool. A Hugo site with a CMS is a product that non-technical users can operate. This distinction matters enormously for client work, because the people who need to edit the site – marketing teams, content writers, business owners – are not going to open a code editor and write Markdown.

Hugoifier generates a complete Decap CMS integration:

Content type mapping. Every content type in the Hugo site gets a corresponding collection in Decap CMS. Blog posts, pages, team members, case studies, products – whatever content types the site has, the CMS is configured to manage them. Fields are mapped from the Hugo frontmatter: strings, dates, images, lists, booleans, relations. The CMS editing interface reflects the content structure.

Media management. Images and other media are configured with upload paths, public paths, and preview settings. Authors can upload images through the CMS interface, and the images are committed to the repository in the correct directory.

Editorial workflow. Decap CMS supports a draft/review/publish workflow backed by Git branches and pull requests. Hugoifier configures this workflow so that content changes go through review before they are published.

Admin interface. The CMS is accessible at /admin/ on the deployed site. Authentication is handled through GitHub OAuth, with the OAuth flow implemented as Cloudflare Pages Functions. No separate backend server is required.

Whitelabel CMS

For agencies and studios that deliver sites to clients, branding matters. Hugoifier supports whitelabel CMS customization through CLI flags:

• --cms-name sets the CMS name displayed in the admin interface
• --cms-logo sets the logo image
• --cms-color sets the primary accent color

The client sees a CMS branded with their name or the agency’s name, not “Decap CMS.” This is a small detail that has an outsized impact on the client’s perception of the deliverable. It signals professionalism and attention to detail, which is exactly what you want when handing off a site.

The Deployment Story

A migration tool that produces a site you cannot deploy is not a migration tool. It is a demonstration. Hugoifier generates everything needed for deployment on Cloudflare Pages:

Cloudflare Pages Functions. The OAuth flow for Decap CMS requires a server-side component to handle the GitHub OAuth callback. Hugoifier generates this as Cloudflare Pages Functions – serverless functions that run at the edge, cost essentially nothing, and require no infrastructure management.

Build configuration. The generated site includes the Hugo build configuration needed for Cloudflare Pages: the build command, the publish directory, and the environment variables. Connect the repository to Cloudflare Pages, and the site deploys automatically on every push.

Environment variable documentation. The generated site includes a .env.example file documenting the environment variables needed for the OAuth flow: the GitHub OAuth app ID, the secret, and the allowed origins. These are not hardcoded – they are read from environment variables at runtime, following twelve-factor app principles.

The result is a site that can go from “repository connected to Cloudflare Pages” to “live in production with working CMS” in under five minutes. This is important because the deployment step is where many migration tools fall apart. They generate a site that works in local development but requires hours of configuration to deploy. Hugoifier treats deployment configuration as a first-class output.

The Testing Story

Hugoifier has 135 tests covering the extraction pipeline, the template generation, the CMS configuration, the CLI interface, and the AI-powered features. This is not a token test suite. It is comprehensive coverage that we rely on for confidence in the tool’s output.

The tests are structured around the three input types:

• Hugo theme tests verify that deprecated API calls are patched correctly, that CMS configuration is generated for all content types, and that the output builds without errors.
• Next.js conversion tests verify that server-rendered HTML is captured correctly, that content is extracted from the rendered output, and that internal links are remapped to Hugo’s URL structure.
• Raw HTML tests verify that content is extracted from arbitrary HTML structures, that templates reproduce the source layout, and that media assets are downloaded and referenced correctly.
• AI feature tests verify that content generation, SEO metadata enhancement, alt text generation, and layout template generation produce valid Hugo-compatible output.

We run these tests on every commit and every pull request. The test suite is also useful as documentation – reading the tests is the fastest way to understand what Hugoifier does and does not handle.

The Bigger Picture

Hugoifier exists because we kept solving the same problem manually. Every web project that involved migrating an existing site followed the same painful pattern: extract content, recreate templates, configure CMS, set up deployment, test everything, fix the things that broke. Each migration was slightly different in its specifics but identical in its structure.

This is the category of work that we think tooling should eliminate. Not creative work. Not strategic work. Mechanical work that follows a predictable pattern and has a well-defined correct output. The content on the old site should appear on the new site. The layout should be preserved. The CMS should work. The deployment should succeed. There is no ambiguity in these requirements. There is just a lot of tedious, error-prone manual labor standing between the requirements and the result.

Hugo as a platform continues to grow because the static site architecture makes sense for an increasing number of use cases. As more organizations move to Jamstack architectures for performance, security, and cost reasons, the migration pipeline from legacy platforms to Hugo becomes more important. And as the number of legacy sites needing migration grows, the manual approach scales worse and worse.

We open-sourced Hugoifier because the problem it solves is universal. Every agency, every freelancer, every development shop has done these migrations. Many of them are doing one right now. The tool is available on GitHub, it is free, and it works.

What Is Next

Hugoifier v0.3 is solid, but there are areas we are actively working on:

• WordPress XML import. WordPress is still the most common migration source, and while raw HTML extraction works, direct WordPress XML import would be faster and would preserve metadata (categories, tags, author information, publication dates) that is not always present in the rendered HTML.
• Additional deployment targets. Cloudflare Pages is our default, but Netlify, Vercel, and AWS Amplify are equally valid targets. Generating deployment configuration for these platforms is straightforward and on the roadmap.
• Theme marketplace integration. Automating the process of selecting and applying Hugo themes based on the source site’s design characteristics. This is an area where AI-powered visual analysis could genuinely add value.
• Multi-language site support. Hugo has strong multilingual support, but extracting and mapping multi-language content from source sites adds complexity that v0.3 does not handle.

If you are facing a website migration and want to try Hugoifier, the GitHub repository has installation instructions, usage documentation, and examples for all three input types. If you run into issues or want to contribute, open an issue or a pull request. We built this tool to solve a problem we have, and we suspect you have it too.