Website Migration

The agreed scope can include naming the type of move, matching your old and new sites and Google accounts, finding web addresses from many sources, deciding where each old address goes and setting up redirects, keeping content and Google signals the same, moving files, forms and connected tools, checking tracking and cookie consent, moving customer accounts or store data when needed, a rehearsal, go-live, a switch-back plan, training your editors on the new platform, monitoring and handing over the old site's wind-down.

We lower the avoidable risk by finding every old address, choosing a relevant one-to-one new home for each, using direct permanent redirects, checking that Google signals match, telling Google and Bing about the move and watching closely for a long time afterwards. Even so, big moves can cause a temporary drop or swing in rankings and traffic while search engines re-read and re-judge each page. So we don't promise zero loss or a fixed date for recovery.

We can handle a switch from http to secure https, a new domain, a new subdomain, new page paths, a new platform, merging sites, splitting a site and changes to how country or language versions are organized. We name each change first, because redirects, Google tools, data and switch-back needs differ for each. Moving servers while keeping the same web addresses is covered by our Hosting Migration service, and deep reshaping of your content records is covered by CMS Migration.

We combine a scan of the live site with exports from your website editor or database, current and old sitemaps, analytics, Google Search Console, Bing Webmaster Tools data, server records, links from other sites, campaigns, archives and file stores, wherever we have access. No method can find an address that appears in none of those sources, so we always show where each address came from and where gaps remain.

No. Each old address should keep its purpose by pointing to the closest relevant new page, where one exists. We mark each address as kept, moved, merged, pointed to a main version, removed on purpose with the right response, left out or still undecided. Sending lots of unrelated pages to the homepage annoys visitors, and Google may treat those redirects as "soft 404s" (pages it considers missing).

We run every known old address, plus important versions with http or https, www or non-www, different paths and extra codes, against the planned map. We check the response code, each hop, the final page, chains, loops, errors, unexpected catch-all matches, lost codes and empty "soft 404" pages, then send any doubtful matches to you for review.

We compare the protected content as it actually displays, plus titles, headings, links, canonical tags (which page is the main version), robots rules, sitemaps, language tags, structured data (hidden labels that describe the page) and business details. Any change made on purpose is recorded. Matching everything still doesn't guarantee the same rankings or special search features like star ratings, and rewriting content at the same time can make it harder to tell what the move itself caused.

We list the media and document addresses we can find, move the approved files, update links to them inside pages and in automatically created pages, keep needed details such as alt text for accessibility, and redirect valuable file addresses that move where it makes sense. We also check scripts, styles, fonts, CDN sources and protected files that a normal list of pages can miss.

That depends on the old platform, the new platform and how logins are set up. We define user identities, whether passwords can be carried over, logged-in sessions, MFA (two-step login), SSO (single sign-on), roles, what each user can access, password reset steps and support. Customers may need to log in again or reset their password for security reasons, and deep login engineering is quoted separately.

When online store data is part of the move, we decide which system holds the official version and how products, customers, orders, subscriptions, stock, payments, carts, discounts, product feeds and automatic updates (webhooks) move, then match both the first copy and any late changes. Not every old record, password, subscription or payment detail can be carried between platforms, so what is and isn't moved is spelled out clearly.

We keep or version your event definitions, check tracking codes and where data is sent, test cookie consent choices, referrals, campaign codes and tracking across domains, and confirm the data each event sends on the new site. Redirects can strip campaign codes, and analytics is always affected by consent choices, ad blockers and processing delays, so we don't treat platform reports as proof of what caused a change.

We only use it when the move qualifies, and only after redirects and the required Search Console setup are in place. Google says not to use it for a switch from http to https, a switch between www and non-www on the same domain, moving pages within the same site or moving servers without changing web addresses. It also can't move just one folder of a site. We confirm both the old and new sites in Search Console and use Bing's Site Move tool where it applies.

We lock the test site behind a login and add the right instructions for search engines, plus safeguards so test emails, automatic updates and data don't reach real customers. Every temporary "don't list this page" or "don't crawl" setting is on the go-live checklist, so your real pages aren't blocked by mistake. A robots.txt file on its own does not keep confidential test content private.

A new platform or setup can remove some limits, but a move on its own doesn't guarantee better LCP, INP or CLS scores (Google's measures of loading speed, responsiveness and page stability). We compare test results with real visitor data where it's available, test key page designs and how much traffic the site can safely handle, and take code, content, devices, networks, traffic and outside tools into account when we explain the results.

We list every way new data enters the site and choose a pause on edits, a read-only period, a catch-up in stages or a supported sync. Late edits, files, accounts or orders are matched using fixed IDs and clear rules for exceptions. Moving live data with truly zero downtime can need app or database engineering that goes beyond normal website work.

The step-by-step go-live plan sets out health checks, the limits for "go" or "stop", a named decision maker, the earlier version we can return to and the steps to switch back or fix the problem. Recovery may need time for DNS changes to spread across the internet, data to be matched up and suppliers to act, so we rehearse switching back but don't claim it is instant on every setup.

Google recommends keeping redirects for as long as possible, generally at least one year. Its Change of Address tool keeps forwarding signals for 180 days, and Google suggests paying for the old domain for at least a year so no one else can buy it. You may need to keep them longer if visitors, links from other sites or search engine robots still use the old addresses, so domain renewals, DNS, security certificates and redirects all need a named long-term owner.

The timeline on this page shows an example twelve-week first cycle, not a promised length. Timing and price depend on your current sites and accounts, how many web addresses and files you have, platform limits, your Google history, how much content changes, languages, customer accounts or store data, connected tools, the rehearsal, go-live support and monitoring. Your proposal states what you get, our assumptions, what is not included, the timeline and our fee.