Website Migration Checklist for Small Businesses: Domains, Redirects, Email, and Launch Timing

Moving a small-business website sounds simple until the launch week arrives.

The new design may be ready. The copy may look better. The template may be cleaner. But the real migration risk usually sits in the practical details: domain access, DNS records, email settings, old URLs, redirects, contact forms, tracking, and launch timing.

For a small business, a website migration should not be treated as a last-minute switch. It is a controlled handoff from the old site to the new one.

Use this website migration checklist before you move from an old provider, DIY builder, outdated WordPress site, agency build, or slow self-managed setup into a new managed website. The goal is not to promise that traffic will never fluctuate. Google specifically notes that rankings can move temporarily during a significant site change while pages are recrawled and reindexed. The goal is to reduce avoidable problems.

Quick Website Migration Checklist

Before launch:

• Confirm who owns the domain and who can change DNS.
• Export or copy the old site's important pages, images, PDFs, menus, service details, and contact information.
• Create a map from old URLs to new URLs.
• Keep important pages as close as practical to their old purpose.
• Prepare permanent redirects for moved pages.
• Check email records before changing DNS.
• Rebuild contact forms, booking links, payment links, and tracking.
• Verify the new site in Search Console and analytics tools.
• Pick a launch window when fewer customers are likely to be affected.
• Test the live site after DNS and redirects are switched.

The small-business version is simple: do not launch only by asking, "Does the homepage look good?" Ask, "Will customers, Google, email, forms, and old links still know where to go?"

Step 1: Confirm Domain Ownership and Access

The domain is the business address. Before a migration starts, confirm:

• Which company is the domain registrar.
• Whose name or business is listed as the registrant.
• Which email address controls registrar access.
• Whether the domain is locked, expired, or near renewal.
• Who can edit DNS records.
• Whether the current web provider also controls the domain.

This matters because a website launch can stall if the owner cannot access the domain account. It can also become risky if the domain was registered by a former vendor, employee, or agency under their own login.

You do not always need to transfer the domain to a new registrar. Often, the cleaner move is to keep the domain where it is and update DNS records so the domain points to the new website. ICANN notes that some domain transfers can be blocked by transfer locks, including certain 60-day lock situations after transfers or registrant changes. For many small businesses, changing hosting or DNS is faster than moving the domain registration itself.

The practical checklist:

• Make sure the business controls the domain account.
• Do not change registrant contact details right before launch unless necessary.
• Check renewal dates before the migration.
• Save registrar login details in a secure business-controlled place.
• Decide whether the migration needs a DNS change, a registrar transfer, or both.

Step 2: Inventory the Old Website

Before building the new version, list what exists today.

Start with the pages customers and search engines already know:

• Homepage.
• Contact page.
• Main service pages.
• Location pages.
• Menu, pricing, treatment, portfolio, or product pages.
• Blog posts or guides that still attract visitors.
• PDFs, image galleries, forms, and downloadable files.
• Pages that other websites link to.

Use analytics, Search Console, the old sitemap, the CMS page list, and manual browsing. A small business may only have 10 to 30 important URLs, but those URLs still matter. A contractor's "kitchen remodeling" page, a clinic's location page, a restaurant's menu, or a law firm's consultation page should not disappear without a plan.

This is also the moment to decide what should not move. Old promotions, outdated staff pages, duplicate service pages, and irrelevant blog posts may be updated, merged, or removed. If a page is removed, decide whether it deserves a redirect to a useful replacement or a proper not-found response.

Step 3: Create a URL Redirect Map

A redirect map is a simple spreadsheet with two columns:

• Old URL.
• New URL.

Every important old URL should have a destination. If the page still exists, redirect it to the closest matching new page. If two old pages are combined, redirect both to the stronger new page. Avoid sending every old URL to the homepage; that is frustrating for visitors and can confuse search engines.

Google's site-move guidance recommends mapping old URLs to their new destinations and using server-side permanent redirects when possible. For small businesses, this usually means 301 or 308 redirects for pages that have permanently moved.

Examples:

• /services/emergency-plumbing redirects to /services/emergency-plumber
• /menu.pdf redirects to /menu
• /locations/north-side redirects to /locations/north-side-clinic
• /about-our-team redirects to /about

The redirect map should be reviewed before launch, not discovered after customers start hitting broken pages.

Step 4: Keep Email Separate From Website Changes

Many small businesses use the same domain for their website and email. That means DNS changes can affect both.

Before changing DNS, identify which records are used for email:

• MX records for receiving mail.
• SPF records for allowed sending services.
• DKIM records for email signing.
• DMARC records for domain-level email policy and reporting.
• Records for Google Workspace, Microsoft 365, hosted mailboxes, email forwarding, booking tools, CRM tools, or marketing tools.

Google Workspace documentation recommends SPF and also DKIM and DMARC for organizations. Microsoft similarly warns that if an SPF record already exists, you should not create a second SPF record for the same domain; the existing record should be updated so there is one combined SPF record.

For the owner, the practical rule is: do not replace the whole DNS zone just to launch a new website unless someone has checked the email records first.

A website provider may only need to change a few website-related records. Email records should be preserved unless the business is intentionally changing email providers too.

Step 5: Rebuild Forms, Booking, Payments, and Tracking

A migrated website is not ready just because pages load.

Test the actions that create leads and sales:

• Contact forms.
• Quote request forms.
• Appointment or reservation links.
• Online ordering links.
• Payment buttons.
• Newsletter signup forms.
• Map links.
• Phone and email links.
• Confirmation messages.
• Lead notification emails.
• Spam controls.

Then check measurement:

