Halcyon Sound
An ageing Drupal install with a decade of articles and a URL structure nobody wanted to keep. Every old address was mapped before the new build started.
Drupal 7 → WordPress · 2025Service · Direct
CMS migration without losing what the old site earned
A migration is not a rebuild with a content import bolted on. The content is the easy half. The half that goes wrong is the URLs.
01Triggers
What usually prompts a migration
- The CMS is no longer supported, or the version you are on has stopped receiving security updates.
- Nobody at your company can edit the site without asking a developer.
- The site is slow and the platform is the reason.
- The agency that built it is gone and nobody can deploy it.
- You are consolidating several sites onto one platform.
- A licence renewal has arrived and it no longer looks like value.
Any of these is a legitimate reason. None of them is a reason to change the URLs.
02Continuity
What actually has to survive the move
Content
Everything, including the parts that are not obvious: media libraries with their alt text, authors and dates, categories and tags, form submissions if they are the record of something, and the twelve-year-old blog posts that turn out to be a third of the site’s traffic.
URLs and redirects
Every existing URL is inventoried before anything is built, and mapped one-to-one where a corresponding page exists. Where it does not, the redirect goes to the closest genuine equivalent rather than to the homepage — a homepage redirect is treated by search engines as a soft 404 and it is the most common way a migration loses rankings.
The map is written, reviewed and tested against a crawl of the old site before launch, and again after.
Metadata and structured data
Title tags, meta descriptions, canonical tags, Open Graph data and schema markup are carried across and checked. A site can survive a platform change and still lose visibility because the new templates generate different titles.
Analytics continuity
Tracking, goals and search console verification in place on launch day, and an annotation on the date so that the next six months of data can be read against a known event.
03Platforms
Where we migrate from and to
Most of our migration work is onto WordPress — from Joomla, Drupal, Squarespace, Wix, a static site, or a custom system nobody maintains any more — and off legacy WordPress onto a modern front end with WordPress kept as the editor behind it.
We also move sites between hosts without changing the platform, which is a smaller job and is sometimes all that is actually needed.
We will say which of those three you are asking for before quoting, because clients frequently ask for the largest one and need the smallest.
04Engagement
How a migration runs
- 01
Inventory. A full crawl of the current site: every URL, its status code, its title, and its traffic. This is also the document that tells us how big the job is.
- 02
Map. Old URL to new URL, page type to page type, field to field. Reviewed with you, because you know which pages matter in a way analytics does not always show.
- 03
Build and import. The new site is built and the content is imported into it — repeatedly, so the final import on launch day is a rehearsed step rather than a first attempt.
- 04
Verify before launch. Redirects tested against the crawl. Metadata compared old to new. A written list of anything deliberately not carried across.
- 05
Launch and watch. Sitemaps submitted, search console monitored for crawl errors, and the redirect map corrected where reality disagrees with the plan.
05Straight answers
What we will tell you before you commit
- Whether the migration is the fix, or whether the platform was never the problem.
- Which pages will lose visibility no matter what, and why. There are usually a few.
- What we cannot carry across. Some platforms hold content in a form that has no equivalent, and pretending otherwise makes launch day worse.
- That rankings normally move for a period after any migration, and recover. Anyone who tells you a migration is invisible to search has not run many.
06Proof
Migrations we have run
Placeholder — invented projects, pending real client work
Northbank Studio
A move off a hosted page builder onto a front end they own, with the editing surface kept familiar so the team did not have to relearn it.
Hosted builder → Nuxt · 202607FAQ
Questions we get asked
Will we lose our rankings?
Traffic normally dips for a period after any migration and recovers. Done properly — every URL mapped, metadata carried across — the dip is small and short. Done by importing the content and letting the new platform generate new URLs, it is neither.
How long does it take?
The build takes as long as the build. The migration work on top of it scales with the number of URLs and the number of content types, both of which come out of the inventory in step one. That is why we do the inventory before quoting.
Can you migrate the site without redesigning it?
Yes. A like-for-like platform move is a legitimate project and often the right one — it separates the platform risk from the design risk instead of taking both at once.
What about our old blog posts?
They come across, 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.
Do you need access to our current site?
Read access is enough to produce the inventory and the quote. Nothing is changed on the existing site until you have agreed to the work.
What if the current site is broken?
That is common — it is often the reason for the call. A broken site can still be crawled and its content extracted. See also rescue and performance work.
08Next step
Start a project
Send us the current site’s address. The inventory comes first, before anything is quoted.
Or email us at hello@felixwebsolutions.com.
Agency looking for a build partner? We work white-label →