Every migration is specific, but there are only about a dozen genuinely different starting points. This library describes each of them: what the source technology gives you, what it withholds, and where the effort concentrates. Each entry links to detailed technical documentation and, where we have written one, to our own editorial treatment of the topic.
Group them by what the destination actually receives. A static export hands you finished markup: the migration is structural, deciding which parts are content and which are chrome. A framework repository hands you a program: the migration is interpretive, recovering intent from components. A hosted platform hands you a rendered result plus a partial data export: the migration is reconstructive, rebuilding editorial features that were part of the platform.
Effort scales with that difference far more than with page count. A two-hundred-page static archive can be faster to move than a fifteen-page application with a bespoke data model. Read the manual versus automated conversion comparison before deciding on tooling, and our AI to WordPress guide for what must be preserved regardless of path.
Component trees do not map one-to-one onto templates. This path covers identifying repeatable components as content types, converting props into fields, replacing client-side routing with permalinks, and deciding whether to keep React as a front end via the REST API or to render fully in PHP.
Technical guideReact conversion referenceour React migration article
Adds rendering-mode complexity on top of React: statically generated pages, server-rendered routes and incrementally revalidated content each behave differently after a move. Covers dynamic route mapping, image component replacement and preserving the existing URL scheme exactly.
Technical guideNext.js conversion referenceour Next.js rendering article
Canvas-positioned layouts and scroll-driven animation are the two hard parts. This path explains how to re-express absolute positioning as flexible CSS, rebuild motion with a maintainable library, and map Framer CMS collections onto post types without losing field relationships.
Technical guideFramer export guideour design-tool export analysis
Lovable produces a genuine React repository, so migration begins with reading the code rather than scraping the page. Covers extracting the design system into theme styles, converting page components into templates, and handling any Supabase-backed data behind the interface.
Technical guideLovable migration case studyour code-portability article
The most predictable of the visual-platform migrations. Static export gives clean class-based markup that maps well onto a theme, and CSV collection exports map onto post types. Budget separately for forms, site search and any collection filtering that relied on Webflow hosting.
Projects written with Cursor are ordinary codebases, so the migration profile depends on the framework rather than the editor. The recurring issue is inconsistency introduced by rapid iteration; normalising patterns before extraction saves more time than it costs.
Claude-generated pages are typically compact and semantically clean, which makes them pleasant to convert. The work is mostly consolidation: turning repeated inline markup into template partials and moving inline styles into the theme stylesheet.
Prototypes generated around Gemini often mix interface code with model calls. This path separates the two: rebuild the interface as templates, then decide which model-powered features go to production and where their credentials will be stored server-side.
Because Bolt.new produces a running project with real build tooling, step one is reproducing the build locally. Once it compiles, the conversion follows the ordinary React route: templates from components, permalinks from routes, theme styles from the compiled stylesheet.
Replit projects frequently include server-side behaviour, storage and secrets. Split the presentational site from the application: the site converts normally, while the application layer becomes a plugin, a REST endpoint or an external service the site consumes.
The most transparent path, and the best one to learn on. Existing markup becomes the theme almost directly; the real work is deciding what becomes a page, what becomes a post type, and how to preserve a decade of file-based URLs with an exact redirect map.
Technical guidestatic site conversion toolingour static HTML article
Beyond the eleven paths, a handful of references come up in nearly every project. For search continuity, the post-migration SEO checklist and the ranking preservation guide. For visual fidelity, the broken layout troubleshooting guide and the responsive design documentation. For speed, the optimisation guide together with image handling.
On the WordPress side, four references cover most of what a newly migrated site needs: how themes work, child theme practice, essential plugins and security hardening. Sites with editorial teams should add staging environments and backup procedures before launch, not after.
If you have not yet chosen a builder, the 2026 platform comparison, the general builder comparison and the cost analysis are the three most useful documents. Our own AI website builders review summarises the same territory with the migration question in front rather than behind.
Our long-form pieces sit in the articles index, including SEO preservation, Core Web Vitals, WordPress as a long-term platform and open standards for public websites. The policy framing is in European digital transformation, and thirty practical questions are answered in the FAQ.
Find the row matching your source technology, read the short description to understand the shape of the work, then follow the linked technical guide for the step-by-step procedure. Our own articles give the editorial context around each path.
Static HTML to WordPress is the most predictable, because the markup you see is the markup you migrate. Framework applications are harder because the visible page is the output of a build step.
For a small static or Webflow-exported site, a confident WordPress administrator can usually manage. For React, Next.js or application-style projects, developer involvement pays for itself in the template and data-model design.