WordPress migration intelligence
Rebuild WordPress sites without losing what makes them work.
Chromatic Bloom inspects an existing WordPress site, separates its content, design, structure, SEO, and behavior into a reviewable model, then turns that intelligence into a scoped migration plan for Next.js.
Status: a project-specific local workflow, in active development.
Source · wordpress
halloway-finch.com · sample
Resolves into one reviewed model · 412 records
discovercrawlcaptureextractclassifyreviewassembleexport
The workflow
Eight stages. Each one produces evidence for the next.
Nothing is inferred from thin air: every stage reads the output of the one before it, and the human review stage sits between the machine's conclusions and any generated plan.
Stage 01 of 08
Discover
Find every reachable URL before touching anything — sitemaps, the REST API, robots rules, internal links, and anything a person adds by hand.
Depends onNothing. This is the entry point; its output is the crawl frontier.
Artifact
247 URLs · 183 in scope
- sitemap.xml → 214 urls
- wp-json/wp/v2 → 12 post types
- robots.txt → 3 disallow rules
- internal link graph → 29 additional urls
- manual seeds → 4
Sample migration
Static sample dataWhat the intelligence actually looks like.
Below is a fictional studio site — Halloway & Finch — carried through the workflow. Every number is fixed sample data, not a live scan, and nothing here is a customer claim.
Why not just copy the pages
A page-by-page rebuild finds the problems last.
Scrapers reproduce markup. One-click converters reproduce appearance. Neither one tells you what a page is, how it relates to the other 182, or what breaks when it moves.
Typical migration
Copy pages one at a time
Chromatic Bloom
Build one complete site model, then work from it
Typical migration
Discover edge cases mid-build
Chromatic Bloom
Surface edge cases before implementation starts
Typical migration
Hope nothing was missed
Chromatic Bloom
Validate the rebuild against the original, page by page
Two migration modes
One model. Two legitimate outcomes.
The decision belongs to the client, not the tool. The same reviewed intelligence supports either direction — what changes is which parts are treated as fixed.
Reviewed site intelligence model
412 records · 11 sections · human-reviewed
Mode A
Faithful reconstruction
Rebuild the site as closely as practical on a modern stack. Layout, hierarchy, and DOM order are treated as requirements.
structure preserved · tokens preserved · order preserved
- Visual and structural parity is the acceptance test
- Builder-only wrappers are dropped, output is not
- Best when the current design still works commercially
Mode B
Content-preserving redesign
Keep the brand, meaningful content, functionality, and SEO value. Replace layouts and builder-generated complexity.
content preserved · SEO preserved · layout rebuilt
- Content parity and redirect integrity are the acceptance tests
- Page families become intentional templates, not accidents
- Best when the site works but the layouts have aged
Site Intelligence Model
The model is the deliverable. Prompts come after.
HTML dumps and screenshots are inputs. The model is the reviewed, structured statement of what the site is — and once accepted, it is the source of truth every implementation prompt is written against.
Every record carries
- source — the page and selector it came from
- extraction method — dom, visual, or heuristic
- confidence — machine estimate before review
- relationships — what it belongs to and uses
- review status — pending, accepted, edited, rejected
If a conclusion cannot be traced back to something on the original site, it does not belong in the model.
Human review
Machine conclusions stay inspectable.
Classification is a proposal. A person accepts, edits, or rejects each region — and the decision, not the estimate, is what reaches the model. Try it below; the state is local to this page.
Where the project stands
A working local workflow, not a hosted product.
Chromatic Bloom runs today as a project-specific local workflow, developed against real WordPress-to-Next.js migrations. This page describes what exists, what is being built, and what is still a direction.
Working today
- The full discover → export run, driven locally per project
- Desktop and mobile capture with DOM and computed-style records
- Design token and type-scale extraction with source selectors
- Page-family and region classification with confidence values
- Human review before anything enters the model
- Scoped implementation prompt packages for Next.js
In development
- Wider coverage of page builders and their generated markup
- Behavior and integration extraction beyond common cases
- A validation harness that diffs the rebuild against the source
- Sturdier review tooling for large sites
Longer-term direction
- A self-service hosted version, if the workflow proves repeatable
- Multi-site and portfolio-scale migration planning
- Continuous validation during a phased cutover
- Targets beyond Next.js where the model already fits
Not built and not planned for now: accounts, billing, hosted scanning of arbitrary sites, or one-click conversion. The sample migration on this page is fixed data — it does not scan anything.