Yuvraj Raulji | WordPress migration
Most WordPress migrations are described as a host move and are actually a content move. The files and database copy across in an afternoon; the risk is in the URLs, the media library, the redirects that were already there, and whether the content arrives as content or as markup nobody can restructure afterwards.
Direct answer
A WordPress migration moves a site between hosts, onto a new domain, or onto WordPress from another CMS. Copying files and the database is the routine part, and it is not where sites get damaged. The risk sits in URL continuity, the redirects that already existed and are easy to lose, a media library whose paths are hardcoded in content, and, on a move from another CMS, whether content arrives as structured posts and fields or as one block of markup that can never be restructured again.
Best suited for
- Moving off hosting that has become the constraint
- A domain or brand change with an archive to protect
- Coming onto WordPress from another CMS
- Consolidating several sites into one install
What this page is not
This page covers the site: files, database, content, media, hosting and domains. If there is a WooCommerce store on it, products, orders and customers need their own plan, and doing both at once is how attribution gets lost when something goes wrong.
The problem
The symptom as the person carrying it would describe it, and the part that shows up in the numbers rather than in the ticket queue.
The existing redirects are lost in the move
What it costs
Years of accumulated redirects live in a plugin, a server config or an htaccess file nobody inventoried. Losing them breaks links that were already working, which is damage the migration created rather than inherited.
Media paths are hardcoded in content
What it costs
Absolute URLs to the old domain sit inside post content and serialised options. A naive find and replace corrupts the serialised data, and the images break in places nobody checks.
Content arrives as markup instead of content
What it costs
Migrating from another CMS into single blobs of HTML means nothing can be listed, filtered or restructured afterwards. The archive technically moved and stopped being an asset.
The move happens without a rehearsal
What it costs
The first time the process runs is on the live site, with DNS already changing. Anything that only fails on real data fails in front of the audience.
Approach
In this order, and the order is the opinion. Most of what goes wrong on this kind of engagement is a step taken before the one it depends on.
Inventory what exists, including the redirects
Content, media, users, plugins, cron jobs, and every redirect already in place across plugins, htaccess and server config. The redirect layer is the part most often discovered after it is gone.
Decide the content structure on arrival
On a move from another CMS, what becomes a post type, a taxonomy, a field or a block. Content that lands as one markup blob is content that cannot be restructured later, which quietly ends its usefulness.
Handle URLs and media properly
Serialisation-safe replacement rather than a plain find and replace, a full redirect map where paths change, and verification that media resolves from content as well as from the library.
Rehearse on real data
The whole migration, end to end, on a copy of the production database, with the result checked rather than glanced at. The live run should be a repeat.
Cut over with DNS planned
TTLs lowered ahead of time, a read-only or low-traffic window agreed, and a rollback written down. The technical move is minutes; the propagation is the part people forget to plan.
Scope
Moves
Host to hostDomain changeAnother CMS to WordPressMultisite consolidation
Content
Post type and taxonomy mappingField and block structureAuthor and date integrityMedia library transfer
Continuity
Existing redirect inventoryRedirect mappingSerialisation-safe URL replacementSitemap and canonical checks
Cutover
Rehearsal on production dataDNS and TTL planningRollback pathPost-move verification
Proof
A content-led platform where the archive and its discoverability were the point of the build.
Web platform · Manufacturing
Engineering manufacturer platform
A modern engineering brand platform built for discovery and enquiry.
Web platformTechnical SEOContent
3x traffic growth and 45% better engagement
Outcome
The archive arrives usable, not just present
Content that lands as structured posts with fields and taxonomies stays listable, filterable and reusable. Content that lands as markup has technically migrated and has stopped being an asset.
Links that already worked keep working
Preserving the redirects that were already in place is the least glamorous part of a migration and the one whose absence is most visible afterwards, because it breaks things that were not broken before.
No traffic figure is published here. None of the six builds on the work record is published as a WordPress case, and the migrations behind this experience belong to the organisations that ran them.
Questions
- Will moving hosts affect our search rankings?
- It should not, if the URLs stay the same, the existing redirects come with you and the new host is not slower. Rankings move when redirects are lost, when media stops resolving, or when the move is combined with a redesign and nobody can tell afterwards which change caused what.
- What is the safest way to change domain?
- A complete one-hop redirect map from every old URL to its new equivalent, serialisation-safe replacement of internal links and media paths, canonicals updated, both properties verified in Search Console, and the old domain kept and redirecting rather than allowed to lapse.
- How long does a WordPress migration take?
- The copy is usually hours. The timeline is set by the inventory, the redirect work and, on a move from another CMS, deciding how content maps onto post types and fields. Content mapping is nearly always the longest part and the one that gets estimated as if it were the copy.
- Can we migrate without downtime?
- Close to it. The site can be prepared and verified on the new host before DNS changes, with TTLs lowered in advance so propagation is short. The usual practical constraint is avoiding content changes during the window rather than the site being unavailable.
- What about the store on the same site?
- It needs its own plan, because products, orders and customers keep changing while a site migration is prepared. Sequencing the two is safer than combining them, since a combined move makes it impossible to attribute a problem to either.
Next step
Describe what is actually in front of you and we will work out whether this is the right piece of work before anyone scopes it. That conversation is usually shorter than people expect, and it occasionally ends with me saying you do not need the project.