Copy, paste, fix, repeat
The new design is approved and built. Now the client's old site content needs to come across: a large blog, dozens of case studies, service pages and a resources library. The old site is on a different platform, with content in a page builder that wraps everything in its own code.
A junior developer starts copying posts into the new WordPress site. Formatting breaks. Images link back to the old server. Author names, dates and categories need re-entering. Weeks later, she is still going, the launch has slipped, and nobody has started the redirect map. After launch, a few older posts that brought in a lot of search traffic turn out to be missing.
Why migration gets underestimated
- Content volume is not checked properly before quoting.
- The old content is locked in page builder code or another platform's format.
- New templates use structured fields that the old content does not match.
- Images, internal links, dates, authors and SEO metadata all need to move too.
- Redirects are left until the end, when there is no time left.
Migration is treated as data entry, when it is a small technical project of its own.
What a manual migration costs
Project hours disappear into copying. Launch dates slip. Formatting errors and broken images make the new site look worse than the design. Missing redirects and lost metadata can hurt the client's search visibility, which may be what they valued most about the old site. The client blames the new site for the drop.
The migration we build
- The old site is crawled and, where possible, its database or export is read, to produce a full inventory: every page, post, product and file, with URL, title, date, author, categories and metadata.
- The inventory is shared with the client to mark each item keep, merge, rewrite or drop, so nothing is moved that should not be.
- Content is mapped to the new templates and fields. Page builder code is cleaned into plain content, and structured items such as case studies are split into their fields.
- A script imports content into the new site through the WordPress REST API or a similar route for other platforms, with images downloaded and re-hosted, internal links rewritten and metadata carried across.
- Old URLs are mapped to new ones, and the redirect list is generated from that mapping.
- A report lists everything that did not migrate cleanly, such as embedded forms, unusual layouts or broken source content, for a person to fix.
- The migration can be re-run close to launch to pick up content the client added on the old site in the meantime.
| Item | Manual approach | Scripted migration |
|---|---|---|
| Blog posts | Copied one by one | Imported with dates, authors, categories |
| Images | Re-uploaded, or left pointing to the old server | Downloaded and re-hosted |
| Internal links | Often broken | Rewritten to new URLs |
| SEO titles and descriptions | Frequently lost | Carried across |
| Redirects | Left to the end | Generated from the mapping |
| Late content on the old site | Missed | Picked up by a re-run |
The script handles the bulk. Some pages will always need a person, especially key landing pages the client wants reworked for the new design.
Content migration as a planned stage
In discovery, the old site is crawled and the content volume goes into the quote. The client marks the inventory. The migration script runs early in the build, so the developer builds templates against real content. A re-run before launch picks up recent posts. The redirect map is ready on launch day, and the go-live check confirms it works. The exceptions report lists a handful of pages for the team to finish by hand.
Is migration eating your projects?
- Old site content is copied into new builds by hand.
- Migration effort is guessed at quote stage.
- Images and internal links break during migration.
- Redirects are built at the last minute or not at all.
- Content has gone missing after a relaunch.