CMS migration without losing what the old site earned

To scope a CMS migration we need the address of the current website, the CMS it runs on and the reason you want to move. Tell us which content, customer records or integrations must carry over. We review the URLs and the migration requirements before agreeing the work. Scoping starts with an inventory: a full crawl of the current site that records every URL, its status code, its title and its traffic. That inventory is also the document that sizes the job, because migration work scales with the number of URLs and content types, which is why it comes before the quote. Read access to the existing site is enough to produce it. Before you commit we tell you whether the migration is the fix or whether the platform was never the problem. We also say which of three jobs you are asking for: a move to a new platform, a new front end with WordPress kept as the editor, or a move between hosts.

Yes, we can migrate a site to a new CMS without redesigning it. A like-for-like platform move is a legitimate project and often the right one, because it separates the platform risk from the design risk instead of taking both at once. The inventory, the URL map and the checks before launch all still apply. Every existing URL is inventoried and mapped to its new address, and the content is imported repeatedly so that the final import on launch day is a rehearsed step. Title tags, meta descriptions, canonical tags, Open Graph data and schema markup are carried across and checked, because a site can survive a platform change and still lose visibility when the new templates generate different titles. We also move sites between hosts without changing the platform at all, which is a smaller job and is sometimes all that is needed. We say which of those you are asking for before quoting.

Old blog posts come across in a CMS migration, with their dates, authors and URLs. If we are going to recommend removing any of them, you get the list and the reason, and it is your decision. We treat old posts as content that has to survive the move, along with media libraries and their alt text, categories and tags. Older posts can turn out to carry a large share of a site’s traffic, which is why the inventory records the traffic for every URL before anything is built. Each post’s URL is mapped one-to-one where a corresponding page exists on the new site. Where one does not, the redirect goes to the closest genuine equivalent and never to the homepage, because search engines treat a homepage redirect as a soft 404. The map is reviewed with you, since you know which pages matter in a way analytics does not always show.

Read access to your current site is enough for us to produce the inventory and the quote. Nothing is changed on the existing site until you have agreed to the work. The inventory is a full crawl of the site as it stands: every URL, its status code, its title and its traffic. It sizes the job, because migration work scales with the number of URLs and content types, so it comes before the quote. Once the work is agreed, the new site is built separately and the content is imported into it repeatedly, so the final import on launch day is a rehearsed step and not a first attempt. Redirects are tested against the crawl of the old site before launch, and again after. On launch day, tracking, goals and Google Search Console verification are in place, with an annotation on the date so that later data can be read against a known event.

A broken site can still be migrated. That situation is common, and it is often the reason for the call. A broken site can still be crawled and its content extracted, so the inventory of URLs, titles and traffic can be produced in the usual way. Read access is enough for that, and nothing is changed on the existing site until you have agreed to the work. Before you commit we tell you whether a migration is the fix, or whether the platform was never the problem. We also tell you what we cannot carry across, because some platforms hold content in a form that has no equivalent, and pretending otherwise makes launch day worse. Anything deliberately left behind goes on a written list before launch. If the site needs repair more than it needs a new platform, see also rescue and performance work. Sometimes a move between hosts is all that is needed.