Belzona Baton Rouge is the authorized Belzona distributor for Louisiana. Their old site lived entirely inside Webflow: the pages, the product catalog, the case studies, and every image on the domain. The brief for the rebuild was easy to say and hard to do: get everything out, keep every page, keep the rankings, and end up owning the whole thing.
Looking back at the finished build, the numbers tell the story on their own: 893 CMS records migrated, 1,507 assets re-hosted, 460 pages generated, and zero reference orphans. Here is how each of those numbers happened.
A migration is a data problem, not a copy-paste job
Webflow's CMS is a set of collections: products, FAQs, case studies, industries, certifications, and so on. The export gives you raw records plus a field schema for each collection. We wrote a transform that reads both and normalizes every field by its declared type: references resolve to slugs, images become url-and-alt pairs, switches become booleans, numbers get coerced. Typed JSON comes out the other side.
The count mattered: 893 records across ten collections, including 112 products, 231 product FAQs, 65 case studies, and hundreds of benefit and taxonomy entries. When one record points at another, the link either resolves or it is an orphan. The migration landed at zero reference orphans. Every product still knew its series, and every FAQ still knew its product.
The transform also writes a gap report: every empty field in every collection, listed in a file, surfaced instead of guessed at. If the source data had no cure time for a product, the new page does not invent one. That is a studio law, and here it is enforced by the pipeline rather than by memory.
1,507 assets, and a build that refuses to lie
Every image and file on the old site was hosted on Webflow's CDN, which stops serving you when the subscription does. A localization script walks every URL in the raw export, including bare URLs buried inside rich text, downloads all 1,507 assets, and uploads them to first-party storage with stable, deterministic paths. The script is idempotent and resumable, because a 1,507-file transfer will get interrupted at least once.
Then we made it impossible to ship a mistake. The transform exits with an error if even one old CDN URL survives anywhere in the migrated data. And because the old host was removed from the image allowlist entirely, an unmapped image would visibly fail in production instead of quietly hotlinking. The build cannot ship a dependency on the old CDN, by construction.
This guard is the part we would push hardest on anyone doing a migration. Leftover hotlinks are invisible on launch day and fatal eighteen months later, when the old account finally closes.
Accessibility fixed at the data layer
CMS rich text arrives with whatever heading levels an editor happened to pick, which means rendered pages can skip levels and fail accessibility checks. Our transform flattens rich-text headings during migration so no page can skip a heading level. Fixing the data once beats patching the UI forever, and it means every future page inherits the fix for free.
How 112 products became 460 pages
The old CMS held 69 application scenario records. We expanded them into 205 canonical application pages, clustered under equipment areas, each with reverse lookups to the real products that solve them. That derived taxonomy is how a 112-product catalog becomes a problem-to-solution site: a visitor with a failing pump lands on a page about failing pumps, not on a spec sheet.
The final build generates 460 static pages: products, applications, application areas, industries, purposes, case studies, repair kits, and the hub pages that tie them together. Every one is prerendered from the typed data, with nothing left in Webflow.
Keeping the rankings
Rankings do not survive a re-platform by accident. The old site's legacy URLs, including an ASPX-era path from an even older generation of the site, redirect permanently to their new homes. We chose a true 301 over the framework's default 308 and left a comment in the config explaining why. The sitemap emits all 459 public URLs so crawlers can re-map the site quickly.
None of that guarantees a ranking by itself. What it guarantees is that nothing we control leaks equity: no lost pages, no broken internal links, no orphaned images, no dead legacy URLs. The client escaped a rented platform without losing a page, an image, or a ranking.
What we would tell you before your own migration
- Treat the export as data with a schema, not as content to paste. A transform can be tested and re-run; manual copying cannot.
- Count everything twice: records in, records out, references resolved. Zero orphans is a number you can prove.
- Re-host every asset before launch, then make the build fail if a single old URL survives.
- Surface missing data in a report instead of papering over it with invented copy.
- Redirect legacy URLs permanently, keep slugs stable, and ship the sitemap on day one.
A migration like this is unglamorous work, which is exactly why it is worth writing down. The glamour is in the result: a 460-page site the client owns outright, faster than the platform it left, with its history intact.
