Moving your website to a new platform feels like it should be a design job. In practice, most of the risk sits in the parts nobody sees: the old addresses Google knows, the forms that send you enquiries, and the tracking that tells you where those enquiries came from.
When a migration goes wrong, it’s rarely dramatic on launch day. The site looks great, and then a few weeks later you notice fewer calls, a gap in your analytics, or a contact form that has been quietly sending messages to someone who left the business last year.
This checklist is organised into what you do before launch, on the day, and in the weeks after. It works whether you’re leaving Webflow, Framer, HubSpot CMS, Wix, Squarespace or WordPress, and there are a few platform-specific notes further down.
Before launch: take stock of everything you have
1. Crawl and list every URL on your current site
You need a complete list of every address on the old site, including the ones that aren’t in your menu. Old blog posts, campaign landing pages, PDFs, thank-you pages and tag or category pages all count.
Run a site crawler over the live site, then compare the result with your current sitemap and with the Pages report in Google Search Console. Each source catches things the others miss. Put the combined list in a spreadsheet, because it becomes the backbone of everything that follows.
2. Find out which pages actually matter
In Search Console, open the Performance report and sort your pages by clicks and impressions over the last 12 months. In your analytics, look at which pages people land on and which ones lead to enquiries. Note any pages that other websites link to as well.
You’ll often find that one or two older articles bring in more visitors than your homepage. Mark those pages clearly, because they need the most care.
3. Build a redirect map, one old URL to one new URL
Add a second column to your spreadsheet with the new address for every old one. The safest URL is the one that doesn’t change, so keep addresses the same wherever you can.
Where an address has to change, point it to its closest equivalent with a permanent (301) redirect. An old “/services/bookkeeping” page should go to the new bookkeeping page, not the homepage. Google tends to treat a pile of redirects to the homepage as missing pages, so the value those pages built up is lost. If a page is genuinely gone and has no close match, it’s fine to let it return “not found”, as long as that’s a decision you made on purpose.
Our guide to redesigning without losing your Google rankings goes deeper on redirect rules if you want the detail.
4. Record your page titles, descriptions and headings
For every page that gets search traffic, copy the current title tag, meta description and main heading into the spreadsheet. When the new pages are written, you can check that the words people search for are still there. You can improve the writing, but if a page ranks for “tax accountant Parramatta”, the new title should still say something very close to that.
Check for structured data too. If your old site describes your business, reviews, articles or FAQs in schema markup, that needs to come across. If it doesn’t have any, a migration is a good time to add it.
5. Export your content, including the images and alt text
Blog posts are usually the biggest job. Export them with their publish dates, authors, categories and featured images, and keep the original wording unless you’ve decided to rewrite something. A post that ranks today ranks because of what it says.
Images are where exports most often fall short. Many platforms host your images on their own servers, so an export can give you links to those images rather than the files themselves. Download every image while you still have access, and keep the alt text that goes with each one, because it matters for accessibility and for image search.
6. List every form and where its enquiries go
Write down every form on the site, what fields it has, who receives the submissions, and anything that happens afterwards: an autoresponder, a notification to a sales channel, a new contact in your CRM, or a booking link. A form that looks identical on the new site can still break the process behind it if it isn’t wired up the same way.
7. Audit your analytics and tracking
Make a list of every script on the current site: Google Analytics, Google Tag Manager, ad pixels, your CRM’s tracking code, chat widgets and anything else. Then list the conversion events you rely on, such as form submissions, phone clicks and bookings. In Google Analytics 4 these are called key events.
If you use Tag Manager, you can install the same container on the new site and keep its history, but triggers that rely on the old page structure or the old form’s thank-you page may need updating.
8. Check how Search Console is verified
If you verified Search Console with a tag in the old site’s code, that verification will disappear when the old site does. Verifying with a DNS record (a Domain property) avoids the problem and covers every version of your domain at once.
Platform notes for Webflow, Framer and HubSpot CMS
Leaving Webflow. You can export each CMS collection as a CSV from the CMS panel. Image fields in that CSV are links to files on Webflow’s servers, so download the images themselves before you close the account. Webflow also handles form submissions natively, which means every form needs a new home on the new site.
Leaving Framer. Framer forms send their submissions through Framer, so they need rebuilding on the new site, along with any integrations connected to them. Check the custom code section of your site settings as well, because analytics and tracking scripts are often added there and are easy to forget.
Leaving HubSpot CMS. This is the one where the details matter most, because many businesses keep HubSpot’s CRM after they leave its CMS. If you’re staying on the CRM, you can embed your existing HubSpot forms on the new site and install the HubSpot tracking code, so new contacts keep flowing in and their history isn’t broken. If you’re leaving HubSpot entirely, every form, workflow and email that a form submission triggers needs replacing. Either way, images inside your blog posts usually point to HubSpot’s file manager, so download them and re-link them before the subscription ends.
When we moved AccountKit off HubSpot’s CMS, which was costing them $12,000 a year, their sales team still ran on HubSpot’s CRM. So the demo form on the new site posts straight into their existing HubSpot form, the booking calendar is still their HubSpot meetings page, and the tracking kept its history.
Launch day: switch over carefully
9. Plan the DNS cutover
A day or two before launch, lower the TTL on the DNS records you’re about to change, so the switch takes effect quickly. When you update the records, change only what the website needs. Your email depends on your MX records, and if you move your domain’s nameservers to a new provider, those records have to be copied across exactly, or your email stops arriving.
Make sure the new site has a valid SSL certificate, and that every version of your domain (www and non-www, http and https) redirects to a single address.
10. Remove anything left over from the staging site
A “noindex” tag or a robots.txt file that blocks search engines is normal on a staging site and a disaster on a live one. So are canonical tags that still point to a staging address. Check all three on the live site within minutes of launch.
11. Test your redirects against the live site
Run your full list of old URLs against the new site and confirm that each one either loads with a 200 response or redirects once, with a 301, to the right page. Look out for redirect chains, where one redirect leads to another, and fix them so every old URL goes straight to its final page.
For AccountKit, that list was 74 old addresses. 62 answer at the same address, including all 45 blog posts moved across word for word, and 12 have a permanent redirect. We checked 92 URLs against the live deployment after the move.
12. Submit the new sitemap and request indexing
In Search Console, submit the new sitemap and use the URL Inspection tool to request indexing for your most important pages. If the domain itself is changing, use the Change of Address tool as well, and keep the old domain’s redirects in place for the long term.
13. Test every form and every conversion on a phone
Plenty of your visitors will arrive on a phone, so do your testing there. Fill in every form, check the submission arrives where it should, and confirm the conversion shows up in your analytics in real time. Tap the phone number, open the booking link and check the menu works with your thumb. It’s worth having someone who didn’t build the site do this too, because they’ll try things you won’t.
After launch: watch it settle
14. Monitor rankings and coverage for four to eight weeks
Some movement in rankings is normal while Google recrawls the site and processes your redirects. What you’re watching for is anything that doesn’t settle. Check these each week for the first four to eight weeks:
- The Pages report in Search Console, for new “not found” errors or pages that have dropped out of the index.
- Clicks and impressions by page, compared with the same period before the move.
- The search terms you care about, to make sure your key pages still appear for them.
- Enquiries and bookings, because traffic only matters if it turns into work.
If an important page drops and stays down, compare its redirect, title and content with what you recorded in your spreadsheet. The cause is usually there. Our guide to the first 90 days after launch covers what to keep an eye on after that.
15. Keep the old platform until you’re sure
Don’t cancel the old subscription the day you launch. Keep it until you’ve confirmed that every page, image and form submission has come across, and that you have an export of anything you might need later, such as old form entries. Once you’ve cancelled, getting that data back can be difficult or impossible.
Doing it yourself or handing it over
Everything on this list is doable in-house if you have the time and someone comfortable with DNS and Search Console. If you’d rather hand it over, a migration is part of our Studio and Full build packages: we map and test every redirect, move your content across, and set up your forms, analytics and tracking, with your new site live for review in seven days. If it isn’t live on the day we promise, you get your money back. You can see what’s included on our website migration page, or compare the packages on pricing.
Frequently asked questions
How long does a website migration take?
For a typical service-business site of up to 20 pages, the build and migration can be done in a week if the content and access are ready. The part that takes longer is the monitoring afterwards, which should run for four to eight weeks while Google processes the change.
Will I lose my Google rankings when I change platforms?
Not if the migration is done carefully. Rankings usually move a little while Google recrawls the site, then settle. They’re most at risk when URLs change without redirects, when content is cut, or when a staging setting blocks search engines on the live site.
Can I keep my domain name when I migrate?
Yes, and in most cases you should. Keeping the same domain means far less risk, because only the pages are changing. If you do change domains, map every redirect and use Search Console’s Change of Address tool.
What’s the difference between a website migration and a CMS migration?
A CMS migration is a type of website migration where the content management system changes, for example moving from HubSpot CMS or WordPress to a new platform. A website migration can also mean changing your domain, your hosting or your URL structure. Many projects involve more than one of these at once, which is why the checklist covers all of them.
How long should I keep my redirects?
Keep them permanently if you can. Links on other websites, in old emails and in people’s bookmarks keep being used for years, and each redirect keeps those visitors and that search value pointed at the right page.
