Web Development
Website Migration
The engineering side of a move. Protecting search rankings through it is site migration SEO, and the two are always bought together.
Website migration moves a site to a new platform, host or domain with the data intact and the downtime planned. The Nexclick maps and tests the redirects before launch, migrates content rather than retyping it, and monitors daily afterwards because migrations always surface something.
Is this you?
What usually prompts the call
- You are moving off a platform that no longer fits and are worried about what breaks.
- Your host has been acquired, put prices up, or become unreliable.
- You are consolidating several sites into one and nobody has planned the URLs.
- A previous migration lost data or downtime and you want this one handled differently.
What we do
The actual deliverables
Things that appear on an invoice, not adjectives.
- Full inventory before anything moves
- Content, media, users, orders, forms, integrations and DNS records. Migrations fail on the thing nobody listed, not on the thing everyone discussed.
- Structural content migration
- Content mapped field to field and moved programmatically rather than copied and pasted. Manual migration loses formatting, metadata and relationships.
- Redirect mapping and staging tests
- Every URL mapped to a successor and tested before launch. Blanket redirects to the homepage discard the equity the move is meant to preserve.
- Integration reconnection
- Payment gateways, CRM, analytics, email and any API integration reconnected and tested with real transactions rather than assumed to carry over.
- DNS and downtime planning
- TTL lowered in advance, cutover timed deliberately, and a rollback plan agreed in writing before the day.
- Parallel running where possible
- The new site verified while the old one is still live, so cutover is a switch rather than a leap.
- Post-migration monitoring
- Errors, forms, transactions and crawl status watched daily for a fortnight. Something always surfaces; the difference is whether anyone is watching.
Checklist
The migration inventory — what to list before you move anything
Migrations fail on the item nobody listed. Work through this before agreeing a date. Every entry has, at some point, been the thing that was forgotten.
- 01Every page and post, with a count to verify against afterwards.
- 02All media files, including ones referenced only inside content.
- 03User accounts, roles and permissions.
- 04Orders, customers and transaction history, if ecommerce.
- 05Form submissions and where notifications currently go.
- 06Every integration: CRM, email platform, payment gateway, analytics, chat.
- 07API keys and webhooks pointing at the current site.
- 08DNS records — A, CNAME, MX, TXT, SPF, DKIM, DMARC.
- 09Email, if it is hosted anywhere connected to the same domain.
- 10SSL certificates and how they renew.
- 11Redirects that already exist from previous moves.
- 12robots.txt and any crawl directives.
- 13Scheduled tasks and cron jobs.
- 14Anything hardcoded to the current domain inside content or configuration.
- 15Third-party services with the current domain whitelisted.
- 16Search Console and analytics properties, and who has access.
- 17Backups of everything, verified as restorable before the move.
- 18A rollback plan, written down and agreed.
How it works
Step by step, with timeframes
Timeframes are typical rather than guaranteed, and they assume we get account access and approvals when we ask.
- 01Week 1–2
Inventory and plan
Everything catalogued, including the integrations nobody remembers. Cutover date and rollback plan agreed at this stage, not on the day.
- 02Week 2–5
Build and migrate content
Target environment prepared and content migrated programmatically, with a verification pass comparing counts and samples.
- 03Week 5–6
Test in parallel
Redirects, integrations and transactions tested against the new environment while the old site is still serving traffic.
- 04Week 6–8
Cut over and monitor
DNS switched mid-week with both teams available, then daily monitoring for a fortnight.
What you get
Reporting and ownership
- A full inventory including the integrations and DNS records nobody remembers until they break.
- The redirect map, tested on staging and version-controlled.
- A written cutover run sheet and rollback plan, agreed before the day.
- Verification that content counts and samples match between old and new.
- Daily monitoring for a fortnight after cutover, with anything found fixed within the engagement.
Tools and platforms
- Screaming Frog (crawl comparison)
- WP-CLI / platform migration APIs
- DNS management with lowered TTL
- Staging with production-like data
- Uptime and error monitoring
- Google Search Console
Timeline
How long this actually takes
Six to eight weeks for a marketing site, longer for ecommerce where orders, customers and payment integrations all have to move intact. The inventory stage is the one that determines whether it goes smoothly, and it is the one clients most want to compress. Two honest points. Migrate mid-week with both teams available for 48 hours afterwards — never on a Friday. And expect a temporary search dip of ten to twenty per cent even when everything is done correctly; the redirect map decides whether that is temporary or permanent.
Pricing model
Fixed-price project
Fixed price after an inventory and scoping stage, since the source and target platforms determine the effort. Emergency recovery on a migration that already went wrong is quoted separately after a diagnostic.
Questions
Website Migration questions
How much downtime should we expect?
Minutes rather than hours if it is planned properly — TTL lowered in advance, the new environment verified in parallel, and DNS switched deliberately. Hours or days happen when the target is built after the decision to move rather than before.
Will we lose our email when we move the site?
Only if the MX records are handled carelessly, and it is one of the most common migration incidents. Email frequently lives on the same domain and different infrastructure. It goes in the DNS inventory explicitly, because losing email is worse than losing the website.
Can content be migrated automatically?
Usually, programmatically and field by field. Manual copying loses formatting, metadata and relationships, and is slow enough to invite mistakes at scale. Where the source platform has no export path, we build one rather than accepting retyping.
What about our orders and customer data?
It migrates, and it needs verification rather than assumption — counts compared, samples checked, and a period where both systems are reconcilable. Payment gateways generally need reconnecting and testing with a live transaction, which is a step that gets skipped surprisingly often.
Should we redesign at the same time?
It is tempting and it adds risk. Migrating and redesigning simultaneously means that when something goes wrong you cannot tell which change caused it. Where budget allows, migrate first and redesign after. Where it does not, we sequence carefully and monitor more closely.
When is the best time to cut over?
Tuesday or Wednesday morning, with both teams available for the following 48 hours. Never a Friday. Most migration problems surface within hours and are cheap to fix immediately — the same problem found on Monday has had three days to be crawled, indexed and noticed by customers.
Last reviewed 28 July 2026.
Tell us what you are trying to fix
A 20-minute call, no pitch deck. The Nexclick will tell you what we would do, roughly what it costs, and whether we are the right people for it.