Move a site off a legacy CMS to WordPress
Moving off a legacy CMS is not one project but two: getting the content out, and getting the site back in. The first is decided by what the old system will give you — a documented export, a database you can read, or nothing but rendered HTML — and that single fact sets most of the cost. The second is ordinary WordPress work: a content model, templates, and a redirect map that preserves every URL the old site earned. Legacy systems fail the first test more often than teams expect: abandoned platforms, in-house PHP from a developer who left, hosted builders with no export, and CMSes whose vendor is gone. In every one of those cases the content is still recoverable — through the database, or by crawling the live site and parsing the HTML — but the recovery method has to be chosen and tested before a migration date is promised to anyone.
How do you get content out of a CMS that has no export?
There are three extraction routes, in descending order of preference.
- Database read. If you can get a dump, the content is structured and the mapping is exact. This is the only route that reliably preserves relationships — author, category, publication date, custom fields, media attachments.
- API or feed. Some legacy systems expose RSS, a REST endpoint or an admin-only XML dump that nobody documented. Worth ten minutes of looking before assuming route 3.
- Crawl and parse. Take the live HTML and extract fields with selectors: title from
h1, body from the content container, date from the byline. It works, and it degrades: anything not rendered on the page — draft posts, unpublished fields, alt text on images that aren't displayed — is simply gone.
Route 3 is a legitimate migration path, not a hack. What it cannot do is recover data the site never printed, so the decision has to be made with that limit visible, not discovered halfway through.
Should the content be migrated as-is, or cut down first?
Cut first, then migrate. Old sites accumulate: duplicate service pages, news posts about events from eight years ago, tag archives with one item, near-identical location pages generated by a plugin that was uninstalled in 2019. Migrating all of it multiplies the work and imports a thin-content problem into the new site.
The cut is a decision on paper, using three signals per URL: does it have traffic, does it have inbound links, does it still say something true. Anything with none of the three goes. Anything dropped still needs a resolution — a 301 to the nearest surviving page or a deliberate 410 — because a dropped URL that returns 404 is exactly what a redirect map exists to prevent.
What is the content model, and why is it decided before the export?
WordPress stores content as posts, pages, custom post types, taxonomies and fields. A legacy CMS stores it as whatever it stored it as: nodes, entries, records, rows in a bespoke table. The mapping between the two is the content model, and it is a design decision, not a technical one.
Decide it first and the export script writes to a known target. Decide it after and the content arrives as a pile of post_content HTML with the structure flattened out — which is recoverable only by going back to the source, if the source still exists. The rule is simple: anything that will ever need to be filtered, sorted or listed separately must be a field or a taxonomy, not a paragraph.
How do you protect the search traffic the old site already has?
By treating the URL inventory as the deliverable it is.
- Build the inventory from the server, not from the sitemap. Access logs plus a full crawl. Old
sitemaps are usually wrong in both directions — missing live pages, listing dead ones.
- Resolve every URL to one of three outcomes: kept, 301'd, or 410'd. No fourth option.
- Ship the redirect map in the same release as the switch. The interval between the two is the
window in which crawlers record 404s, and it should be zero.
- Recrawl afterwards and diff against the inventory. The check either returns zero unmatched
URLs or it names them; there is no partial credit.
Titles, meta descriptions and canonical tags travel as data alongside the content. If the old CMS generated them from a template rule, port the rule — not just the output — or the next thousand pages published will have no titles at all.
What about the things that aren't content?
Every legacy site has a layer that no export touches: forms and where they deliver, search, member logins, payment, whatever the site talks to over an API, and analytics. These are rebuilt, and they are the most common source of a migration that looks finished and isn't.
Inventory them the same way as URLs. For each one: what it does, what it talks to, who needs it to keep working, and what replaces it. A form that still posts to a decommissioned endpoint looks perfectly healthy on the new site and quietly delivers nothing — which is why form destinations get tested with a real submission after the switch, not before.
When is a migration the wrong answer?
When the site is going to be replaced anyway. If the content is mostly obsolete, the structure no longer matches what the business sells, and the traffic is small, then a migration is an expensive way to carry a problem forward. A rebuild with a redirect map from the old URLs to new equivalents is cheaper and produces a better result.
The way to tell is the inventory again: if fewer than a small minority of URLs would survive the content cut, you are not migrating a site, you are keeping a redirect map. Say so early, because the two projects have different shapes and different prices.
What do you need before anyone can quote this?
Four artefacts, all producible before an agency is chosen:
- the platform name and version, and whether a database dump is obtainable,
- the URL inventory from logs or a crawl,
- the list of content types and their fields,
- the list of integrations and forms with their destinations.
With those four, scope and schedule follow. Without them, any quote is a guess, and the number will change once the extraction route is known.
Who does this: Toimi is a digital agency that moves sites off legacy and custom CMS platforms to WordPress. We work in Russian and English and have been in business since 2017. Send the four artefacts above and we will come back with scope, schedule and price.
Contact: info@toimi.pro