• Google Analytics or another analytics tool.
• Google Search Console.
• Conversion events for forms, calls, bookings, or payments.
• Redirect tracking for old URLs.
• Cookie or consent setup where relevant.

If a form routes to the wrong inbox after launch, the website may look finished while leads are quietly lost. Testing should include desktop and mobile. Submit real test inquiries, confirm who receives them, and check whether the thank-you message or confirmation email is accurate.

Step 6: Prepare the New Site Before Launch

The new site should be ready before the switch.

Check:

• Every main page has a clear title, heading, and call to action.
• Internal links point to new URLs, not old URLs.
• Images load and have useful alt text where appropriate.
• Contact details are consistent.
• Navigation works on mobile.
• The SSL certificate is ready or can be issued immediately after DNS changes.
• Temporary noindex settings or development blocks are removed before launch.
• The new sitemap is ready.
• Search Console and analytics verification will survive the migration.

Google's guidance also notes that if you use robots.txt or noindex rules during development, you should prepare to remove the blocking rules when the move starts. That is a common migration mistake: the site launches, but search engines are still told not to index it.

Step 7: Choose the Launch Window

Timing matters because customers may be affected while DNS, SSL, redirects, and testing settle.

For most small businesses, a good migration window is:

• Outside peak inquiry hours.
• Away from major promotions, events, or seasonal demand.
• When the owner or manager can answer quick questions.
• When the website partner is available to test and fix issues.
• Before a weekend only if support is available over the weekend.

Google recommends timing site moves during lower-traffic periods when possible. For a restaurant, that might mean not switching before Friday dinner service. For a dental office, not during a Monday morning rush. For a contractor, not during the first day of a seasonal campaign.

The goal is to leave time for calm testing.

Step 8: Launch, Then Test the Live Site

After launch, test the live site instead of assuming the staging site behaved the same way.

Check:

• The homepage loads on the correct domain.
• http redirects to https.
• www and non-www versions resolve consistently.
• Old important URLs redirect to the right new URLs.
• Forms submit and route correctly.
• Booking and payment links work.
• Email still sends and receives.
• Analytics and conversion tracking are active.
• Search Console can access the site.
• The sitemap is submitted or updated.
• The site works on a real phone.

For a domain move, Google's Change of Address tool may be relevant after the site has moved and redirects are in place. It is not used for every migration. For example, it is not for a simple hosting change where the visible URL stays the same.

Step 9: Monitor the First Few Weeks

A migration is not finished the minute the DNS changes.

For the first few weeks, monitor:

• Broken pages.
• Redirect errors.
• Form submissions.
• Email delivery.
• Search Console coverage and sitemap status.
• Analytics traffic patterns.
• Mobile usability or speed problems.
• Customer reports of old bookmarks or links not working.

Google notes that a medium-sized website can take a few weeks for most pages to move in its index, and larger sites can take longer. For a small business, this is why the redirect map and post-launch monitoring matter. Temporary traffic movement can happen, but avoidable errors should be fixed quickly.

Keep the old domain, old hosting, or old provider access long enough to confirm the move is stable. Do not cancel everything the same hour the new site goes live unless the migration plan already accounts for redirects, files, domains, and backups.

Common Migration Mistakes

The most common small-business website migration mistakes are preventable:

• Launching without domain access.
• Forgetting that email uses DNS too.
• Replacing DNS records instead of preserving needed records.
• Letting old important URLs become 404 pages.
• Redirecting every old page to the homepage.
• Launching with development noindex settings still active.
• Forgetting PDFs, menus, galleries, or old service pages.
• Breaking forms, booking buttons, or lead routing.
• Changing domain, CMS, design, copy, and URL structure all at once without a map.
• Canceling the old provider before redirects and backups are confirmed.

None of these problems require a huge site to matter. A five-page local business website can still lose inquiries if its contact form breaks or its old service page links stop working.

What to Ask a Website Provider Before You Switch

Before choosing a new provider, ask:

• Will you review the old site before rebuilding it?
• Will you map old URLs to new URLs?
• Who handles redirects?
• Who changes DNS?
• How do we protect Google Workspace, Microsoft 365, or other email records?
• Will forms, booking tools, and tracking be tested after launch?
• What happens to old images, PDFs, and blog posts?
• Will the new site have a sitemap?
• Who verifies Search Console and analytics?
• What support is available during launch?
• What happens if we need a new page, booking integration, or custom section later?

The answers matter more than the sales pitch. A migration is operational work, not just design work.

How Brimky Helps With Website Migration

Brimky is built for small-business owners who want to move faster without becoming the website operator.

The Brimky path starts with a proven industry template, then customizes it to the business with managed website setup, CMS, hosting, SSL, domain/DNS help, forms, and support. For an existing site, the migration should be planned around the details that protect continuity: old content, important URLs, redirects, forms, email-related DNS records, analytics, and launch timing.

Brimky also supports add-ons when a migration needs more than a basic template switch, such as extra service pages, location pages, booking integrations, lead capture, analytics and conversion tracking, local SEO setup, Google Business Profile help, multilingual content, or custom work.

The practical benefit is accountability. Instead of coordinating a designer, host, registrar, email provider, CMS plugin, and analytics setup yourself, you have one managed website path to plan the move.

If your current website is outdated, slow, hard to update, or stuck with a provider that no longer fits, Brimky can help you move into a managed small-business website without treating domains, redirects, email, forms, and launch timing as afterthoughts.

CTA

Moving an existing website? Browse Brimky templates or contact Brimky to plan a managed migration that covers the site, CMS, hosting, domain/DNS, redirects, forms, and launch handoff.